if no SSL Scanner is used the original certificates will be used. In case a Client requests an HTTPS Website we should see a CONNECT request which contains the requested URL - and this URL will be checked against your URL Filtering configuration just like HTTP requests.
In case there is no explicit proxy but transparent proxy setup MWG should extract the requested URL from the Certificate of the requested URL to get something to check against the URL Filter, so generally there is no action required to apply URL Filtering to HTTPS requests.
What is the problem you encounter?
We are using WCCP (transparent). When we send 443 to the web gateways with the SSL scanner turned off, they work okay if the user is previously authenticated. If they do not use the Internet for a few mins, then click on a desktop shortcut going to an HTTPS website, we get the default "Page cannot be found message" in IE. This message is from IE, it is not coming from the Gateway. If the user opens IE and browses to Google, then closes IE and clicks on the desktop shortcut to an HTTPS site, they get there no problem.
This must have something to do with authentication??
Here is my transparent authentication rule set.
I also noticed, in my logs, that all my CONNECT's are hitting IP addresses and not URLs. This is what is causing IE to throw a vertificate error.
Is it normal for transparent https requests to be CONNECTs?
if you do not browse for a couple of minutes and then start with an HTTPS URL your browser will be redirected to the Authentication Server. I assume this will cause a problem here for some reason when you redirect in HTTPS. Do you have the "Set Client Context" Event called anywhere in front of the Authentication Server? This may be required as MWG has to send the redirect within an HTTPS tunnel, since this has been requested by the End-User. If we want to modify the HTTPS response we have to use our own certificate in order to have something to encrypt the session, since we can´t modify the request within the SSL tunnel between Client and the Webserver.
This may be a reason. Can you have a look at
I think if you scroll down a little bit there is a similar problem described.
Yes, I did add the "Set Client Context" to my top level rule set. I have it set to Always. This did help some, but did not fix the problem.
I did more tests and it is definitely an authentication problem. I set up a special proxy port and service group (51) for only 443 traffic. I setup a special service group (51) in my Cisco ASA to only forward 443 for test users. Then I setup a special authentication server rule set just for SSL traffic. I have the SSL scanner disabled. I have "Set Client Context" set to always and it is before my authentication rule set.
If I turn the SSL authentication rule set on, I get certificate errors in IE if the user has lost authentication, after 6 mins. These are certificate address mismatch errors. If I disable "Warn about certificate address mismatch" in IE > Advanced settings, I do not get these errors and the page loads fine.
But, if I turn off the SSL authentication rule set, everything works fine and the traffic is being logged which means it is going through the gateway. The only difference is that there is no user name in the access.log file. This creates problems because now the user is not authenticated so my URL Filter rules that allow certain people to get to Web Mail are not being used and Web Mail is being blocked.
Must be something that can be done....
sorry for the late reply. Did you apply these steps:
https://community.mcafee.com/message/167503#167503 (the note by Jon Scholten) already?
I have to admit I am a bit lost because there is no much information but it is hard to work without examples. If the above steps won´t help I would strongly recommend that we file an SR for this topic to get this resolved. This will allow us to better work on a specific issue than from within the community.