CURL certificate error on apstream

General
#1

I’ve been configuring a Rocky 8.4 VM under QEMU/KVM as a base for cloning production VMs. I have other VMs running Rocky 8.4 already.

The issue i’m having now is that when I try to install or update packages I get the following CURL certificate error:

[root@rocky-base ~]# dnf makecache
Rocky Linux 8 - AppStream 0.0 B/s | 0 B 00:01
Errors during downloading metadata for repository ‘appstream’:

I have not modified anything that I’m aware of having to do with certificates.

Looking for a solution.

Steve

#2

Someone had this in a post already on the forum: Curl 60 error when updating system - #2 by bug4j

See if the solution here helps. Alternatively, if the solution from the link doesn’t work, you can try a:

dnf clean all
dnf update
#3

I looked at this and it does not seem to apply as this error is when trying to get the mirrorlist from rockylinux.org.

I have made sure I’m synchronized with a time source.

the error indicates that the EE certificate key is too week. I have done nothing that I’m aware of with ket certificates.

Steve

#4

Hi,

I was faced with the same situation with baseos and appstream repos:

Error: Failed to download metadata for repo ‘baseos’: Cannot prepare internal mirrorlist: Curl error (60): Peer certificate cannot be authenticated with given CA certificates for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=BaseOS-8 [SSL certificate problem: EE certificate key too weak]

The culprit in my case were crypto policies set to FUTURE (you can check your config with: update-crypto-policies --show) , and on some HTTPS mirror sites RSA public key length is less than 4k. And mirrors.rockylinux.org is one example of “broken” mirror sites.

As workaround I did simply use mirrors.rit.edu as baseurl in yum configs for baseos and appstream. But in the future probably public key length greater than 4k should be mandatory for official RL mirrors.

Iztok

1 Like
#5

Hey @iztokd - Glad you were able to figure this out for your system.

With respect to 2048-bit keys on the mirrors - this will not be changing any time soon. 4096-bit keys are computationally very expensive, and furthermore provide little security gain for something like a TLS web certificate which is already rotated automatically every ~90 days.

On the backend connections, we are either using 4096-bit RSA or ECDSA keys, however these are long-lived connections between our CDN and origin, and therefore the overhead of the TLS authentication and decryption can be mitigated more.

The big thing here is that many people use Rocky on a lot of different systems, from beefy servers to raspberry Pi’s! and we want to make sure nothing is obnoxiously slow for anyone.

You can read some more about this predicament in a great write up from APNIC (and Fastly) from last year! https://blog.apnic.net/2020/09/14/why-bigger-isnt-always-better-when-it-comes-to-tls-key-size/

2 Likes
Curl 60 error when updating system
Mirrors.rockylinux.org - 2048-bit RSA key insufficient for FUTURE crypto-policy
#6

Hi,

Thanks for explaining the reasoning behind different key sizes. So the best way is to stick with DEFAUL or FIPS security policies and then harden individual deamons ckonfiguration if needed. Hm proxy between RL system and mirrors could also solve that when using FUTURE sec. policy.

Thanks again!

1 Like
#7

Yep! That’s a great solution, as well, to add a middleware appliance to “downgrade” to the DEFAULT crypto policy.

#8

Looks like RHEL8 had this issue initially and RH upgraded their server certs

#9

Using the process described here: How to customize crypto policies in RHEL 8.2

I copied the FUTURE.pol policy to MOSTLY_FUTURE.pol
Then edited this line to 2048 bit rsa
min_rsa_size = 2048
and deployed the new policy
update-crypto-policies --set MOSTLY_FUTURE
and that prevented the “EE certificate key is too week” error when trying to update with dnf.