I removed, but it didn't help...
1 Like
The "fix" might need to be applied on the clients (not the server).
As for the server, this chain seems short:
---
Certificate chain
0 s:/CN=admin.nurso.com.br
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
---
It's shorter than the one used by this site:
---
Certificate chain
0 s:/CN=community.letsencrypt.org
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
2 Likes
How did you manage to solve the problem?
1 Like
Right, do you know how can I change this chain on IIS? Because I have installed the DST Root CA X3
back again but no lucky. Should I try to remove the Preferred Issuer from ISRG Root X1?
1 Like
That depends on the ACME client in use.
And the version of Windows.
And the version of IIS.
And the alignment of the planets...
Most likely though it should be as simple as adding/removing the cert from the cert store and either rebinding the cert to the site (in IIS) or rebooting (or both).
Search this site - there are other ongoing topics that more specifically address Windows and IIS.
2 Likes
For those with the problem, don't even look for a magic or elegant solution.
yum remove certbot
snap install --classic certbot
ln -s /snap/bin/certbot /usr/bin/certbot
certbot renew --force-renewal --preferred-chain "ISRG Root X1"
Some friends have already commented on the above solution for debian and family.
2 Likes
I'm using Win-ACME, Windows Server 2016, IIS 10 and well.. the align of the planets I'm not very well informed 
I already tried all of that, I think I'm looking for an answer at 12 hours now, I'm losing hope to find a solution to all devices. I saw many other threads, but I will try again.
Thanks anyway.
2 Likes
In Win-ACME, you can change the chain by modifying the PreferredIssuer parameter in the settings.json file.
If the parameter is set to null, ACME will get the long chain by default. If you want to use the alternate chain, you must set the parameter to ISRG Root X1.
Win-ACME needs to be in the latest version as well, since the previous version presents a bug that ignores the chain preference parameter.
2 Likes
It is at the last version of Win-ACME and I have set the Preferred Issuer to ISRG Root X1.
1 Like
When you open the Windows Server certificate management console in the Web Hosting directory, does the certificate show the long or short chain? This is what defines the chain used by the server.
Just to confirm: Have you issued a new certificate after changing the chain preference in the ACME configuration file?
The sheet certificate in Windows Server should look like this:
Short Chain:
Long Chain:
1 Like
This solution works for me.
in my scenario I have a loadbalance in digital ocean, as front of my servers. I setup loadbalance for "passthrough" certificate and so I follow the solution above in all servers and Goaaaaaallllll.
thank you so mutch!
1 Like
I see here only the Short Chain, not the Long.
And yes, I defined the Preferred before generating it.
1 Like
We have many sites using Let's Encrypt, all of which have the certs managed/automated through our hosting provider (no idea how they actually manage them; I just set them up through their dashboard). We've started seeing expired SSL issues on older devices starting today (makes sense from what I've read) but I am no SSL expert and I don't know what to tell our hosting provider to do or look into to fix it. Restarting the devices that are encountering issue has not fixed it for them.
Here is one of the sites having the issue:
https://vikings.1rmg.com
Thanks in advance for any help!
1 Like
I have a fix for my issue.
It turns out that what I needed was already included in my PFX file that I get from Certify the Web. I'm using an Apache Web Server, the server includes an optional Certificate File that can be included in the SSL Settings called the Certificate Chain File.
I created the chain file from the PFX using this command:
.\openssl.exe pkcs12 -in mycert.pfx -cacerts -nokeys -passin pass: -out chainfile.crt
Then I added that chainfile.crt file to the Apache Interface and restarted the web server. That instantly fixed the issue on all Apple devices and even the Edge browser on my windows computer.
I really hope this helps someone else out. I'm happy to share this info in other places and I'll probably be copy and pasting this guy to several threads on several different sites .
Good luck everyone!
2 Likes
Did you find the fix for OpenSSL? We're still experiencing this issue on a similar setup as you. Thanks!
1 Like
16.04 is close to the end of the road by now
even 20.04 which is what I am using only because I switched machines my web server
on my end I commented on openssl being updated in advance
1 Like
[I posted this separately, but then saw this thread]
My domain is:
https://crt.sh/?q=guardiandigital.com
I updates our certs just a few days ago:
certbot -d guardiandigital.com [-d all other domains] --manual --preferred-challenges dns certonly
My web server is (include version):
httpd-2.4.49-1.fc34.x86_64 on fedora34
The operating system my web server runs on is (include version):
fedora34
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 1.19.0
The problem appears to be with MacOS version 10.11.6 - El Capitan users using the latest Chrome or Safari.
What is the solution for these users?
Here's a screenshot from the MacOS system showing the expired root cert
1 Like
Something now kosher here:
---
Certificate chain
0 s:/CN=guardiandigital.com
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/CN=guardiandigital.com
i:/C=US/O=Let's Encrypt/CN=R3
2 s:/C=US/O=Let's Encrypt/CN=R3
i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
3 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Lines ZERO and ONE are duplicates.
Which implies the use of cert.pem and fullchain.pem [which includes the cert & the chain]
[but I could be wrong]
Please show the lines of code that actually use this cert (in httpd)
2 Likes
Hi @rg305, thx for the answer but it's ok problem solved.
The steps provided in my first post solved the issue. But I had two call to two differents API, and I solved the first one but the errors was still the same, but from the second server...
Thanks again, and sorry for the useless question 
3 Likes
Try installing the ISRG X1 Root from https://letsencrypt.org/certs/isrgrootx1.der using Keychain, into System Roots, then reboot for luck.
2 Likes