OCSP on SSL decrypt with self signed certificate

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

OCSP on SSL decrypt with self signed certificate

L4 Transporter

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

1 accepted solution

Accepted Solutions

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

View solution in original post

10 REPLIES 10

L7 Applicator

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

L4 Transporter

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.

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

L4 Transporter

Following, since this case relates to us Smiley Wink

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

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

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

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

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.

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.

  • 1 accepted solution
  • 6886 Views
  • 10 replies
  • 0 Likes
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!