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.
This is taken from my Kickstart file and was my attempt to address this without messing up the FUTURE stuff to much (Rocky Linux Version 9.5):
#=================================================================================================#
# 9.14 Configure Repository Access with FUTURE Crypto Policy #
#=================================================================================================#
# Problem: #
# - When using FUTURE crypto policy, repository connections fail with: #
# "EE certificate key too weak" (curl error 60) #
# - This happens because both the mirrorlist service and the direct repositories use #
# 2048-bit RSA keys in their TLS certificates #
# - The FUTURE crypto policy requires minimum 3072-bit RSA keys #
# #
# Technical explanation of the issue: #
# - Both mirrorlist (mirrors.rockylinux.org) and direct baseurl (dl.rockylinux.org) #
# use 2048-bit certificates that trigger the error #
# - However, our testing showed that combining two workarounds helps bypass the issue: #
# 1. Disabling the mirrorlist mechanism avoids the initial certificate check for #
# the mirror selection service #
# 2. Using empty SSL parameter settings in DNF config appears to modify how #
# certificate validation occurs (using system defaults rather than strict policy checks) #
# - The combination of both approaches provides a working solution #
# #
# Solution: #
# - Disable mirrorlist and enable direct baseurl connections (workaround part 1) #
# - Create a targeted DNF-specific configuration with empty SSL parameters (workaround part 2) #
# - This affects ONLY repository connections, not the entire system #
# - System-wide FUTURE crypto policy remains active for all other services #
# #
# Security implications: #
# - Better than downgrading entire system to DEFAULT policy #
# - Better than disabling SSL verification entirely (which would be unsafe) #
# - CIS security compliance maintained for all services except repositories #
# - Certificate verification still active, only key length requirement is modified #
# #
# Future considerations: #
# - This is a workaround for a specific issue with Rocky Linux repositories #
# - When Rocky Linux upgrades their certificates to use 3072-bit RSA keys, this override #
# will no longer be necessary and should be removed #
# - The behavior of empty certificate parameters is not thoroughly documented in DNF #
# and could potentially change in future versions #
#=================================================================================================#
echo "CONFIGURING REPOSITORY ACCESS WITH FUTURE CRYPTO POLICY." | tee /dev/tty1
printf "\r\n" | tee /dev/tty1
# WORKAROUND PART 1:
# Modify repository files to bypass the mirrorlist mechanism completely.
# While both mirrorlist service and baseurl have the same certificate issue,
# Testing showed this step is necessary in combination with the SSL parameter settings.
echo "[INFO] Rewriting Rocky repo files to disable mirrorlist and enable baseurl." | tee /dev/tty1
printf "\r\n" | tee /dev/tty1
for file in /etc/yum.repos.d/rocky*.repo; do
if [ -f "$file" ]; then
# Only modify files that actually contain mirrorlist entries
if grep -q '^mirrorlist=' "$file"; then
sed -i \
-e 's|^mirrorlist=|#mirrorlist=|' \
-e 's|^#baseurl=|baseurl=|' \
"$file"
echo "[INFO] Updated: $file" | tee /dev/tty1
printf "\r\n" | tee /dev/tty1
else
echo "[INFO] Skipping: $file (no mirrorlist entries found)" | tee /dev/tty1
printf "\r\n" | tee /dev/tty1
fi
fi
done
# WORKAROUND PART 2:
# Configure DNF to use empty SSL parameters, which causes it to use system defaults
# rather than the strict crypto policy checks. This combination with direct baseurl
# connections allows DNF to work with 2048-bit certificates.
echo "[INFO] Creating DNF crypto policy exception for repository connections." | tee /dev/tty1
mkdir -p /etc/dnf/dnf.conf.d/
cat > /etc/dnf/dnf.conf.d/crypto-policy-repo-exception.conf <<'EOF'
[main]
# Repository-specific TLS settings override.
# Keep SSL verification enabled for security.
sslverify=1
# The following empty settings modify the certificate validation approach.
# When these parameters are left empty, DNF uses system default certificate
# validation instead of the strict FUTURE policy checks.
# This allows DNF to accept 2048-bit RSA keys used by Rocky Linux repositories.
sslclientkey=
sslclientcert=
sslcacert=
# NOTE: This is a targeted workaround that only affects DNF repository connections.
# All other services continue using the strict FUTURE crypto policy.
# This configuration should be removed when Rocky Linux upgrades to 3072-bit certificates.
EOF
echo "[INFO] Added repository-specific TLS configuration to allow 2048-bit RSA keys." | tee /dev/tty1
printf "\r\n" | tee /dev/tty1
# Clean DNF metadata and refresh to apply new configuration.
# This forces DNF to reload its configuration and retry with new settings.
echo "Running: dnf clean all && dnf makecache --refresh" | tee /dev/tty1
printf "\r\n" | tee /dev/tty1
dnf clean all
dnf makecache --refresh || echo "[INFO] Repo refresh failed. Check network or verify if FUTURE policy is still blocking TLS handshake." | tee /dev/tty1
printf "\r\n" | tee /dev/tty1
echo "Repository TLS override complete. FUTURE policy remains system-wide." | tee /dev/tty1
printf "\r\n" | tee /dev/tty1
Obviously this is part of a large Kickstart so may need %post %end etc.