The only decision LE made was which (of the two remaining paths) would it serve as the default.
[a root cert expiry is not something any choice can avoid]
And of the two trust paths, some systems (like your MacOS 10.9.5) won't like either.
3 Likes
Then they will get the same message from any of the other 200 million sites that use LE certs.
They will likely start to see the pattern and realize it is their systems that needs the "fix" or upgrade.
3 Likes
LE has zero control over messages shown by Chrome.
3 Likes
I'm not sure what you mean by the two remaining paths and it would still have been nice with a bit of warning instead of saying that there would be no issues at all with browsers.
Could they have waited?
2 Likes
Well thank you for you help.
2 Likes
No.
The root expired and that can't be postponed.
There are currently two remaining "valid" trust paths:
- the longer chain (via "DST Root CA X3 (expired)"
good for old Android devices - the shorter chain (via "ISRG Root X1")
good for devices that have that "newer" root installed ("trusted")
4 Likes
Hello to all,
I need your help with a client of ours. her web system works on any computer we have apart of hers.
She has a mac 2014 , and she is getting certificate error when in all other devices is opening with no problems.
DST Root CA X3 ( Expired )
How can I update the root on that laptop as it affects the ISRG Root X1 which is below this.
I wish I could put a screenshot here to see it.
She is running mac os 10.11 ...
Thank you in advance,
2 Likes
If someone who has access to that system is comfortable with using a command line, this may be the "quick fix":
Otherwise, there are more manual (but graphical) instructions here:
(The reason why you're seeing this error in the first place is because ISRG Root X1 is only included in macOS 10.12.1 or newer, but that system is slightly older than the cutoff. Your other systems probably are all running a newer version of macOS, so they don't have these issues. You could also try updating the affected system to a more recent macOS, instead of the above)
4 Likes
@stiobhan , I too am getting the exact same thing on our Centos 7 FreeIPA when running ipa-server-certinstall. I've been trying every which way to get the DST CA out of /etc/ssl/certs and/or /etc/ipa/ca.crt. Are you still stuck with this issue?
1 Like
@erglazier
Have you tried (using a bigger hammer!)?
vi /etc/ssl/certs/ca-bundle.crt
vi /etc/ssl/certs/ca-bundle.trust.crt
2 Likes
@erglazier
I managed to solve it with some help on the FreeIPA mailing list. Have a look here
I had the additional problem on one of our servers that the certificate itself had already expired. If yours is still valid you probably won't have to dig as deep as I did. Just make sure you replace the cross-signed X1 root cert with the self-signed one. If you have further questions I can help you over on the freeipa-users list.
1 Like
FreeIPA keeps this in a nss database
# certutil -L -d /etc/dirsrv/slapd-REALM
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
CN=MY_HOSTNAME u,u,u
CN=R3,O=Let's Encrypt,C=US C,,
CN=ISRG Root X1,O=Internet Security Research Group,C=US C,,
and then also a file /etc/ipa/ca.crt. I removed both the expired X3 and the cross-signed X1, and then put the self-signed X1 in.
3 Likes
super weird issue here with an univention server , we cannot renew certs for some reason because apprently curl while getting the correct R3 from the server doesnt seem to chain it down to ISRG however in /etc/ssl/certs it's definitely present and wget doesnt seem to have issues. curl basically just says that the certificate expired when trying to curl the acme v2 api endpoint.
root@server:/# curl -v https://acme-v02.api.letsencrypt.org/directory
* Trying 172.65.32.248...
* TCP_NODELAY set
* Connected to acme-v02.api.letsencrypt.org (172.65.32.248) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: certificate has expired
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
1 Like
Can you confirm that those locations have the self-signed "ISRG Root X1" cert?
grep MIIFazCCA1OgAwIBAgIRAIIQz /etc/ssl/certs/ca-certificates.crt
grep MIIFazCCA1OgAwIBAgIRAIIQz /etc/ssl/certs/ISRG_Root_X1.pem
2 Likes
yup it's in both.
1 Like
Yesterday I did end up just manually editing the /etc/ipa/ca.crt and the /etc/letsencrypt/archive full chain files- removing the DST chunk from both. I was able to get things working after that but it's hacky and I'm not sure it will persist. I intend to do more testing today. And that probably means removing it from the source, as you mention.
2 Likes
Thank you, I will take a look at that link you sent
2 Likes
For ubuntu 10.04 lucid
put http://curl.haxx.se/ca/cacert.pem into /usr/share/ca-certificates/
add a line cacert.pem into /etc/ca-certificates.conf
sudo update-ca-certificates
download the latest openssl and curl (configure with --with-openssl) make and install
==> fixed my problem
2 Likes
