Configuring OCSP Stapling on BIG-IP

I have the same question as Jie.

When I follow the instructions, OCSP Stapling appears to be configured, SSL Labs reports "OCSP Stapling: Yes". However, Chrome still does it's own OCSP checks and Firefox throws an error MOZILLA_PKIX_ERROR_OCSP_RESPONSE_FOR_CERT_MISSING.

I have an EV certificate with an intermediate chain certificate issued by QuoVadis. It seems that the OCSP Stapling profile doesn't support this certificate configuration. Or am I missing something?

I am wondering on the "Response Caching => Timeout: Indefinite" setting: Yesterday I revoked some certificate and this morning it was still shown as ok. When I deleted the OCSP cache for that certificate the status was updated to 'revoked' which is fine. If you follow the advice to set it to "Indefinite" - wouldn't this render OCSP stapling pretty much useless as the certificate will only be checked once then the cached response is used forever no matter if the certificate is still valid or revoked?

What timeout do you guys set on this usually? 1800-3600 seconds?

@Torsten, I think you'll find that after a short time the cached response would be invalid as I'm lead to believe the OCSP response has it's own expiry. But I'm new to this OCSP stapling so maybe someone with more experience could chime in.

I generally don't revoke certificates, I just destroy them as best I can along with the private keys after I've got a replacement cert+key pair setup on the F5. The revocation process is more complicated and less reliable than starting over. I'd only use revocation if a private key was stolen.

I eventually got rid of my Firefox error, I think it had something to do with the order of the certificates. It turned out that my stapled OCSP data was actually useless. Browsers other than Firefox just ignored it and fetched it from the source. Once I got it working, I found still there was no chain certificate getting stapled so I figure I'll disable it for now as it seems like a flakey feature.

@Sam: I would expect this too but after waiting for roughly one day the certificate was still shown as valid until I manually deleted the OCSP cache...

Regarding the timeout of OCSP stapling I tested against the website of our CA:

echo HEAD / HTTP/1.0 | openssl s_client -connect www.digicert.com:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update'

Result:

OCSP response:
======================================
    OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 3DD350A5D6A0ADEEF34A600A65D321D4F8F8D60F
    Produced At: Oct 30 00:12:54 2017 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 49F4BD8A18BF760698C5DE402D683B716AE4E686
      Issuer Key Hash: 3DD350A5D6A0ADEEF34A600A65D321D4F8F8D60F
      Serial Number: 0793EC89595DBA606D1FD9F7BE389802
    Cert Status: good
    This Update: Oct 30 00:12:54 2017 GMT
    Next Update: Nov  5 23:27:54 2017 GMT

So it seems the timeout is seven days which I find rather irritating, or is this just a fixed renewal which is independent of revoking certificates? Nevertheless I did now set the timeout to 1800 seconds and see how this will perform...

Any further advise appreciated 🙂

Hi Jason!

Could it be the migration of devcentral destroyed the code snippets above? As an example:

openssl verify -CAfile \:Common\: \:Common\:"cert in question"

If I use the command as specified I get the following errors:

Error loading file :Common:

47706134397416:error:02001002:system library:fopen:No such file or directory:bss_file.c:165:fopen(':Common:','r')

47706134397416:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:168:

47706134397416:error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib:by_file.c:258:

If I use the command like this:

openssl verify -CAfile \:Common\:"ca cert in question" \:Common\:"cert in question"

I get the following output:

:Common:"cert in question": C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO RSA Certification Authority

error 2 at 2 depth lookup:unable to get issuer certificate

The individual certificates I use seem to be okay though:

# openssl verify \:Common\:"cert in question"

:Common:"cert in question": OK

# openssl verify \:Common\:"ca cert in question"

:Common:"ca cert in question": OK

Also, I found that I have to run the command from the /config/filestore/files_d/Common_d/certificate_d directory if I don't want to specify the complete path, and I think adding this information to your article might be helpful.

Can you perhaps try the following and see if it gives you any better results from within bash or list the specific version of F5 you are running as this was put together against v13.1.5.

# set directory path to location of certs (change to custom partition if not stored in /Common)

cd /config/filestore/files_d/Common_d/certificate_d

# obtain the full name of cert + ca bundle

ls

# test OCSP response using openssl

# -issuer & -CAfile are both using a cert bundle containing both the Intermediate + Root CA for DigiCert

openssl ocsp -no_nonce -header Host ocsp.digicert.com -issuer \:Common\:digicert_bundle.crt_198653_1 -cert \:Common\:your.website.com.crt_234232_1 -url http://ocsp.digicert.com -CAfile \:Common\:digicert_bundle.crt_198653_1

We haven't looked at it for a while, but I think we ended up determining that the F5 was caching a bad or failed OSCP response which upset Firefox. This was on version 12. I also kind of lost interest when I realised that OSCP stapling doesn't support the chain certificate anyway, so it won't eliminate the delay, only halve it. That coupled with the risk of denying access to the site it's supposed to speed up, I found it pretty disappointing overall and there doesn't seem to be any activity towards adding support for stapling chain certs since draft was raised 6 years ago... https://bugzilla.mozilla.org/show_bug.cgi?id=611836