Let's Encrypt Certificate Chain Imported From PFX - Certificate Can't Be Verified
REF: SonicOS API Endpoint for Importing SSL Certificate
As I've been working on trying to automate my process of managing the SSL certificates for my domain's endpoints, I've been working on trying to get the certificate issued by Let's Encrypt imported into my SonicWALL device via the SonicOS API. Based on the linked thread, I believe I should soon have the import process working normally, but I'm still encountering a potential issue that I'm not sure quite how to resolve just yet. When I manually import the certificate chain PFX file, everything appears to come in just fine, but when I look at the site certificate's details through the SonicWALL's UI, it indicates that the certificate's status is "Not Verified - Loaded but could not verify certificate" (see image below)
Per the conversation in the linked thread, the thought was that perhaps the issue was because the CA certificates had not been imported. Since I initially just had the PFX file, I went back and had my system regenerate the certificate as component PEM files - one for the cert, one for the key, and one for the certificate chain. Then I tried to import only the chain file, but I got a message that said that the certificate had already been imported.
I looked at the certificate path for a second site where I've already deployed a Let's Encrypt certificate to try and determine what specific CA and intermediate certificates I needed to load, then went back to the SonicWALL UI. From what I can see, it appears that all of the certs in the chain were imported, so I went ahead and just deleted all of them. From there, I went ahead and re-imported the PFX file through the UI. The two CA certificates popped back in there, but the site certificate still shows that it's "Not Verified" (see image below).
I am generating the site certificates through the Certify SSL/TLS Certificate Management application from Certify The Web. I'm not (currently) generating a CSR from the SonicWALL appliance, but instead allowing the Certify application to automatically generate its own private key/CSR to request the certificate from Let's Encrypt. I've not yet tested generating the CSR from the SonicWALL to use for submitting the request, but that will probably be my next troubleshooting step. Of course, that may also mean that I have to change the API endpoint I'm using to import the certificate, but I'll deal with that if the need arises.
One "odd" thing I noticed was that the root CA certificate (the one for ISRG Root X1) is showing an expiration date of 30 September 2024 in the SonicWALL management UI, but when I look at the certificate details by accessing the chain through a browser, it shows that the certificate is valid until 4 June 2035 (see image below). Again, I'm not sure if that has anything to do with the certificate "verification" that the SonicWALL is trying to do, but it's something I wanted to at least mention to add as much context as possible. But, for now, that's all the information I have on this "issue".
Best Answer
-
G_Hosa_Phat Newbie ✭
Well, I guess it was the root certificate. I found this KB article Imported Certificates Not Validating and went through the recommended steps of exporting the CA certificate from my browser to a
.p7b
file. I deleted and reimported the CA certificate (using the file generated from the intermediate certificate) through the SonicWALL UI and the site certificate that was showing as "Not Verified" now shows as "Verified". I'll take it, but I'll take this to the Certify developers as a potential "issue" for them to address. Consider this issue resolved.1
Answers
UPDATE/FOLLOW-UP: After posting in the Certify the Web community forums (ref. Let’s Encrypt Certificate Chain Issues On SonicWALL), I found that the issue with the root CA certificate is caused by Let's Encrypt using an old, now expired chain for backward-compatibility (Additional explanation/detail: Let's Encrypt DST Root CA X3 expiry Sept 30th 2021 | Certify The Web Docs). By changing the "preferred chain" setting in the Certify application to explicitly use ISRG Root X1, the issued certificate's PFX appears to have everything correct.