HTTPS Proxy - getting a lot of sites that we can't access because SSL cert is bad?
Sometime today my users started getting messages when browsing to some websites that the sites are not secure, and it seems that the SSL certificate isn't valid. In one instance I clicked on the link anyway and it blocked me from accessing a site in Singapore (we have that country blocked).
I upgraded from 12.3.1 to 12.5.1 yesterday (M370).
The firewall is blocking them.
Anyone else seeing this on 12.5.1?
0
Sign In to comment.
Comments
If you are using HTTPS with DPI enabled, that will have enough times to be really frustrating, but not enough times to stop using DPI.
What specific sites got blocked, and if it's a country you block with Geolocation, do you really care?
Gregg
Gregg Hill
Did some testing after reading a report about recreating the rules after upgrading to 12.5.1 around October. That didn't fix it, but if I disable Geoblocking for the rule then all websites work properly. The websites were already located inside the USA, so it appears to be something to do with Geoblocker.
What it actually says is that the website (some.remote.site) has an SSL certificate for (our ssl cert installed on the firewall). So, basically something related to geolocation screws with HTTPS and causes it to get our SSL cert (installed on the WG firewall, been on it for a year, 2 years left) instead of the outside websites SSL cert.
Sometimes you'll get cert warnings when the sites certs are using weak encryption or they have missing intermediate certs. You can check a site's cert using https://www.ssllabs.com/ssltest/analyze.html or other SSL test sites.
Gregg Hill
Yea, this isn't because the remote site has a SSL problem, most of them are banking sites, 2048, still good for 3-5 years, etc... Once I disabled GeoBlocking it works properly on all SSL sites.
I've only upgraded 1 client to 12.5.1, so I think I'll wait a few weeks before I do any others.
If Geo blocking was the problem, those sites are using something on them in countries you were blocking. It could be something as simple as an image. It also could be China spying on the banking web site. The latest as of Nov 14th is 12.5.1 Update 1.
Gregg Hill
Sorry, I did the 12.5.1.U1, downloaded it yesterday before the update. I tried all the fixes noted in another thread - the most common fix was to delete and recreate the rule - I disabled it and made a new one, and that didn't fix it. I disabled GB and that was the only change after that test, and now it works, but the logs show it's not trying to reach singapore or any non-US location. Looks more like a bug in the GB lookup for SSL proxy rules - we also have dual WAN connections if that makes any difference.
Mark
What happens if you step through the cert warning ? With GeoBlocked requests, denied traffic has to be redirected to the Firebox so users get the Geo deny message (where it functions in the filtering flow).
With HTTPS sites, this throws in the Firebox's self-signed cert into the mix hence the cert warning.
You can test this theory out with http://mail.ru and https://mail.ru
Ralph, I'll test this later today, have a conference call in 5 minutes - thanks for thinking about that. We normally add a customer cert to the firewall so that they don't get a warning when they authenticate with the firewall.
A custom Firebox web server certificate won't make a difference here. Users will still see a warning because the certificate cannot be validated. The requested URL/domain is compared to the Subject in the Firebox's web server certificate.