Sonicwall DPI-SSL Certain Sites - Self-Signed Certificate Error
MacGyver
Newbie ✭
TZ-370 SonicOS 7.0.1-5030-R2007
This issue has been replicated using two different Sonicwalls on different ISPs. DPI-SSL is enabled, and the Sonicwall DPI-SSL certificate is loaded in the Trusted Root Authority on the workstations as well as in Firefox.
If you go to most any secure site, you will see the secure site icon in whatever browser you're using, and it will indicate that the certificate in use is the Sonicwall certificate, just as it should be. However, there there are sites like: https://www.intitleclosing.com
IfI try to go to that site from at least two different Sonicwalls, I can get there fine with DPI-SSL disabled, but when enabled, it will cause:
www.intitleclosing.com uses an invalid security certificate
The certificate is not trusted because it is self-signed.
If I go to view the certificate error, I will see a certificate for *.intitleclosing.com and one for SonicWALL Firewall DPI-SSL.
Now if I go back there with DPI-SSL disabled, the certificate shows valid and issued by DigiCert.Other sites work just fine.
Anyone seen this?
Best Answer
-
CORRECT ANSWER
Larry
All-Knowing Sage ✭✭✭✭
@MacGyver if you are registered at SonicWall University, take the 15 minutes to view "Client DPI-SSL Troubleshooting Part 5"
It is a truly wonderful - and for SonicWall - straightforward explanation of the steps necessary to resolve this. I realize now that the KB article didn't cover it in detail (or the same way).
Larry
0
Answers
@MacGyver Yes, this happens frequently (a minor pita, actually).
Review this KB article:
Scroll down to the heading Certificate Errors in Browsers - Self-signed certificate for actions to take.
Hope that helps!
Larry
@Larry
First, thank you for taking the time to reply. Yes, a pita indeed, but I'm not sure I agree with minor. Ugh. I did import the certificate from that site, but no joy. Same issue.
I love how the way to really fix it according to the article is through the diag page and, "not recommended."
Any idea why this cert isn't being processed? Yes, I did bounce the wall after import.
@Larry thanks again. That is truly a great video; however, it just made things more perplexing. First, it confirmed that I did import the certificate correctly. Secondly, and perhaps more importantly, it confirmed that the root certificate was already in the Sonicwall certificates as part of the software as confirmed by the DigiCert Global Root CA Certificate Serial Number. I would bet that if you go to https://www.intitleclosing.com and view the certificate, you'll see that it exists in your Sonicwall as well.
Yet we still get the error. Any idea at all how that can be happening?
Well, even though it's not the way that Sonicwall shows to do it on the Sonicwall University video on the subject, or in the Knowledgebase Article, two of the three certificates in the chain had to be added. The third one alone won't work, the top one alone won't work, but the top and middle will. Good thing because the bottom one expires every 30 days.
SW says only the root is necessary which would make sense, but that's not the case.
Thanks for the help.
@MacGyver the problem with the specific site you mentioned is, that the server is not returning the intermediate Certificate for "DigiCert TLS RSA SHA256 2020 CA1". That's a common problem if the admin of the webserver is not paying attention.
I didn't tested it in detail, but in this case the "middle" Cert should be the only one which has to be imported into the Appliance, because "DigiCert Global Root CA" is already in the certificate store of the Firewall.
If you have any contact information you should send them a note to configure the certificate chain properly which their webserver is providing.
--Michael@BWC
@BWC thanks for the insight. It must be a common problem as adding that middle certificate also fixed another mortgage banking site. As for contacting them, it's like trying to herd cats. The mortgage world is a prime target for scams, fraud, and bad sites, yet they invite it with deplorable security. At one time we tried to enforce strict SPF as that would literally wipe out the vast majority of the scams our clients get. However, the big banks are the worst offenders. If you enforce SPF, you will miss lending packages from the largest banks as their mail is coming from servers that are not listed in their SPF records. When you try to contact them, you never get beyond some CSR in their banking center who couldn't spell SPF.
Sorry. End rant.
I appreciate the insight and will pass it along to the senders.
Experiencing Sonicwall DPI-SSL issues with self-signed certificate errors on specific sites. Despite implementing DPI-SSL, encountering challenges with certain websites triggering self-signed certificate errors. This poses a potential security risk and disrupts seamless browsing. Requesting assistance to resolve this issue promptly, ensuring DPI-SSL functions effectively across all sites without encountering certificate errors. Any insights or guidance on adjusting settings or troubleshooting steps would be greatly appreciated. Seeking a solution to ensure secure and uninterrupted access to all websites through Sonicwall DPI-SSL.