Sounds like there is a bit of confusion here. There isnt any problems with DNS resolution for HTTPS requests.
The client (in a transparent setup) will make a connection to the IP of the server on port 443, Web Gateway will intercept this connection. At that point it will only know the IP of the destination server. This is considered the "CONNECT" phase of the connection (in regards to Web Gateway). During this CONNECT phase the Web Gateway will typically then enable certificate verification (CERTVERIFY), at which point it will attempt to initiate its own connection to the server to determine who the server is that the client is communicating to.
This CERTVERIFY phase allows the Web Gateway to look at certificate information, such as the common name. Typically after the certificate verification phase has taken place, content inspection would take place, this allows for inspection of full URLs, etc..
Here is an example of what might happen when you go to https://www.mcafee.com (18.104.22.168) in a transparent setup:
-CONNECT Phase: URL.Host = 22.214.171.124*
-CERTVERIFY Phase: URL.Host = 126.96.36.199, SSL.Server.Certificate.CN = *.mcafee.com
*Some browsers use SNI (server name indication), which may change the URL.Host in the CONNECT Phase.
Hope this helps or is on the right track in understanding the issue. I tried to keep this simple, so forgive any gaps in explanation.
Sorry, just trying to straighten things out in my head.
At which point does the issue of not being able to connect to HTTPS sites properly happen, the CONNECT phase or the CERTVERIFY?
Or is it that the clients don't properly pass on the IP address?
Thanks a lot, Jon.
Well I guess I would wonder what is the results that the user see's (what error page do you see).
But this could happen during the either, depending on the configuration.
What are some of the symptoms you are seeing? Like blockpage, access log entries, etc...
As an example users are trying to go to https://www.mcafee.com (IP 188.8.131.52)
- I have specifically allowed all access with URL matches *.mcafee.com*/Stop Cycle before authentication takes place (so anyone anywhere can get to authenticated or not)
- These users have a 13 TTL session so that they can never be disconnected from the site due to reauthentication
The clients are getting a generic "cannot display this webpage" screen from IE
Also, if they try to visit https://security.mcafee.com (IP 184.108.40.206) they get through just fine.
I've rectified the situation by adding the Destination.IP is 220.127.116.11/Stop Cycle to my rule set. I just don't know if the www.mcafee.com server rotates it's IP and the rule may not work tomorrow
If you let me know which logs to look at, I'll definitely sort through those.
This sounds like an authentication issue, what is the TTL for the auth server session? You said 13 TTL, but what metric (seconds?) ?
It sounds close to what we talked about in https://community.mcafee.com/message/164724.
What are the actual examples for your test? I'm wondering if it has to do with the CN or the redirect after the authentication (reason for the "Fix Hostname" rule).
Oops, sorry. 13 hours. It is the same problem, I was looking through the old posts, too for ideas
The actual examples are state criminal justice websites that you can't access without a proper certificate.
- doesn't work unless IP is set for stop cycle
** - works
Message was edited by: ittech on 11/7/11 2:41:34 PM EST
Is this a once a day type of issue, or is it reproducible any time?
I wasnt able to get to either of those sites. My goal was to see if the certificates used for their servers had wildcards in the CN.
You could attempt to perform rule engine tracing to see what the issue is as well. What type of transparent setup do you have (wccp | bridge | router | sidewinder)?
Like I said, it's a state criminal justice site so it wouldn't surprise me if they had some pretty tight ACLs. I'll try to access the site's certificate from here. We have a transparent bridge, sorry.
Ok the two certificates from each site look the same. One is just issued to www and the other to david2, no wildcards, other than that they are alike. The root path is the same also.
Not sure if I can reproduce the issue right now, as I would disable my other users too