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

If you have any questions about whether you need to do anything special for the upcoming DST Root CA X3 expiration in September 2021, please post them here. A staff member may split out some conversations into their own threads.

Note: Your first step in debugging should be to update your operating system. Most problems are solved by running the latest operating system available for your machine, and staying up to date will also make you more secure.

Update 30 September 2021

Yesterday, the R3 signed by DST Root CA X3 intermediate expired as planned. If you experience problems related to certificate chaining you should first review your configuration and make sure your server/website/device is sending the correct chain with the updated R3 intermediate signed by ISRG Root X1. It is unlikely that you need to force renewal to resolve issues related to R3 signed by DST Root CA X3 expiring. This thread and many more on the community offer advice to review and resolve this problem.

Earlier today, the DST Root CA X3 expired as planned. Most problems related to DST Root CA X3 expiring will not be solved by force renewal. Please search the forum and this this thread for help to resolve the problems you are experiencing before opening a new thread.


Hello Lets Encrypt.
My question is about Zimbra. After install or renew a cert, Zimbra asks to insert to chain.pem the IdenTrust root Certificate also. Otherwise will not deploy it.
The instructions are here: Installing a LetsEncrypt SSL Certificate - Zimbra :: Tech Center

What will happen after 11/21? Will Zimbra recognize Letsencrypt CA?

Thank you in advance.


If you have a test environment, or you can afford the Zimbra environment you do have to potentially be unavailable for a period (e.g. planned engineering) you should test what happens if you omit this step in their instructions.

This additional item in the chain will not be necessary for the web browser to trust your certificate, so the question is only whether for some reason the Zimbra software itself requires this certificate, which it should not do. If everything works perfectly without, you should advise the maintainers to update the instructions you linked, they seem quite old so it's possible they already knew they're wrong and should be updated. If things break, you could report that here, but most importantly alert the Zimbra maintainers that they've got a problem looming.


Thank you for your answer.
Our Zimbra server is very productive and actually the mail server one of our client.
Unfortunately we have to wait until next cert renew and see what will happened.
Zimbra forum don't have yet something similar. I'll try there and came back for new information.
Thank you.


I have one question, which is not answered on the docs page: for now, it looks like my certificates are signed by R3 which indicates an issuer of DST Root CA X3; when will the new chain be used in renewals?

Those details seem to be available in this other topic:; would it be possible to add those details on the help page?


If you have received a notification email containing an unfamiliar domain name, please see the Let's Encrypt staff message here:


Welcome to the Let's Encrypt Community :slightly_smiling_face:

Great suggestion! I've submitted changes to reflect this to DST Root CA X3 Expiration (September 2021) - Let's Encrypt that are awaiting review.


Does this issue affect all vendor-supplied versions of OpenSSL 1.0.x? Or have some vendors patched theirs? I'm curious in particular about Ubuntu's 1.0.2g-1ubuntu4.19 which comes with 16.04
We're a bit behind with upgrading our systems unfortunately (16.04 was supported till April this year).


There are some details on how OpenSSL will break when DST Root X3 expires if a server is sending the default chain in this thread:

And a questions for it thread, though it looks like it's since been closed:

I haven't heard of any specific vendor having backported a fix for it to older OpenSSL, but that doesn't mean it hasn't happened.

If your OpenSSL 1.0.x-based system is only connecting to servers you control, and those servers don't need to maintain compatibility with old Android, then you probably want your servers to be using the "alternate" chain that doesn't include the expiring DST Root.


I've heard that OpenSSL 1.0.2 can be manually fixed by setting the flag X509_V_FLAG_TRUSTED_FIRST. This flag is not set by default in 1.0.2, but you might be able to do this in your client applications (it can also potentially be done via config file nope, doesn't look like it).

I haven't tested this myself, as all my systems have OpenSSL 1.1, where the flag is set by default.


I've requested that topic be reopened to allow further questions (as I believe it was intended to be).



"If you run a typical website, you won’t notice a difference - the vast majority of your visitors will still accept your Let’s Encrypt certificate."

Based on my Analytics, I still have a good % of users on Android < 7.1 and iOS < 10.

Sure, "vast majority" of the users will be accepting the new certificates, but a good significant amount will be affected.

"To make sure the certificates we issue are trusted on older devices, we also have a “cross-signature” from an older root certificate: DST Root CA X3."
"DST Root CA X3 will expire on September 30, 2021."

I understand your position, and that this is the reason.

However (and I apologize for the ignorance), is there no workaround for this, such as cross-signing to some other older widely accepted root CA that is still active?

Are other certificates such as Comodo, Verisign, etc, being affected by the same problem?

Thank you!


We hear your pain and wish we could provide broader compatibility for longer, but we concluded it wasn't feasible for us. This workaround was requested and discussed recently in this thread which offers some more detail and options.

In the next few years, other certificates authorities will have their roots expire. This is a deep dive on the problem space that offers information about upcoming root expirations: The Impending Doom of Expiring Root CAs and Legacy Clients


To clarify, the users on Android < 7.1 will be fine, due to the special cross-sign we got. But it's true the users on iOS < 10 will have problems. In theory all iPhone 5 and later can upgrade to at least iOS 10, but I know there are a variety of reasons people may not install all updates.


Do you have any recommendations for testing client connectivity prior to the certificate expiring?

For example, is there a test web server available using only the ISRG Root X1 root certificate? Or a method to request a certificates without the DST Root CA X3?



Isn't that special cross-sign with DST Root CA X3, which is expiring this year?

I don't understand how in 2020, the article says: "IdenTrust has agreed to issue a 3-year cross-sign for our ISRG Root X1 from their DST Root CA X3.", if that root is expiring in Sep 2021.

Did I misunderstand something?

Thank you!


I'm not sure if it's misunderstanding or you simply stopped reading. The text gives an explanation why this works.


:grin: My apologies. My answer is there!

"Android has intentionally chosen not to use the notAfter field of trust anchors."

Thank you very much.


You can test what happens with a chain that only leads to ISRG Root X1 today, your ACME client might support an option to have it sort this out for you, or you can manually construct the chain, the individual certificates are signed documents, so you cannot change those, but the "fullchain.pem" file for example is just several certificates concatenated together, so if you remove a certificate from the file now it's not in your chain.

However, it will not be possible to check what happens exactly in September 2021, without travelling to September 2021. If you tell a computer today that it's already September 2021, it will say your certificates aren't trusted because they're out-of-date - you got them back in May (ie now). We can do some better experiments on the details in July and I believe there are plans for just that.


You can already test this today, if you have control over both client and server that you're testing -

You can issue a cert from Let's Encrypts staging enviroment. Staging is specifically configured to serve a chain up to a root that is already expired. However, the staging certificates are not trusted, so you need to temporarily add the Let's Encrypt staging certificates to your trust store do test. (Remove them after you're done).

The test certificates used in staging are documented here: Staging Environment - Let's Encrypt

I host a test server that is configured to serve a staging chain, if you don't want to set that up yourself: Remember to add the staging certificates to your trust store when testing, and don't forget to remove them after that.

PS: As I just saw that the LE staging documentation is a bit confusing, here's the staging root certificates you need to add for testing. (This is a simulated "ISRG Root X1" certificate) (This is a simulated "DST Root CA X3" that is already expired. Adding this to your trust store enables testing on how your trust store handles expired root certificates)