• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Lets Encrypt root certificate expiration on 30 September 2021

Guys, just be aware that even newly issued LetsEncrypt certificates are still dual/cross-signed with the old and now expired R3 certificate and a properly configured server will send this expired intermediate to the client. (alongside the domain certificate and the proper/new intermediate )

This can and will cause troubles with some clients, as they may check and use the old but not the new chain. (clients with older openssl library for example)

On the server side you can manually remove the old chain cert from the LetsEncrypt chain.pem/fullchain.pem files and this will solve that problem.
Of course, once the certificate gets renewed, you have to do this again...
Though I think that LetsEncrypt will stop cross-signing soon and this will solve the problem once and for all. (as it's completely bullshit to do so - at least now, that the old intermediate and root are expired)
 
Addendum, yes on brand new servers you don't need a manual workaround, because OpenSSL has some built-it filter that explicitly masks the offending LetsEncrypt chain certificate if it encounters it.

I did not read into the details on the OpenSSL Dev List, but there may even be some intelligence/logic in it, that this filter tries to determine if the client is an old one that does not know the new LetsEncrypt root and in that case it will send automatically the old (and now expired) intermediate certifcate instead of the new.
 
Addendum, yes on brand new servers you don't need a manual workaround, because OpenSSL has some built-it filter that explicitly masks the offending LetsEncrypt chain certificate if it encounters it.

I did not read into the details on the OpenSSL Dev List, but there may even be some intelligence/logic in it, that this filter tries to determine if the client is an old one that does not know the new LetsEncrypt root and in that case it will send automatically the old (and now expired) intermediate certifcate instead of the new.
I have the same issue! I've done all Ubuntu and Plesk updates, but our API is still not working!!! When I do a SSL check, the old root cert is still in the chain. Any idea?
 
I faced this problem on my windows 10. Root certificates need to be renewed. I wrote instruction, but it in russian full instraction in russian

Major action:
In Windows PowerShell you must insert this:
cd C:/
certutil.exe -generateSSTFromWU roots.sst
$sstStore = ( Get-ChildItem -Path C:/roots.sst )
$sstStore | Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root
 
have solution fix on centos6 ?
Looks like migrating to a more recent OS is your only choice:
 
@Monty
I really don't get these LetsEncrypt guys...

They insist on keeping the old chain alive and you can read statements like these from many involved people:

Using LE's short alternate chain is definetly a fix, if all servers are under your control and old Android compatibility is not required.

But, but, but.....I mean, the old chain and root expired two days ago, so these certificates are no longer valid on the old Android devices anyway.
So why keep that old chain?!?
 
going nuts ;( - I recognize that something is up with my computer despite it being a modern Surface Pro machine and windows 10 is completely up to date. I have a mac as well and mobile devices and they are all working just fine. That said, from my windows machine, likely owned by many millions users, I was not able to access sites like stackoverflow as well as letsencrypt.org itself and of course my own websites described in my previous post.

Finally I manually imported the "ISRG Root X1" cert which was missing from my machine from here: Chain of Trust - Let's Encrypt - problem was solved. Why it was not installed? Microsoft, go figure. Thanks for all the help, at least I learned a few things.
 
Pour une utilisation Debian :
sudo cp /etc/ca-certificates.conf /etc/ca-certificates.conf.orig
sudo nano /etc/ca-certificates.conf
Remplacez « mozilla/DST_Root_CA_X3.crt » par « ! mozilla/DST_Root_CA_X3.crt ” une sauvegarde
sudo update-ca-certificats
Merci Matrix, cela a parfaitement fonctionné pour mon ancienne Debian 8 qui est en fin de vie lol L'année prochaine, changement de serveur et dernière version de Debian sont à l'ordre du jour.

Bonne journée
 
have solution fix on centos6 ?

Here you go: RHEL/CentOS 6 OpenSSL client compatibility after DST Root CA X3 expiration

Build openssl RPM:

Code:
yum install wget
yum install krb5-devel zlib-devel lksctp-tools-devel util-linux make gcc rpm-build
curl -o openssl-1.0.2k-21.el7_9.src.rpm https://vault.centos.org/7.9.2009/updates/Source/SPackages/openssl-1.0.2k-21.el7_9.src.rpm
rpm -i openssl-1.0.2k-21.el7_9.src.rpm
cd ~/rpmbuild/SOURCES/
sed -i 's/secure_getenv(/getenv(/g' *patch
cd ../SPECS/
sed -i 's/%patch68 -p1 -b .secure-getenv/#%patch68 -p1 -b .secure-getenv/g' openssl.spec
rpmbuild -bb openssl.spec
cd ../RPMS/x86_64
rpm -U openssl-libs-1.0.2k-21.el6.x86_64.rpm openssl-1.0.2k-21.el6.x86_64.rpm

Build ca-certificates RPM:
Code:
yum install asciidoc java-1.6.0-openjdk
mkdir /dl/ca-cert; cd /dl/ca-cert;
curl -o ca-certificates-2020.2.41-65.1.el6_10.src.rpm https://vault.centos.org/6.10/updates/Source/SPackages/ca-certificates-2020.2.41-65.1.el6_10.src.rpm
rpm -i ca-certificates-2020.2.41-65.1.el6_10.src.rpm
curl -o ca-certificates-2021.2.50-72.el7_9.src.rpm https://vault.centos.org/7.9.2009/updates/Source/SPackages/ca-certificates-2021.2.50-72.el7_9.src.rpm
rpm2cpio ca-certificates-2021.2.50-72.el7_9.src.rpm | cpio -idmv
cp certdata.txt ~/rpmbuild/SOURCES/
sed -i 's/Version: 2020.2.41/Version: 2021.2.50/g' ~/rpmbuild/SPECS/ca-certificates.spec
rpmbuild -bb ca-certificates.spec
cd /root/rpmbuild/RPMS/noarch/
rpm -U ca-certificates-2021.2.50-65.1.el6.noarch.rpm
 
Back
Top