- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
05-02-2013 04:45 AM
When enabling OCSP and having a self signed certificate for SSL decryption
(we push the certificate to all our domain clients)
will OCSP check my self signed certificate against the OCSP responder (and fail because it is unknown)?
Or will it only check the original destination server certificate (for example that of facebook)?
06-18-2013 05:17 AM
owkey
a quick update: seems we were hitting a bug.
it seems there was a filename buffer overflow. so when we enable ocsp and the PA did a check to find the PA responder it would fail because the filename was to long.
(extract from the sslmgr.log file: pan_ocsp_certchain_to_file(pan_crl.c:1104): Error opening /opt/pancfg/certificates/predefined/VeriSign, Inc., )
PA feedack:
The fix for the original issue is still being tested. I will update you with further OS version information when available.
The fix will extend the CA filename buffer to eliminate the error message we are seeing in sslmgr.log. Also, it will clean up the cert status representation on the dataplane.
regards
05-02-2013 03:42 PM
The OCSP extension will simply not be built in the client-side certificate by default.
If you choose to use an OCSP responder on the self-signed certificate, the client will use that OCSP responder. It won't fail, because the OCSP responder will not find a revoked serial number (it won't find any serial number, but that's not the purpose of OCSP).
Hope this helps!
Greg Wesson
05-03-2013 02:23 AM
Allright, OCSP is not completely clear to me yet.
Would you not use it purely for client certificates?
And if so, how do you dissable it to check all server certificaes when ssl decryption is enabled.
Because when we set this up and we use SSL decryption, we get untrusted warnings for all certificates. To solve this, we would need to configure an OCSP responder for all CA's separately, which obviously is not possible.
05-03-2013 09:21 AM
OCSP is pretty uncommon to be used for SSL decryption. I most commonly see it used for the firewall login itself (using a trusted or in-house CA), captive portal, and global protect.
The reason you get untrusted warnings on all certificates with SSL decryption is because the firewall is creating a new certificate on the fly for the host you are visiting. For example, if your client visits https://live.paloaltonetworks.com, instead of the certificate being issued by GoDaddy as ours is, it is issued by your firewall. The firewall copies the Common Name and dates from the official GoDaddy cert on that site, but has to issue a new one for the client.
Unless the client trusts that firewall CA certificate, every site will be untrusted. This is the nature of SSL Decryption (technically it is a man-in-the-middle).
05-06-2013 02:10 AM
Following, since this case relates to us
05-06-2013 03:11 AM
I know, that is PA ssl decryption 101 🙂
I mean even with the client having the root CA in his trust, we still get all untrusted certificates.
(without OCSP the ssl decryption works fine)
Looks like the OCSP is not checking the root CA, but is checking if the original certificate (for example facebook) is not revoked...
05-06-2013 03:02 PM
I wouldn't expect using OCSP would have any effect on decryption. I think that it might be worth creating a case with support as long as your firewall is under a support contract. The client doesn't get the original certificate, so it wouldn't be possible for them to check to see if it is revoked or not.
When you open your support ticket, please point to this discussion for additional background.
-Greg
05-07-2013 04:02 AM
Owkey, then it seems my initial understanding of OCSP was somewhat correct and this should not have any impact on ssl decryption.
I have opened a tech support case (pointing to this discussion).
I will give an update as soon as I have one.
Tanx for all the help Greg!
Linus
06-18-2013 05:17 AM
owkey
a quick update: seems we were hitting a bug.
it seems there was a filename buffer overflow. so when we enable ocsp and the PA did a check to find the PA responder it would fail because the filename was to long.
(extract from the sslmgr.log file: pan_ocsp_certchain_to_file(pan_crl.c:1104): Error opening /opt/pancfg/certificates/predefined/VeriSign, Inc., )
PA feedack:
The fix for the original issue is still being tested. I will update you with further OS version information when available.
The fix will extend the CA filename buffer to eliminate the error message we are seeing in sslmgr.log. Also, it will clean up the cert status representation on the dataplane.
regards
06-20-2013 11:50 PM
Can you please tell some details? I think we're hitting a same bug:
Jun 21 08:34:15 Error: sslmgr_parse_request(sslmgr_main.c:820): Truncated buffer(8188)
Jun 21 08:38:31 Error: pan_ocsp_certchain_to_file(pan_crl.c:1078): Error opening /opt/pancfg/certificates/predefined/VeriSign, Inc.,
Jun 21 08:38:31 Error: pan_ocsp_fetch_ocsp(pan_crl.c:1922): pan_ocsp_certchain_to_file() failed
The certificate for the site https://neo.ubs.com is valid but our pa says the certificate is expired.
06-24-2013 11:59 PM
I think it's best you open a tech support case for your issue. You can always point to this discussion.
The bug id i got was 51658. I am still waiting on the PanOS which will include a fix for this.
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!