Help thread for DST Root CA X3 expiration (September 2021)

Is anyone running FreeIPA with letsencrypt certs? I've been using them for both the web and LDAP servers, and could always install a new cert with ipa-server-certinstall . Now however I get this error message and cannot install the new certificates


CA certificate CN=DST Root CA X3,O=Digital Signature Trust Co. in /etc/letsencrypt/live/XXX/cert.pem, /etc/letsencrypt/live/XXX/privkey.pem is not valid: certutil: certificate is invalid: The certificate issuer's certificate has expired. Check your system date and time.

The ipa-server-certinstall command failed.

1 Like

You need to specify "ISRG Root X1" as your preferred chain when generating certificates. The exact process for doing so will depend on what software you're using.

As for switching back, if you stop specifying a preferred chain then you'll go back to generating certs with the default chain.

1 Like

I work on a macbook (Catalina 10.15.7) and develop a webapp on my local machine. I use the mailtrap.io email testing service to check outgoing emails. I haven't changed anything, but a few days ago the mailtrap service gives back the below error message:

ErrorException stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Illuminate\Foundation\Bootstrap\HandleExceptions::handleError vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/StreamBuffer.php:94

Mailtrap advises the following:

Regarding SSL error while trying to send emails to Mailtrap: You are not alone. Please update your OpenSSL version You might hear about the global issue with Letsencrypt certificates: its old root certificate expired on Sep 30. Mostly it impacted clients who use OpenSSL versions prior 1.1.0. The most common solution is to update your OpenSSL. If you can’t do that read the recipe for v.1.0.2 from OpenSSL.

My first approach was to remove the expired certificate and install the some new ones. I removed the DST Root CA X3 section from /etc/ssl/cert.pem file and removed all DST Root CA X3 instances using the Keychain Access app. Then I installed the ISRG Root X1 and ISRG Root X2 using the Keychain Access app setting them to always trust. Unfortunately I still get the same error message after rebooting.

The secong approach would be update OpenSSL on my machine. The "openssl version" command tells me that I have LibreSSL 2.8.3 on my machine, so I assume this is what I need to update. Checking the libreSSL release notes it seems that there already a fix for this problem. But I'm a little concerned that I mess-up my mac with this procedure.

Am I on the right track? Should I update LibreSSL to the latest version? How do I do that? Are there any side-effects? Are there any better solutions to this problem?

Any advice would be highly appreciated!
Thanks! W.

1 Like

2 posts were split to a new topic: Expired R3 chain

I have not yet been able to figure out how to issue that command successfully. Using certbot on Ubuntu with Nginx. Tried
sudo certbot --preferred-chain "ISRG Root X1"

2 Likes

6 posts were split to a new topic: iOS and Android issue

@kmconklin
That is the correct way to use that parameter:

But, it requires having certbot v1.12.0(or higher)
Which certbot version are you using?
certbot --version

5 Likes

Am I right assuming that renewal of the certificates will not solve the issue ? We have some clients who still have a chain pointing to expired certificate. Other than them updating their OS and/or browsers is there anything I can do as service provider ?

1 Like

Correct, usually the end leaf certificate is perfectly fine and valid. However, with some ACME clients, if the server operator would want to use the "short" certificate chain, the only way to force the client to retreive the short chain from the ACME server is to force a renewal in combination with "get me the short chain" option for the ACME client (with certbot you'd use --preferred-chain "ISRG Root X1").

3 Likes

@Osiris thanks a lot for clarifying, I'm using auto-ssl/lua-resty-auto-ssl with resty to generate certificate for few hundred websites and I think it uses dehydrated under the hood which supports preferred-chain option. However it's a big hassle to generate few hundred certificates. Also what's interesting when I check the chain on my machine I get short version but for the same certificate the clients who have issues get longer chain, that's why I'm not sure if regenerating will solve it at all?

2 Likes

If you're "checking the chain" using a browser, then note that this is not a good way to check which chain your server is sending. It only shows one of the possible chains a browser can make. And browsers often can make a few different chains. It's better to use openssl s_client -connect $hostname:443 -servername $hostname or online checkers such as SSL Checker .

Also note that if you choose to use the short chain and the actual issue your clients have is a lack of ISRG Root X1 in their certificate root store, the short chain won't fix anything.

4 Likes

Thanks @Osiris the issue with client is that her browser shows ISRG Root X1 -> DST Root CA X3 and the last one being expired. Would this mean then I can then regenerate with short chain this one and then it will be just fine ? What I'm afraid of is that in her browser ISRG Root X1 might still point to expired one.

2 Likes

I think the thing you should be afraid of is that with the short chain your client would get an "issuer unknown" error. It looks like your client doesn't have ISRG Root X1 in the root store. I've seen more issues with Windows 7 not updating the root certificate store. Take a look around on the Community. I'm not a Windows 7 user, so I have no clue about it, but it did came up a few times.

3 Likes

So the safest path is to ask them to update their OS ?

1 Like

I think their Windows 7 is missing the ISRG Root X1 indeed due to missing updates. See for example the following post from a different thread with a possible solution: Windows 7 Chrome - NET::ERR_CERT_DATE_INVALID - #48 by i4004

2 Likes

Greetings LE community,

We have recently changed our certificates to use --preferred-chain "ISRG Root X1 as we did not have control over clients connecting to our services. This worked perfectly. However, I was wondering what the difference in compatibility between the short-chain vs the default longer chain is.

Is it expected we migrate to the longer default chain eventually or is the shorter chain also long-lived supported?

1 Like

Hi there Sander, welcome!

The longer chain is purely there for compatibility for Android older than 7.1.1.

The short chain is in principle the "correct" chain, but lacks older Android compatibility, so LE chose to use the longer chain by default.

5 Likes

Both trust paths hinge on the same cert ("ISRG Root X1") - which only has one expiration date.
So that makes the lifespan of both trust paths identical.

1 Like

Just to clarify:

ISRG Root X1 cross signed certificate served in long chain will expire at Sep 30 18:14:03 2024 GMT

ISRG Root X1 self signed certificate will expire at Jun 4 11:04:38 2035 GMT

Cheers,
sahsanu

2 Likes

But that wouldn't hamper a non-Android-pre-7.1.1 client even if the "long" chain was used by the server, as such clients would chain to the ISRG Root X1 in their trust store and would ignore the cross-signed ISRG Root X1 anyway. The expiry date of Sep 30 18:14:03 2024 GMT is just relevant for older Androids.

4 Likes