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?
3 Likes
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
!mozilla/DST_Root_CA_X3.crt
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
subject=/CN=rmail.org
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.
2 Likes
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.
2 Likes
If you haven't already done so...
Try:
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.
2 Likes
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.
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
subject=/CN=my.host.net
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 
To add to your choices...
OR
Use an alternate ACME client. Like: acme.sh
OR
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.
Cheers,
sahsanu
2 Likes
Thanks a lot sahsanu. I'm using the version 0.38.0.0 which is the last I found on github.
Have a nice day!
2 Likes
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 :
https://github.com/xenetis/letsencrypt-expiration
Just run, it should work :
wget -O - https://raw.githubusercontent.com/xenetis/letsencrypt-expiration/main/letsencrypt-expiration.sh | bash
