Yes you are correct @MikeMcQ the client experience the same issue while accessing the https://letsencrypt.org
3 Likes
@MikeMcQ Any idea how I can fix this issue
2 Likes
Clearly a client problem then.
Try searching through this forum for that specific client and that error message.
2 Likes
There are some possible complex Windows cert store updates for your client's Server 2008. But I do not know Windows well enough. Perhaps @rmbolger or @webprofusion will have ideas. Or, as Rudy suggest, search this forum for that client system. They have problems reaching any site using the "long chain" from Let's Encrypt so may want help for a proper fix.
Without that, I can think of two options
-
Change your server to send the "short chain". This should allow your Windows Server client to work but will then not work for people using older Android clients. See this topic Long (default) and Short (alternate) Certificate Chains Explained for more details of this tradeoff and setting the short chain. You would also need to update your Certbot to a snap install to get a version that supports the preferred-chain option. Or you could make the short chain with manual edits - ack. You can confirm the short chain would help your Windows Server client by having them try this link: https://valid-isrgrootx1.letsencrypt.org If that works changing to short chain will help them - at least.
-
Use a different Certificate Authority like ZeroSSL or another free CA. This is sometimes needed if you need to support a wide variety of older clients. See this topic for how to change Certbot to do that. This may well be the most painless option in this case.
3 Likes
Okay, should you find a direct link, please share it here
2 Likes
I will try the second option and update you on the outcome
3 Likes
I'd guess the client OS doesn't currently have ISRG Root X1 in their Trusted Root certs store. They can check visually using certlm.msc or run the following PowerShell command:
Get-ChildItem Cert:\LocalMachine\Root\CABD2A79A1076A31F21D253635CB039D4329A5E7
If it's not shown in the GUI or there's an error with the PowerShell command, the cert is not trusted and needs to be downloaded from here (HTTPS) or here (HTTP). Then from certlm.msc, expand Trusted Root Certification Authorities\Certificates. Right-click the Certificates folder, select All Tasks > Import and follow the wizard to import the file you downloaded.
5 Likes
That's a catch-22.
I'm pretty sure it's unwise to download root certificates you're about to give full trust to through HTTP.
It's probably better to download it from a HTTPS site not using ISRG Root X1 itself as the trust anchor, such as crt.sh | 9314791
3 Likes
The crt.sh link would work as well. But the links from Let's Encrypt owned sites might seem more trustworthy to some. And since it's a certificate with a well-known thumbprint, it's easy enough to verify the file you downloaded was the one you expect regardless of where it came from.
4 Likes
If you're verifying the thumbprint anyway, the location from where you got it doesn't matter 
Which of course is very wise, verifying the thumbprint 
4 Likes
It appears LE renewal didn't go quite well as fullchain.pem was missing.
After deleting the existing certbot and removing the LE folder and subfolders
I followed the instruction on here - Certbot Instructions | Certbot
And the site is working just fine at least on my end.
I will wait for my client response and I will update
2 Likes
I noticed the fullchain.pem file is missing after the auto renewal which must have caused some machines to have issue verifying the SSL cert.
2 Likes
Probably not, I checked your site earlier and it was serving a perfectly normal chain..
3 Likes
That was the error apache2 was giving me on command line
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.