I have successfully been able to import my Let’s Encrypt certificates into IIS for both a basic website and an RD Gateway server, as well as into my WS_FTP server using the PFX files created by the Certify application. Those systems seem to handle the chain without a problem and the certificates can be used without any further “intervention”. However, when I import the PFX on my SonicWALL appliance, the root and intermediate CA certs are imported as a part of the chain, but the site certificate indicates (in the management UI) that it can’t be verified. See the reference link at the end of this post.
In my troubleshooting, I looked at the certification path details for one of my active Let’s Encrypt certificates and compared them to what was showing on the SonicWALL. When I looked at the details of the ISRG Root X1 cert, I noticed that the expiration dates didn’t match (the “active” one showed an expiration date of 4 June 2035, while the one that was imported into the SonicWALL showed an expiration date of 30 September 2024.
Following some troubleshooting suggestions from one of their KB articles - Imported Certificates Not Validating - I exported the ISRG Root X1 cert from my browser and deleted/re-imported that into my SonicWALL. Doing that seems to have resolved the issue and the site certificate is now listed as “Verified” in the management UI.
This, however, brings me to the question of why the ISRG Root X1 certificate imported from the PFX has a different expiration date while both the site and intermediate certificates seem to be fine. It also “concerns” me because I’m trying to automate the SSL renewal and installation process and I’m wondering if I’m going to have to include steps for retrieving (e.g., download the ISRG Root X1.der file from http://x1.i.lencr.org/) and re-installing the ISRG Root X1 certificate as a part of the application I’m building to handle this automation.
REF: Let’s Encrypt Certificate Chain Imported From PFX - Certificate Can’t Be Verified — SonicWall Community
So there are actually two valid ISRG Root X1 cert in play:
ISRG Root X1 (self signed, June 4th 2035)
ISRG Root X1 (cross signed by DST Root CA X3, Sept 30th 2035 )
The default chain that Let’s Encrypt uses when providing you a certificate is Your Cert > R3 > ISRG Root X1 (issued by DST Root CA X3) > DST Root CA X3 but a quirk of Windows is that DST Root CA X3 is no longer trusted (it expired last sept, so that’s ok). Instead Windows sees your installed ISRG Root X1 and terminates the chain at that cert.
For various reasons this all works ok for most current operating systems. To get the more sensible chain (without reference to the expired DST Root CA X3), edit your Let’s Encrypt account settings in Certify The Web and enter “ISRG Root X1” as your ‘preferred chain’ (under Settings> Certificate Authortities> edit the account settings, preferred chain is on the Advanced tab). Next time you request the certificate it will build with the correct path.
By default, this doesn’t really matter on windows (because windows does it’s own thing with the chain) but when exporting the cert and using it on other operating systems it does matter.
For more background see: Let's Encrypt DST Root CA X3 expiry Sept 30th 2021 | Certify The Web Docs
Basically, Let’s Encrypt chose to default to the old chain for Android compatibility, it’s a bit weird.
1 Like
Thank you so much, @webprofusion ! I had read that article about the DST RootCA X3 expiration - which is where I found the direct link for downloading the “new” ISRG Root X1 - but I apparently didn’t make the connection with what I was facing. I must’ve missed the bit on changing the setting in the Certify application, but I’ll make sure to get that implemented going forward. I remember seeing the setting when I was putting everything together, but I skipped over it at that point. I’m so glad the solution is a lot simpler than I was (over-)thinking.
1 Like