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.
If you look at the certificate that you get when you go to any google website like https://youtube.com (click on the icon to the left of the address to view certificate info) you will see that the common name is *.google.com. 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. *.google.com is in the Search Engines category, so that's what the firewall identifies it as when you go to google sites like
https://youtube.com , 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.
Thanks, but it's not a problem of being blocked by firewall policy. It's a problem with the PAN checking Google's certificates.
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.
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:
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?
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?).
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!