Certbot 1.12+ which supports --preferred-chain in OS packages

[Johnson66666]

Hi.

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 --prefered-chain option.

I also know that I could install a more up to date version of certbot using snap : https://certbot.eff.org/lets-encrypt/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?

Thank you.

[Phil]

Hi @Johnson66666,

Welcome to the community forum! An option you have is to use another client such as acme.sh.

[bmw]

@Johnson66666

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?

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:

• Update to Debian bullseye/stable where certbot 1.12.0 is available

• Install Certbot through pip

• Run Certbot in Docker, however, the nginx plugin which you're presumably using won't be available and you'll need to switch to using webroot or standalone, make the necessary paths/ports available to the Docker image, and manually configure certificate renewal including reloading nginx to pick up the new certificate.

[Johnson66666]

Well thank you I think that I'm gonna use it

[Johnson66666]

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?

[rmbolger]

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.

[Johnson66666]

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?

[Nummer378]

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.

[Johnson66666]

Well thank you very much, I think I got it now, correct me if I'm wrong

• Xamarin apps use their own chain list by default that does not implement RFC4158 correctly so they can't use the intermediate ISRG Root X1 if DST Root CA X3 is also available
• I broke the < 7.1 compatibility by renewing with the --preferred-chain "ISRG Root X1" option so Xamarin apps can temporarily work
• Xamarin devs will have to specify in their code to use OS-side truststore on Android. They'll also have to ignore the expiration date of DST Root CA X3 for Android < 7.1. Basically this way they'll use one or other chain depending on the OS version, someone suggested a solution here : TrustFailure exception with inner exception: Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED on android and xamarin-forms on android · Issue #4688 · xamarin/xamarin-android · GitHub
• I can re-issue my cert on the server side without the option after that so everything forks fine again