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.
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.
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.
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.
4096 may be computationally expensive, but industry is pushing/forcing toward such. Nessus vulnerability scans report weak ciphers, etc. Mitigation recommends “FUTURE”. Industry trying to adhere to security needs, yet sources not allowing. makes for bad situation in these time of ransomware, etc especially for gov institutions.