R3 Intermediate certificate has expired - How to fix this on Debian with Certbot?

R3 Intermediate certificate has expired - How to fix this on Debian using Certbot?

Thank you

1 Like

Is your website ssl config configured to use fullchain.pem? This file should be recently updated and contain the latest certificate and intermediates.

If you need more help than that and you've already done a restart etc, you'll need to fill out all the questions from the new topic template like what command are you using, what webserver are you using, what's your current config, what's your domain?


same issue here...

using the certbot:

root@mx ~/dev/ # certbot --version
certbot 1.19.0

i also deselect X3

root@mx ~/dev/ # cat /etc/ca-certificates.conf |grep X3

root@mx ~/dev/ # update-ca-certificates

but when i try to test:

root@mx ~/dev/ # openssl crl2pkcs7 -nocrl -certfile /etc/letsencrypt/archive/mx.rmail.org/cert8.pem | openssl pkcs7 -print_certs -noout
issuer=/C=US/O=Let's Encrypt/CN=R3

i got the "issuer=/C=US/O=Let's Encrypt/CN=R3".... My website https://mx.rmail.org works correct (nginx) no problems, but my mail clients with the same cert for dovecot does not work but i did not understand why

.. which is correct. The R3 private key currently is used to sign end-leaf certificates.


Ok, I also found the issue for my mail problem, not solved but I am working on it.... it seems i have to change the root ca manually for the mta server.

Preferably all certificates including intermediates do not require manual intervention, but are handled by the ACME client. For mail clients usually just a single manual intervention is required: at the installation of the certificate. All other things like a change of intermediate certificate or change of certificate chain should be handled automatically, if everything is set up correctly.


If you haven't already done so...


sudo atp update
sudo apt install libgnutls-openssl27 libgnutls30
sudo apt install ca-certificates
1 Like

I guess I should add that this only works for Stretch or newer. When I tried it on Jessie, it couldn't find libgnutls30.


Tried 25-30 or without a number?
[yes I'm that guy - there is always a bigger hammer!]

1 Like

Has anyone been able to get this fixed? I'm having similar SSL issues with STunnel.

1 Like

Please be more specific.
STunnel and which O/S & version & anything else relevant.

A post was split to a new topic: R3 issue on Ubuntu 16

So I ran the same check as I'm encountering similar problems (in my case I'm using letsencrypt to signa cert used by a StrongSWAN VPN server), the Client app says the server is returning a cert that expired Sep 29 2021 20:21:40 (oddly specific and doesn't perfectly match root expiry, might be tz diffs, not sure),

Ran all updates via apt (system is Debian Stretch), ran certbot again to renew the cert, same issue

anyway, I get the expected result from the cert.pem so I ran the check on the fullchain;

openssl crl2pkcs7 -nocrl -certfile /etc/letsencrypt/live/my.host.net/fullchain.pem |openssl pkcs7 -print_certs -noout

issuer=/C=US/O=Let's Encrypt/CN=R3

subject=/C=US/O=Let's Encrypt/CN=R3
issuer=/C=US/O=Internet Security Research Group/CN=ISRG Root X1

subject=/C=US/O=Internet Security Research Group/CN=ISRG Root X1
issuer=/O=Digital Signature Trust Co./CN=DST Root CA X3

It seems that the signing by ISRG Root X1 should be sufficient and that it's still being cross signed by DST Root CA X3 is the problem?

Is there some flat to pass to certbot to ask it not to do that or can I just literally edit the PEM file to lop off the lower 3rd?

Oh I see. I just need to add --preferred-chain "ISRG Root X1" to the certbot command

Except that the version shipped with Debian Stretch is waaay to old to feature that switch, so my options seem to be to grab certbot from snap (which plops a load of canonical/ubuntu stuff into the Debian box, which feels odd) or maybe just use this as a good excuse to dist upgrade away from Stretch.

Hi @PhilV welcome to the LE community forum :slight_smile:

To add to your choices...

Use an alternate ACME client. Like: acme.sh

Use alternate (free) CAs. Like: ZeroSSL.com / BuyPass.com

Hi all, if it helps, this article https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ talks about the root CA X3 expiration.
With all Browsers, it worked fine but with (java) tools working on the url, I had the issue of expired part.
I'm maybe not using the same way as you all, because I'm using le64.exe to generate my certificates but I have the same issue of the intermediate certificate expired.
To resolve the issue, I've removed the expired part from my certificate.
I've checked the complete chain with this site https://tools.keycdn.com/ssl and the url after the replacement with this site https://decoder.link/sslchecker/.
Everything looks good.
It's probably not the most automated solution but it solved my issue and my certificate works fine at 100% in all situations.
I'm not an expert but if you have any idea of how to generate the cert without the expired part at the end, I'm interested.

Hello @it22,

You should use last Crypt-LE version and use the parameter --alternative 1 to use the short-chain instead of the long-chain (this long-chain is the default and the one that includes the expired DST Root CA X3 certificate).

Check Crypt-LE doc for more info.



Thanks a lot sahsanu. I'm using the version which is the last I found on github.
Have a nice day!


For Debian 8 and 9, I just do that for updating cert on host and no longer have the error 60: SSL certificate problem: certificate has expired :

Just run, it should work :

wget -O - https://raw.githubusercontent.com/xenetis/letsencrypt-expiration/main/letsencrypt-expiration.sh | bash

And before that, please first check what the code is actually doing, before you run something from a stranger on the internet.

It's just 13 lines of code (currently), so easy to check :slight_smile:

Besides the warning, thanks of course :wink:

1 Like