SSL Error on Certain Websites behind pfSense

[jmo]

Similar to this post: SSL error on android when using pfsense

All devices are behind a Netgate 7100-1U running 22.01. Devices can visit all other websites without issue (that I am aware of). However, any device using any browser trying to go to either https://docs.google.com or https://github.com results in the following error (example is from Firefox only because it gives more detail):

ERR_SSL_KEY_USAGE_INCOMPATIBLE
github.com uses an invalid security certificate.
The certificate is not trusted because it is self-signed.
Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

When viewing the certificate, these are the certificate details:

Subject Name
Country:  CA
State/Province:  ST_DNSBL
Locality:  LN_DNSBL
Organization:  ON_DNSBL
Org Unit:  OU_DNSBL
Common Name:  CN_DNSBL
Email Address:  dnsbl@example.com

Seeing the references to DNSBL, I tried disabling pfBlockerNG, but the problem remains.

I am able to take the same device, disconnect from the network behind pfSense, connect to a 4G hotspot, and I can load the page fine. I don't see anything related in the firewall logs, Suricata has not blocked it. I'm out of ideas. I'm wondering if this is a bug with 22.01, as I've never had issues with these two sites until recently. Open to suggestions. Thanks.

[Gertjan]

@jmo said in SSL Error on Certain Websites behind pfSense:

ERR_SSL_KEY_USAGE_INCOMPATIBLE
github.com uses an invalid security certificate.
The certificate is not trusted because it is self-signed.
Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT

google.com or github.com would use "SELF_SIGNED_CERTS" as that will make a lot of noise.

The answer to that question will bring you very close to "who gave you (your browser) this certificate.
And you said it :

This :

@jmo said in SSL Error on Certain Websites behind pfSense:

Subject Name
Country: CA
State/Province: ST_DNSBL
Locality: LN_DNSBL
Organization: ON_DNSBL
Org Unit: OU_DNSBL
Common Name: CN_DNSBL
Email Address: dnsbl@example.com

info was typed in by some one. Like the admin of your pfSense; Or, to be more precise : whatever solution you use to do 'DNSBL'.

Long story short : IP's belong to github and Google are on your DNSBL lists.
So your browser is redirected to a local web server to tell you visited a domain (== an IP) that was blacklisted by the DNSBL admin.
Because that web server was suing a self signed (non trusted) cert, that 'blocked page' won't even show up.
Which boils down to : it's useless to use the option to have the browser redirected in the first place if a DNSBL hit occurs.
If your browser want to visit https://www.somewhere.tld and it get redirect to https://www.somewhereelse.tld, it will yell at you. Even if the cert that somewhereelse.tld gave you is valid, good date, etc. It will fail because that cert will say it's from "somewhereelse.tld", not from "somewhere.tld".
Conclusion : disable the usage of the "pfSense pfBlockerNG web server" that shows that an domain name was blocked **.

@jmo said in SSL Error on Certain Websites behind pfSense:

I tried disabling pfBlockerNG, but the problem remains

Solution : flush the DNS cache of the device you are using to visit google.com or github.com.
It has asked the upstream resolver (pfSense) an IP for these domains, and it got 10.10.10.1 (the default pfSense pfBlockerNG web server IP (which is useless as you now know).
The "10.10.10.1" will get cached for a while locally. So flush local cached DNS results and you'll be fine.

** it will work if the request was a "http" request. But these do not exist any more.

[jmo]

@gertjan

Yes, that makes sense. Did a packet capture, and the DNS request was returning 10.10.10.1.

I searched all of my blacklists for the FQDNs and IPs, but could not locate them. I ended up adding them to the Custom Domain Whitelist in DNSBL and restarting dnsbl and unbound, and now it appears to be working. Thanks for the assist!

[Gertjan]

@jmo said in SSL Error on Certain Websites behind pfSense:

but could not locate them

Sledge hammer solution : Disable pfblocker.
Do Diagnostics > DNS Lookup (check on pfsense, as his DNS cache would have been reset for sure).

Then reset your local cache, like

ipconfig /flushdns

If you have a Windows PC.

When you re activate, pfBlocker again, and the issue comes back, then you know it's a "how to search / what do I search / where do I search" issue ;)

[jmo]

@gertjan

Oddly enough, Diagnostics -> DNS Lookup returned the correct IP address prior to whitelisting. 10.10.10.1 only showed up in the pcap.

Also prior to whitelisting, I disabled pfBlocker and flushed the client cache and the resolver was still returning 10.10.10.1.

In any case, it's fixed. Thanks again.

[stephenw10]

Yeah, that's definitely pfBlockers DNS-BL returning the the single pixel it hosts.
Just stopping pfBlocker is not enough to clear the DNS lists from Unbound. You have to disable DNS-BL and save/apply that.

Steve