Hi, one of my certificates was renewed yesterday and we’ve had auth problems today. I noticed that the cert has been issued by R3 instead of X3 and tracing it back to Let’s Encrypt - I found this thread that says that some clients might be ignoring the new intermediate.
Looks like the community edition client might need to be updated?
I’ve tried installing the new intermediate R3 issuer on the client but no luck. The certificate isn’t getting accepted.
Hi, can you elaborate more on what you mean by auth problems?
We don’t embed the intermediate certificates and instead just use what Lets Encrypt give us.
If you scan your site will Qualsys SSL checker does it complain about the cert chain?
Some browsers cache the chain and get briefly confused when the intermediate changes.
We use Certify the Web to create and deploy a certificate that is used by our internal mail server (hmailserver). We use Thunderbird as the mail client. We’ve never had any certificate trust issues before but all of a sudden, all clients began to throw up a security exception confirmation with the message “the certificate is not trusted because it hasn’t been verified as issued by a trusted authority using a secure signature”. I checked the server and found that the certificate had been auto renewed the previous day. When I didn’t recognize the issuer, “R3”, I followed the trail to the Let’s Encrypt site and found the other thread where you’d responded. I’ve tried renewing the certificate a few times but the result is still the same. Thunderbird stubbornly refuses to accept it without confirming a security exception which I’d rather not train our users to do! Since it’s an internal server, I used Digicert’s certificate checking tool (digicert.com/util/) which is able to retrieve the certificate without any errors.
I’ve even force installed the new intermediate R3 (and the root X3) on a test client but the result is still the same. I’d like to dismiss it as a Thunderbird issue, but nothing’s changed on the client as well and it’s impacting everyone at the same time. Is there anything else I could provide to help identify the cause?
So your cert should currently have the chain
DST Root CA X3 > R3 > Your cert.
When you export the cert to use it with hmailserver how do you do that?
When you verified the cert with the digicert tool, did you use the original PFX that Certify generates or did you use your exported/converted cert that you use for hmailserver?
Here is an example of how another user exports to hmailserver: Hmailserver and new version 5 CTW
It’s not impossible that we have a bug but if we do it would be more likely to be related to a specific export as these are less commonly used than the core cert renewal functions.
Hi, I just got it working. I’d mentioned that I had manually imported both the Root CA X3 and R3 certificates into a test client’s machine store and Thunderbird still wouldn’t accept it.
Finally I tried importing the R3 certificate directly into Thunderbird’s list of Authorities and the exception finally stopped. Shouldn’t this be done automatically? I’ve never imported any certificate into Thunderbird like that before.
Thank you for the hmailserver config help, as I mentioned, we’ve been successfully using it for a while. I’ve even configured Certify the web to change the certs on hmailserver as a task
As for Digicert test, yes I did use the PFX genertaed by Certify which is stored without a private key.
I think the certificate chain .pem file (I presume hmailserver only allows one file) needs to contain the elf/end-entity cert (for your domain, the intermediate cert and possibly the root cert. Certify has several Deployment Task options available for different types of export, for instance the ‘Generic’ Server’ export will output 3 files: your cert, the chain and the private key. You may need to concatenate the cert and chain into one pem file (your cert first) or you can try to ‘Export Certificate’ task and choose ‘full chain’ to get one file with everything.
Looking at my own copy of Thunderbird I can see that it has the old X3 certificate in the trust store, which would explain why that has not been an issue so far:
Note also the Let’s Encrypt are transitioning to their own ISRG X1 root in January, and that cert is also in Thunderbirds store.
Ah that did it! I used the Export certificate task and selected the Full chain PEM option and created an additional CRT file for hmailserver.
Thunderbird added the R3 under DST this time. When I imported the R3 directly, it was shown under ISRG.
The kind of options you’ve built into Certify is just awesome. Thank you very much!
Excellent glad you got it working. I’ve added a general note on the Let’s Encrypt forum for people experiencing issues with Firefox or Thunderbird.
For people coming here because of the Let’s Encrypt R3 & DST Root CA X3 expiry please see Let's Encrypt DST Root CA X3 expiry Sept 30th 2021 | Certify The Web Docs