My Nginx server was impacted buy the CA expiration. I don't understand why because our cert was issued in june 2021, and LE team claimed that the issue was anticipated starting this date. Every Android version was concerned, including latests (v9,10,11) contrary to what has been said last days. The client app having an issue was developed with Xamarin and they faced this error on every Android devices
Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
In the rush, I temporarily edited my fullchain.pem file and deleted the last certificate, which worked pretty well. Now I'm looking for a more reliable long-term solution.
I understood that I had to update certbot to at least v1.12 to gain a
--prefered-chain option while renewing in order to force
ISRG Root X1, with
certbot renew --preferred-chain "ISRG Root X1". But I'm stuck on v0.31 using the debian 10 native package, with no
I also know that I could install a more up to date version of certbot using snap : Certbot - Debianbuster Nginx The question is : do I have another option? Is an update via apt-install planned by the certbot team for the net few days, or do I need to migrate on the snap package?
Welcome to the community forum! An option you have is to use another client such as acme.sh.
You have a few options although unfortunately none of them include a newer version of the package being offered for Debian buster/old stable. In general, due to the policies in LTS distros, the Certbot packages there often lag behind.
We think the easiest option for most people is to use the Certbot snap, but if you don't want to do that for whatever reason, in addition to the option of using another client, your other options include:
Well thank you I think that I'm gonna use it
Thanks for the review. Yeah I don't like snap and I don't want to depend on it so I think I'll choose to use acme.sh.
Any idea if I'll need to renew using --prefered-chain or if LE team already removed it's expired CA from its renewal result?
Your understanding of the situation is a little off-base. But the short answer to your question is yes, you'll need to use the preferred chain option of your ACME client for the time being to get the short chain that doesn't utilize the workaround for old Android devices.
OK thank you. Could you please tell me why since we passed 30 sept, the X3 root CA is still there by default when we ask for a renew? I mean it's expired, why is it still issued? It means that we'll have to use the
--preferred-chain option until the end of time?
Let's Encrypt serves a chain up to the (now expired) DST Root CA X3, because that helps with Android compatibility. The current plan is to serve this chain until about 2024, though those plans may change at any time.
Most clients should have no problem with either chain - ISRG Root X1 is included in the current chain, and any validation algorithm following RFC4158 (and having ISRG Root X1 in the trust store) will use that as its trust anchor.
There are some clients - especially older versions of non-OS/non-browser related TLS implementations (OpenSSL, GnuTLS and others) that do not implement RFC4158 correctly. Those clients can verify the alternate chain, but not the default*.
For these clients, there are sometimes client-side workarounds available (removing the expired root from their trust store, enabling optional features....). Serving the shorter alternate chain server-side is a valid workaround server-side, but will break Android < 7.1.1.
*Assuming that ISRG Root X1 is in their trust store. Clients where this does not apply usually have issues with either chain, unless they ignore the expiry of DST Root CA X3 and the server serves the long chain.
Conclusively, both chains have advantages- and disadvantages. There is no solution for everyone.
Well thank you very much, I think I got it now, correct me if I'm wrong
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.