Invalid certificate trust chain for centos.org (original) (raw)
October 16, 2024, 9:40pm 1
I was running into issues trying to retrieve some keys from https://www.centos.org using curl:
root@fae1f68d1eeb:/# curl https://www.centos.org/keys/RPM-GPG-KEY-CentOS-Official -o /tmp/RPM-GPG-KEY-centosofficial
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.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.
So I used openssl to inspect the certificates (openssl s_client -connect centos.org:443
) and got the following:
---
Certificate chain
0 s:CN = centos.org
i:C = US, O = Let's Encrypt, CN = R10
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Oct 16 10:10:20 2024 GMT; NotAfter: Jan 14 10:10:19 2025 GMT
1 s:C = US, O = Let's Encrypt, CN = R11
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Mar 13 00:00:00 2024 GMT; NotAfter: Mar 12 23:59:59 2027 GMT
---
Verify return code: 21 (unable to verify the first certificate)
The issuer for the centos.org certificate is Let’s Encrypt R10, while the certificate included in the chain is Let’s Encrypt R11. That discrepancy is causing the curl failure.
Surprisingly, when I run the same curl command from my macOS laptop, it works. When I visit the website from a browser, it seems to mostly work (I ran into an error once because of the same certificate error). I was wondering if others were observing the issue. Is it possible that the certificate chain is invalid on some webserver backends, but not all?
arrfab (Fabian Arrotin) October 17, 2024, 4:57am 2
Hi,
Yes, some certificates were renewed and now that Letsencrypt is using both R10 and R11 for RSA keys (since June 2024, see Chains of Trust - Let's Encrypt), it can be that it will be initially signed on one but renewed then on the other one. We detected the issue and adapted the process to ensure correct CA chain would be also distributed by ansible
antoninbas (Antonin Bas) October 18, 2024, 5:24pm 3
Thanks, everything seems to be working now.