1 2 Previous Next 10 Replies Latest reply on Nov 29, 2011 8:38 AM by ittech

    Still problems with HTTPS


      We are still having issues with DNS and I just have a question.


      I understand there is a problem with the MWG7 resolving HTTPS URLs to IPs, but if we are hosting the DNS zone on our server that the MWG7 is pointing to for DNS should there still be a problem?


      We are set up in Transparent Mode, btw.



        • 1. Re: Still problems with HTTPS
          Jon Scholten

          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 ( in a transparent setup:

          -CONNECT Phase: URL.Host =*

          -CERTVERIFY Phase: URL.Host =, 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.



          • 2. Re: Still problems with HTTPS

            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.


            Message was edited by: ittech because I can't spell straighten :P on 11/7/11 1:30:48 PM EST
            • 3. Re: Still problems with HTTPS
              Jon Scholten

              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...



              • 4. Re: Still problems with HTTPS

                As an example users are trying to go to https://www.mcafee.com (IP


                - 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 they get through just fine.


                I've rectified the situation by adding the Destination.IP is 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.

                • 5. Re: Still problems with HTTPS
                  Jon Scholten

                  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).



                  • 6. Re: Still problems with HTTPS

                    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.


                    **https://www.hsmv.flcjn.net** - doesn't work unless IP is set for stop cycle


                    **https://david2.hsmv.flcjn.net** - works


                    Message was edited by: ittech on 11/7/11 2:41:34 PM EST


                    Message was edited by: ittech on 11/7/11 2:42:05 PM EST
                    • 7. Re: Still problems with HTTPS
                      Jon Scholten

                      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)?



                      • 8. Re: Still problems with HTTPS

                        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.

                        • 9. Re: Still problems with HTTPS

                          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  

                          1 2 Previous Next