10-27-2020 08:22 AM
Since all public CA's are not supported for decryption. How can we skip the decryption rule for those not supported so we have less tickets and lesser bad reputation. We can't have the list of all the websites from these unsupported CA's.
10-27-2020 08:58 AM
What I did was create a Custom URL Category, Lets call it "SLL work arounds". I then apply that in my decryption policy, lets call that "No-decrypt work around". Make sure you go to the Options tab for the rule and set it to "No Decrypt", and set the Custom URL in the Service/URL catagory tab. So when I come across a site that doesn't decrypt properly, I just add the url to the "SSL Work arounds" policy. So say www.badSSLplayer.com is throwing a browser warning, i'll add *.badSSLplayer.com to the list.
Just another I.T. Guy
10-27-2020 10:22 AM
@VincentPresogna I am also doing the same and bypassing decryption for those I come across. The issue is for our organization we can't limit access much to what users can access, and the userbase is also large. The decryption issue with websites keep popping almost everyday for some particular CA's, although it was implemented 8 months ago. Users don't mind if it happens once in a while, but if it keeps happening everybody including management looks as if we don't know what we are doing.
10-27-2020 10:32 AM - edited 10-27-2020 10:34 AM
@raji_toor I see we are in the same boat then, so to speak. Luckily for me, my user base is relatively small and rarely come across this issue much any more since I implemented decryption. Would be nice if maybe there was an EDL that could do this. But this poses the question, how to populate the EDL FQDN's of known decryption offenders.
Just another I.T. Guy
10-27-2020 10:42 AM
@VincentPresogna you can use domain url list for EDL, that eases the operation but still it still is an issue not knowing what domains to be added. This is why if it can be done on the basis of a CA would be nicer.
10-27-2020 12:11 PM
I definitely wouldn't whitelist based off of URL unless you actually have a valid reason to do so, it simply takes too much time. If you run into a CA that isn't natively trusted by the firewall you can still import the CA's certs as a trusted CA which will allow you to bypass this issue. I would only actually whitelist based off of the actual domain if you don't actually trust the CA for whatever reason.
10-30-2020 08:33 AM
10-30-2020 09:24 AM
@BPry Just as an example.. When logged in on support.dell.com and clicking an open SR gives the SSL error on (https://pf.us.dell.com/). I have imported both
'Entrust Certification Authority - L1K'
'Entrust Root Certification Authority - G2'
As i remember PA does not support Entrust, and this is also one of the reason for firewall to not do decryption on all Entrust issued certificate websites. We should have the capability to make that choice.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!