A slightly longer answer is that any SSL/TLS endpoint that is going to decrypt and authenticate incoming HTTPS connections MUST have a certificate because it's the cryptographic identification and authentication of a peer. If an SSL/TLS server you're connecting to claims to be 'www.example.tld' it must present a certificate (preferably signed by a trusted third party so it verifies correctly) with a CN (common name) 'www.example.tld', otherwise the SSL/TLS handshake will be aborted if the server can not present such certificate.
All I can suggest here is starting a bounty for a complete package rewrite. Apparently noone will touch the current buggy code, since it's completely unreadable mess. Unfixable.
Alternatively, get some blocklists in Squid's ACL format and use those.
(And, FWIW, about 99% sure this has completely nothing to do with "Bypass Proxy for These Source IPs" or any other Squid configuration. If you cleared whatever other fields, or simple re-saved the Squid config without doing any changes whatsoever, it'd have the same effect (restarting services, reloading firewall, working again until it breaks for god knows what reason…)
It is intercepting just fine. Recently discussed in the proper forum. If things break, use the manual config, or don't MITM.
apologies if I wasn't clear in my post - I am not implementing MITM and have never enabled it. It would appear that while all other SSL traffic bypasses the proxy just fine (as intended), this one API call with the :443 appended may indeed be SSL but is attempting to go through the proxy.
I found the setting in pfblockerBg that you where talking about but i could not work out what you meant by Force Reload all.
Click the Update tab.
Ok thanks done… Just a quick question before i install squidguard again how do i change the lists in squadguard once its installed encase I would like to add or remover rules on the lists.
