10 posts were split to a new topic: MacOS keychain issue
2 posts were merged into an existing topic: Certificates are not trusted on Chrome and Safari on old iMac with El Capitan
A post was merged into an existing topic: Ubuntu Android problem
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.
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: https://community.letsencrypt.org/t/production-chain-changes/150739; 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
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?
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?