7 Replies Latest reply on May 25, 2015 3:20 PM by nathancc

    CRL checking fails through firewall


      I have an odd issue that started awhile ago.

      When using https through IE, especially with joining a webex, I have started getting failures because the browser cannot check the certification revocation list (CRL).  If you look at the certificate and copy  the URL for the CRL into the browser, it gets the CRL just fine, but it WILL NOT retrieve it when you are browsing normally or using Webex in the browser.  In Webex you see this when you go to join a meeting but you cannot.


      The odd thing is that it works with some sites (automatically) but not with others. It appears to cut acrosse multiple certificate vendors and web platforms.


      I do not have this problem unless connecting through the firewall.


      It happens on Chrome, IE 9, 10 and 11.


      On IE, unchecking CRL check option under the advanced tab fixes it. Having said that, I want to check for CRLs and do not want to use this work around permanently.


      Anybody heard of this?



      Dan Sichel  

        • 1. Re: CRL checking fails through firewall

          Can you paste the audit entry which shows the firewall is blocking the clients from retrieving the CRL?

          Can you see in tcpdumps that the client does a request to the URL for the CRL and it hits the firewall on one interface and does not go out the external?


          Are you doing non-transparent browsing or transparent?

          Are you using SSL-decryption at all?

          Is there any way for us to reproduce this easily ourselves?

          • 2. Re: CRL checking fails through firewall

            I cannot paste the audit event or tcpdumps. Happens encrypted and the firewall log is not showing any evidence that it is blocking it. That is why i am struggling to diagnose this.  BUT, if you take a laptop, connect via our corporate lan (through the firewall) you get this issue. Same laptop moments later connected via DSL not through firewall, no issue.


            both transparent and non-transparent to varying destinations. Problem appears to occur with both.

            not doing SSL decrypt at all.

            Don't know how you might reproduce it unless you have it happening too.


            Sorry for the difficulty on this, it is just weird and frustrating. I wish I knew/could do more to provide useful info on this.


            Any suggestions or hints or anything would be much appreciated.


            Dan Sichel

            • 3. Re: CRL checking fails through firewall

              We had a similar problem with webex and CRL's, but I'm not sure if it matches up completely to what you are describing.  We require our users to authenticate themselves when they access the internet.  When joining a webex, the CRL lookup failed the authentication check and prevented the users from starting the webex.  We would see the attempt hit a failed authentication deny rule, however.

              1 of 1 people found this helpful
              • 4. Re: CRL checking fails through firewall

                Did you ever resolve the issue? Webex told us to turn off CRL checking, which while it worked, is not exactly the outcome we want.

                • 5. Re: CRL checking fails through firewall

                  We found the CRL checks going out to a few Akamai servers at and  The requests were proxy aware, so they were hitting a rule that allowed non-transparent HTTP traffic, but required authentication.  The webex app wasn't able to process the auth request for the CRL checks, so the traffic wasn't allowed out.  We created a rule to allow unauthenticated HTTP access to those IP's, which resolved our issues.  Luckily, those IP's haven't moved around on us so far, but I'm sure will be different based on your location. Hope this helps. 

                  1 of 1 people found this helpful
                  • 6. Re: CRL checking fails through firewall

                    Thanks, that does help.

                    • 7. Re: CRL checking fails through firewall



                      I had this same issue, but we are using McAfee Web Gateway for Proxy.

                      I'm in Brazil and it seems we are hitting the Akamai IP's, and for CRL.