RPM package repository - key too weak

[DasFaultier]

Hi everyone,

I was trying to sudo dnf update my RHEL 8.10 system and got the following error message:

$ sudo dnf update
Subscription Management Repositorys werden aktualisiert.
MediaArea.net SARL software repository for rpm based distributions - x86_64                                          0.0  B/s |   0  B     00:00
Errors during downloading metadata for repository 'MediaArea':
  - Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://mediaarea.net/repo/rpm/releases/CentOS_8/x86_64/repodata/repomd.xml [SSL certificate problem: EE certificate key too weak]
Fehler: Failed to download metadata for repo 'MediaArea': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

So I went to re-read the documentation at https://mediaarea.net/en/Repos and tried to reinstall the repo-MediaArea-1.0-26.noarch.rpm package to make sure I wasn't making any mistakes and that the repo package was recent, but rpm wasn't able to pull the package either; same error.
The last line in the output says "Error: skipping .rpm - transmission failed", but the relevant part happens before that.

sudo rpm -Uvh https://mediaarea.net/repo/rpm/releases/repo-MediaArea-1.0-26.noarch.rpm
https://mediaarea.net/repo/rpm/releases/repo-MediaArea-1.0-26.noarch.rpm wird geholt
curl: (60) SSL certificate problem: EE certificate key too weak
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
Fehler: https://mediaarea.net/repo/rpm/releases/repo-MediaArea-1.0-26.noarch.rpm wird übersprungen - Übertragung fehlgeschlagen

Just to be on the safe side, I downloaded the package using curl and ignored certificate errors, but in the end I only found that the repo package was already installed in the latest version, so that looks very much like a server side issue.

$ curl -k https://mediaarea.net/repo/rpm/releases/repo-MediaArea-1.0-26.noarch.rpm
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
[jsachse@sdvlzarosappdev ~]$ curl -k https://mediaarea.net/repo/rpm/releases/repo-MediaArea-1.0-26.noarch.rpm --output repo-MediaArea-1.0-26.noarch.rpm
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 13196  100 13196    0     0   122k      0 --:--:-- --:--:-- --:--:--  122k

$ rpm -Uvh repo-MediaArea-1.0-26.noarch.rpm
Fehler: Transaktion-Sperre auf /var/lib/rpm/.rpm.lock kann nicht erstellt werden (Permission denied)
[jsachse@sdvlzarosappdev ~]$ sudo !!
sudo rpm -Uvh repo-MediaArea-1.0-26.noarch.rpm
Verifying...                          ################################# [100%]
Vorbereiten …                       ################################# [100%]
        Das Paket repo-MediaArea-1.0-26.noarch ist bereits installiert

Could you please check the TLS certificate and key for the rpm package repository and update them with more modern versions?

Thank you and best regards!

[cjee21]

MediaArea server SSL cert looks to be as secure as it can get : https://www.ssllabs.com/ssltest/analyze.html?d=mediaarea.net&s=2600%3a3c00%3a0%3a0%3af03c%3a91ff%3afe33%3a6729&hideResults=on

It is even better than some banks...

I also have no issues with curl without -k:

>curl https://mediaarea.net/repo/rpm/releases/CentOS_8/x86_64/repodata/repomd.xml
<?xml version="1.0" encoding="UTF-8"?>
<repomd xmlns="http://linux.duke.edu/metadata/repo" xmlns:rpm="http://linux.duke.edu/metadata/rpm">
  <revision>1762387582</revision>
  <data type="primary">
    <checksum type="sha256">8d239d8f738ef8a84c2a3bdea2831026a1ca1c8d8b5b297fa5a3494c5497ad2d</checksum>
    <open...

Are root certificates configured properly on your system? Or maybe you can try the following command and ensure that you are receiving the correct cert?

>curl https://mediaarea.net -w "%{certs}"

...

Subject:CN=mediaarea.net
Issuer:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36
Version:2
Serial Number:15:3c:a7:52:5f:77:c7:0c:b0:6b:dd:89:89:c5:39:b8:
Signature Algorithm:sha256WithRSAEncryption
Start Date:2025-11-03 00:00:00 GMT
Expire Date:2026-11-11 23:59:59 GMT
Public Key Algorithm:rsaEncryption
RSA Public Key:2048

[DasFaultier]

My apologies for the late answer.

I've just tried the curl command you gave me and got:

$ curl https://mediaarea.net -w "%{certs}"
curl: unknown --write-out variable: 'certs'
curl: (60) SSL certificate problem: EE certificate key too weak
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

My next idea was to check for ca-certificates, but they are already installed and up to date:

$ sudo dnf list ca-certificates*
Letzte Prüfung auf abgelaufene Metadaten: vor 2:49:49 am Fr 05 Dez 2025 13:08:57 CET.
Installierte Pakete
ca-certificates.noarch          2025.2.80_v9.0.304-80.2.el8_10           @rhel-8-for-x86_64-baseos-rpms

I found out that RHEL's crypto policy might be responsible for this issue, so I tried that:

$ update-crypto-policies --show
FUTURE

The documentation at https://access.redhat.com/solutions/4740591 describes exactly this problem and states:

Root Cause
Certificate that is currently available is considered too weak for the FUTURE crypto policy.
More information about Strong crypto defaults in RHEL 8 and deprecation of weak crypto algorithms

OK, so when you follow this link, you find the description for the "FUTURE" crypto policy:

A conservative security level that is believed to withstand any near-term future attacks. The purpose of the policy is for testing infrastructure and applications for their readiness for future strengthening of requirements. The policy is not supposed to be used for general purpose systems. This level does not allow the use of SHA-1 in signature algorithms. The RSA and Diffie-Hellman parameters are accepted if larger than 3071-bits.

and it goes on to explain:

Disabled in the FUTURE policy, but enabled in the DEFAULT policy
The FUTURE policy provides additional hardening of the system. It is a conservative security level that is believed to withstand any near-term future attacks. The policy is not supposed to be used for general purpose systems.

• CBC mode ciphersuites in TLS
• Symmetric ciphers with smaller keys than 256 bits
• SHA-1 and SHA-224 signatures in certificates
• DH with parameters < 3072 bits
• RSA with key size < 3072 bits
  Please note that most of the current WWW site certificates use just 2048 bits RSA keys so it will not be possible to connect to most of the public WWW sites with this policy.

Your RSA Public Key is 2048 Bits, but that's deprecated in RHEL 8 with "FUTURE" crypto policy, and subsequently probably in other RHEL-based distributions as well. The required keysize in this scenario is RSA with key size >= 3072 bits.

I recommend updating the key to a more future-proof keysize; the recommendation that I've heard in the context of SSH is 4096 Bits for RSA keys.

[cjee21]

I've just tried the curl command you gave me and got:

Looks like your curl does not support that command so ignore that.

Well, that documentation explicitly says:

The purpose of the policy is for testing infrastructure and applications for their readiness for future strengthening of requirements. The policy is not supposed to be used for general purpose systems.

It's for testing for the future and not supposed to be for daily use now. It will break alot of things. Even redhat.com uses RSA 2048. Doesn't RHEL default to the DEFAULT policy? There must be a reason why it's named default.

So it is actually not an issue to use RSA 2048 at the moment but it's something for @JeromeMartinez to consider anyway. I see that Google is using 256-bits Elliptic Curve which may be better than RSA 4096 since it's smaller and faster with equivalent security as 3072-bit RSA.

[DasFaultier]

You're absolutely right, crypto-policy FUTURE is not the default. We use it because it disables a lot of rather ancient Ciphers in SSH that shouldn't be used in production anymore and that always made our vuln scanner pop up. Also, we're talking about RHEL 8 here, so their "future" is what other distros call "legacy". 😁 But seriously, thank you for looking into it with me.

I'm not sure what my workaround will be though, because due to our security policy, I cannot revert to a more lax crypto-policy. I will probably disable updates for packages from the repo for now and install from manually downloaded packages, and we'll see what Jerome thinks.

[cjee21]

Many distros are using plain http for their default/official repos...

[JeromeMartinez]

Many distros are using plain http for their default/official repos...

But delivered content is signed.

[JeromeMartinez]

We use it because it disables a lot of rather ancient Ciphers in SSH that shouldn't be used in production anymore

But RSA 2048 is not like them, still considered as fair enough.
And unfortunately I renewed the certificate with RSA 2048, oops.
I'll check if I can have another one easily.