SonicWall and Expiring Let’s Encrypt Certificates
Enzino78
Enthusiast ✭✭
Hello Community, has anyone of you facing problems appliying DPI-SSL due to root CA for Let’s Trust certificates, IdenTrust DST Root CA X3, had expired at 00:00 UTC on September 30th?
I found this warning page issued by Fortinet, while nothing posted by SonicWall.
Thanks, Regards.
Category: Entry Level Firewalls
0
Best Answer
-
CORRECT ANSWER
CFuertbauer
Newbie ✭
You can import the ISRG Root X1 certificate (e.g. from your desktop)
We recognized that the build-in ISRG Root X1 does not work correctly.
0
Answers
A client site contacted me on Friday about this.
As a workaround, I cleared the HSTS in Chrome on the one computer that had to get to the two affected websites.
Would also like a better - more secure - approach.
They really should have posted an article about this. I raised a ticket and got 5 paragraphs about this issue which obviously weren't written just for me, so why not stick it on the publicly-facing KB, saving my time and theirs in the process?
I, too, created a case and spoke with support (after a 25 minute wait). CSR had absolutely no understanding of what I was talking about, sent inappropriate KB articles, and generally wasted my time until I hollered that he needed to find out from someone else if he didn't know.
Here's what I got back:
The issue is related to Let's Encrypt. Let's Encrypt saw one of its root certificates expired recently, however to correct the issue they obtained a cross-signature from ISRG Root X1 for its own certificate that’s valid for longer than the signing root. Because of this change some clients may need to update, rebing or install this new certificate.
For a SonicWALL Firewall using DPI-SSL this can be accomplish by enabling the "Always authenticate server for decrypted connections" and then "Allow Expired CA" under DPI-SSL > CLIENT SSL, load the failing page, and then it should be safe to disabled this options again. Once this has been done the issue should be resolved for all pages affected by this problem. Another alternative would be to disable DPI-SSL and then Re-enabling it, although this change would be more impacting as it will reset the current proxy connections.
He insisted that the TZ had to reboot after any change to the DPI-SSL settings (which would have meant two). And yet, for my client affected by this idiocy, that was not necessary because the website that could not be reached came through within a moment of the change.
Hi,
I'm still struggling with this issue. I imported the ISRG certificate, rebooted the firewall, however the certificates still fails the verification.
Could it be that the older DST certificate creates a conflict? Is there a way to remove it?
Thanks,
Mickael
Issue fixed: I had two ISRG certificates in the stack. Removing the one calling the DST fixed the issue.