Trouble decrypting Google traffic

Showing results for 
Search instead for 
Did you mean: 

Trouble decrypting Google traffic

L3 Networker


we have some trouble with a lot of Google sites when we enable SSL decryption and also enable CRL and OCSP checks. We either get no response at all, or error messages like the one in the attached screenshot. If we disable the CRL/OCSP checks (which is undesirable I guess), then we have no problems at all. Google is the only destination we have these problems with and regarding to the system logs, the CRL list retreival is working fine.

Any ideas?




L5 Sessionator

If you look at the certificate that you get when you go to any google website like (click on the icon to the left of the address to view certificate info) you will see that the common name is *  Google uses this wildcard certificate for most of its sites.

Before decrypting the traffic the firewall only has the common name on the certificate to use for looking up URL category.  * is in the Search Engines category, so that's what the firewall identifies it as when you go to google sites like , or basically any other Google service.  Once you have decrypted the traffic the firewall can do the URL lookup based on the HTTP GET request for the website.

Best regards,

Karthik RP

Thanks, but it's not a problem of being blocked by firewall policy. It's a problem with the PAN checking Google's certificates.

See this:


As I wrote above, it must have something to do with checking CRL/OCSP in Device -> Service -> Session -> Decryption Certificate Revocation Settings.

If we disable the checks, it works fine.

Looks like the CRL/OSCP check is timing out - look at Status: timed-out and hence the error message. Can you verify if there is any network latency in retrieving the crl list or reaching the server itself?

As I said earlier, regarding to my system logs, there are no issues with retrieving the CRL lists. There is no timeout, and Google is the only destination that's affected. The "timeout" in the error message is indeed strange, but sometimes we get no error message at all.


L5 Sessionator

1>Can you  try to increase the timeout value for the settings under Decryption Certificate Revocation Settings : to max=60sec .

2>What is the Software Version installed on the firewall?

3>Can you attach the following log

>less mp-log sslmgr.log

Also following discussion may interest you:

Hello Nadir,

we are running 5.0.4. And I am seeing the same error messages in sslmgr.log that are described in the other discussion you linked to. So it's safe to assume we are hitting this bug as well. I will try to turn off OCSP checks. If I understand the bug correctly, it's only happening after turning on OCSP. What do you think?



Hello Sacha,

If you are seeing the same error ,its likely that we are  encountering the Bug referenced in the discussion that would be fixed with OS_5.0.7.


Thanks. Just for clarification: Isn't certificate revocation checking decoupled from decryption? Meaning, even if I bypass Google from decryption, wouldn't the certificate checks still jump in? Or are these settings only used in tandem with decryption?

Where can I find a statement in the manual that proofs this?

As far as I know the PA will only check the cert for revocation when its being part of the decryption.

If the session is not being intercepted then there will be no checks for revocation (how would the PA otherwise be able to display an error message for the client (that the cert is revoked) if the ssl session isnt decrypted?).

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!