OCSP AUTH AGENT
Hello everyone, I'm facing a situation and I need your input to figure it out what's wrong. I have a VIP where mtls is configured in the client SSL profile with the issuer's certificate as CA (we call it CA_1), and it works well. (Per info, the client cert is issued by CA_1, which is also issued and signed by a higher authority CA_2.) I wanted to make OCSP checks for client certificates so I created a simple APM policy as follows : Client --- > on-demand cert agent ---> OCSP Auth Agent ---> Allow or deny The OCSP responder is configured with the same CA_1 that's configured in the in the Client authentication in the ssl profile, and a responder (ocsp.example.com). The error I'm facing is OCSP Auth agent: Failure status 'Error querying OCSP responder host ocsp.example.com. To troubleshoot, I did few tests and we can eliminate the following possibilities: Connectivity and DNS: I can reach the responder in the http port using the FQDN. Blocked traffic : no Firewall inspection between the BIG IP and the responder. The responder is not treating the request as it should: openssl ocsp verification works fine and gets me the wanted result from the ocsp responder. The famous "missing host header" : the header is well included in the request sent by the big ip to the responder; moreover, i compared this request to the one sent when using openssl ocsp and the one sent when i test from my own computer using openssl, and they are identical when it comes to the OCSP date in the request and response frames. What's more interesting is when I capture the response sent by the responder when the apm sends the ocsp verification request, i can clearly see that's stating the status of the certificate (which is revoked in my case), but the APM logs doesn't show that; instead, when debugging, it says that the on-demand cert agent is executed (i can see the client cert and the issuer cert CA_1 as well) and then it moves successfully to the OCSP auth agent and then directly it says the querying error. Could you please tell me if you see anything i could do to troubleshoot more ? Any ideas ? PS 1 : I tried also using the CA_2, a bundle of CA_1 and CA_2, a cert chain of both, but no luck ! PS 2 : when i use the CRLDP agent, i can see the status (revoked) in the APM logs. Thank you in advance !
OCSP and Comodo cert
Hi all, I was wondering if somebody ran into the same issue with OCSP and Comodo issued certs. Since last week we're getting "OCSP Check Failed" messages for Comodo issued certificates. We did some tcpdumps to figure out what's going on and it seems that Comodo OCSP URL requires a host header. This was the HTTP response to our OCSP request: Invalid URL The requested URL "[no URL]", is invalid. Reference 9.7ce58db.1529652000.5b7f63b A manually performed check confirmed the issue (we're on 12.1.2-HF2): openssl ocsp -issuer comodo-chain-bundle.crt -cert web-certificate.crt -text -url http://ocsp.comodoca.com -no_nonce -verify_other comodo-chain-bundle.crt OCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: xxxx Issuer Key Hash: yyyy Serial Number: zzzz Error querying OCSP responder 47881717408264:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:ocsp_ht.c:247:Code=400,Reason=Bad Request By adding a host header to the openssl command we were able to get a successful response: openssl ocsp -issuer comodo-chain-bundle.crt -cert web-certificate.crt -text -url http://ocsp.comodoca.com -no_nonce -verify_other comodo-chain-bundle.crt -header "Host" "ocsp.comodoca.com" OCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: xxxx Issuer Key Hash: yyyy Serial Number: zzzz OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: 90AF6A3A945A0BD890EA125673DF43B43A28DAE7 Produced At: Jun 20 08:45:26 2018 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: xxxx Issuer Key Hash: yyyy Serial Number: zzzz Cert Status: good This Update: Jun 20 08:45:26 2018 GMT Next Update: Jun 27 08:45:26 2018 GMT Signature Algorithm: sha256WithRSAEncryption ---snippp--- Response verify OK web-certificate.crt: good This Update: Jun 20 08:45:26 2018 GMT Next Update: Jun 27 08:45:26 2018 GMT The "web-certificate.crt" is issued by Issuer: COMODO RSA Domain Validation Secure Server CA, COMODO CA Limited Write review of Comodo Our "comodo-chain-bundle.crt" contains Common Name: COMODO RSA Domain Validation Secure Server CA Issuer: COMODO RSA Certification Authority, COMODO CA Limited Write review of Comodo Common Name: COMODO RSA Certification Authority Issuer: COMODO RSA Certification Authority, COMODO CA Limited Our implemented OCSP check doesn't send a host header and we have no issue with certificates issued by other CAs. Does anybody know a workaround? Can we savely add a host header to our OCSP check without affecting the checks of other certificates? Any hint is much appreciated. cheers
DISA OCSP responder sometimes producing errors
Hi, not sure if there are others that have this issue, it seems sporadic. I’m using BigIP v13.1.1 OCSP will sometimes fail and users will fail to login, and it will fail for a random duration of time which makes me think it may be an issue with DISA's OCSP servers. It doesn't happen daily. I have a pretty standard APM setup. No HA, nothing weird. My VPE: Start -> On Demand Cert (request) -> OCSP (/Common/DISA_OCSP, cert type user) -> etc etc -> For my OCSP config I have default settings with the Certificate Authority file as the DOD CA bundle and Verify other is the DOD Email CA bundle. Everything is checked besides Ignore AIA and Trust Other. The error in /var/log/apm is: OCSP Auth agent: Failure status ‘Error querying OCSP responsder *(<-this is a typo in the error)* host (ocsp.disa.mil) path (/)’ Looking at my email cert, it looks like I have two different AIAs. One is a crl.disa.mil url pointing at my CA's DODEMAILCA cer file, the other is ocsp.disa.mil. Can anyone recommend a more stable way to configure this?
OCSP check iRule issues
Hi, so, as i have quite some issues with OCSP/client cert checks using a auth profile with attached irule, i wanted to start from scratch. IF YOU CAN EVEN ONLY ANSWER ONE OF THE QUESTIONS, PLEASE DO SO! While starting with _sys_auth_ssl_ocsp, i noticed a few things: 1) We shouldnt have to do this, at least when we set set tmm_auth_subscription "*" in CLIENT_ACCEPTED, right? if {[info exists tmm_auth_subscription]} { AUTH::subscribe $tmm_auth_ssl_ocsp_sid } Though, can it be somehow possible that we get too much AUTH_RESULT events if we set it to "*"? 2) the AUTH_RESULT event will probably produce conn timeouts: when AUTH_RESULT { if {[info exists tmm_auth_ssl_ocsp_sid] and \ ($tmm_auth_ssl_ocsp_sid == [AUTH::last_event_session_id])} { set tmm_auth_status [AUTH::status] if {$tmm_auth_status == 0} { set tmm_auth_ssl_ocsp_done 1 SSL::handshake resume } elseif {$tmm_auth_status != -1 || $tmm_auth_ssl_ocsp_done == 0} { reject } } } If the first "if" statement is not true for whatever reason OR we get a tmm_auth_status of -1 (general OCSP error), the held ssl handshake will never finish and we will run into either the ocsp idle timeout or a tcp timeout; so wouldnt it be generally better to ALWAYS to the SSL::handshake resume and just do a "return" after the reject for that special case? Or is there any special reason we shouldnt resume the handshake here? 3) can someone please explain if {[info exists tmm_auth_ssl_ocsp_sid] and \ ($tmm_auth_ssl_ocsp_sid == [AUTH::last_event_session_id])} { to me? AFAIK, last_event_session_id is the last processed auth event generally. In a high load scenario (and cause the AUTH is most likely multithreaded) it may happen that this is not true. Or is the AUTH_RESULT event called for ALL instances, and this if-statement just means that we want the correct instance to process it? Many thanks in advance, Rene
Enabling OCSP stapling via f5-sdk fails
I want to enable OCSP stapling for a lot of clientSSL profiles, so I thought if'd use the f5-sdk python library. However, my tests so far fail miserably, even without trying to change the actual setting. Here's what I tested: #! /usr/bin/env python3 from f5.bigip import ManagementRoot mgmt = ManagementRoot("hostname", "username", "password") profile = mgmt.tm.ltm.profile.client_ssls.client_ssl.load(partition="Common", name="myprofile") print(profile.ocspStapling) profile.update() This print the current ocpStapling value ('disabled'), but updating the unchanged profile fails: $ python3 ocsp-test2.py disabled Traceback (most recent call last): File "ocsp-test2.py", line 15, in <module> profile.update() File "/Users/teun/Library/Python/3.7/lib/python/site-packages/f5/bigip/resource.py", line 617, in update self._update(**kwargs) File "/Users/teun/Library/Python/3.7/lib/python/site-packages/f5/bigip/resource.py", line 580, in _update response = session.put(update_uri, json=data_dict, **requests_params) File "/Users/teun/Library/Python/3.7/lib/python/site-packages/icontrol/session.py", line 295, in wrapper raise iControlUnexpectedHTTPError(error_message, response=response) icontrol.exceptions.iControlUnexpectedHTTPError: 400 Unexpected Error: Bad Request for uri: https://hostname:443/mgmt/tm/ltm/profile/client-ssl/~Common~myprofile/ Text: '{"code":400,"message":"\\"{ dont-insert-empty-fragments no-tlsv1.1 single-dh-use no-sslv3 no-tlsv1 }\\" unexpected argument","errorStack":[],"apiError":26214401}' I didn't change any settings of the profile, so why would it fail to update? As a test, I removed these SSL options., but that doesn't help either. The error message changes of course, but updating an unchanged profile still fails: icontrol.exceptions.iControlUnexpected HTTPError: 400 Unexpected Error: Bad Request for uri: https://hostname:443/mgmt/tm/ltm/profile/client-ssl/~Common~myprofile/ Text: '{"code":400,"message":"01b4002a:3: Client SSL profile (/Common/myprofile):cert-key-chain and profile cert/key/chain/passphrase options cannot be specified together.","errorStack":[],"apiError":3}' I really fail to see what's wrong here and what I need to do to get this to work. Any other suggestions on configuring OCSP stapling via python are welcome too.
Create Your Own Certificate Authority
Problem this snippet solves: The main goal of this article is to share an easy way to create your own Certificate Authority (CA) for your lab enviroment with APM module. REF - https://github.com/DariuSGB/LabCA This repository is composed by a set of scripts that give you an easy way to: Create your own root CA. Create your own intermediate CA, signed by your root CA. Create your own certs, signed by your intermediate CA or your root CA. Create your own OCSP cert, for using it in your OCSP responder. Create your own CRL cert, for using it directly in your APM. Revoke your certs (remember to refresh your CRL cert after that). Create your own PKCS#12 cert (from regular PEM certs/keys) for installing it in your windows enviroment. Invoke a OCSP responder of your certs enviroment (remember to create a OCSP cert first). How to use this snippet: Download and install your enviroment using these commands: git clone https://github.com/DariuSGB/LabCA.git cd LabCA chmod +x $(ls | grep -v README) Tested this on version: 14.1OCSP through an outbound explicit proxy
Hey DC community, Kevin Stewart here with a fun little project I'd like to share. There have been countless questions about this over the years: how to pass LTM or APM OCSP requests through an outbound explicit proxy. We've already established that you can create a simple VIP and iRule that "proxifies" an outbound OCSP HTTP request, and that you can point the OCSP responder configuration URL directly at this layered VIP. But what if client certificates need to be validated against different OCSP responders, based on the X509 AIA extension? AIA, or "Authority Information Access" is an X509 certificate extension that identifies, among other things, the OCSP responder URL that a given client certificate should be validated against. The LTM and APM OCSP clients (as of 13.1) don't pass an HTTP Host header, and don't allow you to inject any "signaling" information into the outbound OCSP request. That means there's no easy way to get the client's real certificate AIA value over to the proxy VIP, plus you need the OCSP responder to point to the proxy VIP anyway. The answer is to signal "out-of-band" - at the application VIP, catch the certificate issuer, serial and AIA values into a table, issuer_hash:serial = AIA and at the proxy VIP, catch the issuer and serial in the OCSP request and look up the AIA URL from the table. The issuer value in the OCSP request is a SHA-encoding of the issuer value from the DER-formatted certificate. You can't just SHA hash the X509::issuer value. That'd be too easy. It's necessary then to binary parse the issuer directly from the binary certificate blob. The OCSP request is already binary, so you have to binary parse this data anyway. Before I get into the details, I should warn you that there's a lot of binary processing TCL code in these iRules, which a) isn't for the faint of heart, b) isn't great for performance, and c) isn't going to correct for every type of certificate. I did test this with sha1WithRSAEncryption and sha256WithRSAEncryption certificate signature algorithms, across both RSA and EC certs, and these all worked. It's also worth noting that the performance loss may be neglible given that OCSP itself will be the bigger hit. However, things like TLS session resumption should keep full handshakes and OCSP validation from happening as much over a set of active user sessions. The configuration looks basically like this: Create your application VIP, pool, and client SSL profile as required. Test without client cert auth first to makes sure basic flow and functionality works as expected. Create an internal "proxy" VIP and pool that points directly at the outbound explicit proxy (ex. 192.168.2.1:3128), and attach the proxy iRule. You can also create an empty VLAN (no interfaces), attach a unique self-IP to that VLAN (ex. 11.11.11.1), and assign an IP from that subnet to the proxy VIP (ex. 11.11.11.2:80) to keep all OCSP proxy traffic internal. Also make sure the proxy VIP is listening on the correct VLAN, enables address and port translation, and SNAT as required. If using LTM OCSP, create the OCSP responder, configuration and profile. If using APM OCSP, create the OCSP responder AAA and an access policy VPE that starts with the OCSP authentication agent - the included iRules parse the certificate issuer, serial and AIA from CLIENTSSL_CLIENTCERT, so the client SSL profile needs to request the client certificate (versus the APM On-Demand Cert Auth agent). This could also be done completely within the Access context, but I'm not adding that code right now (maybe later). Point the OCSP responder URL at the HTTP proxy VIP URL (ex. http://11.11.11.2) and check "ignore AIA". If APM OCSP, set CertID Digest to SHA-1. LTM OCSP automatically uses SHA-1. Attach the application iRule to the application VIP, and attach either the LTM OCSP authentication profile or APM access policy to the application VIP. Application iRule when CLIENTSSL_CLIENTCERT { ## Get the SHA1 hash of the DER-formatted issuer value ## X509 certificates are ASN.1-formatted, which is not easy to parse. ## Based on RFC5280 (https://tools.ietf.org/html/rfc5280), the issuer field is a mandatory value in the X509 certificate ## that comes directly after the signature algorithmIdentifier value. So we'll start by finding the object identifier (OID) ## of the signature algorithm, and then walk down the ASN.1 blob to the next item, which is the issuer. if { [SSL::cert count] > 0 } { ## Start with the PEM-formatted certificate, remove the "BEGIN CERTIFICATE" and "END CERTIFICATE" header/footer, ## and base64-decode the remaining data to expose the binary (DER-formatted) certificate. set strippedcert [findstr [X509::whole [SSL::cert 0]] "-----BEGIN CERTIFICATE-----" 27 "-----END CERTIFICATE-----"] if { [catch { b64decode ${strippedcert} } string_b64decoded] == 0 and ${string_b64decoded} ne "" } { if { [catch { ## sigAlg OID (1.2.840.113549.1.1.5) = sha1WithRSAEncryption = HEX \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x05 ## sigAlg OID (1.2.840.113549.1.1.11) = sha256WithRSAEncryption = HEX \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x0B ## Find the initial offset at the position of sigAlg OID in the certificate ## Here's an online tool to convert OID to Hex: https://misc.daniel-marschall.de/asn.1/oid-converter/online.php if { [expr [set offset [string first \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x0B ${string_b64decoded}]] > 100] } { if { [expr [set offset [string first \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x05 ${string_b64decoded}]] > 100] } { ## Error: unknown signature algorithm } } ## Offset this position by the size of the sigAlg set newoffset [expr ${offset} + 13] ## Get the length of the issuer value - ASN.1 values start with a type and a length, so this extracts the length value. binary scan [string range ${string_b64decoded} ${newoffset} [expr ${newoffset} + 4]] H2H2 type issuer_len_hex ## Convert the length to decimal scan ${issuer_len_hex} %x issuer_len_dec ## SHA1-encode the DER-formatted issuer value - this is the value that will be present in an OCSP request binary scan [sha1 [string range ${string_b64decoded} ${newoffset} [expr ${newoffset} + ${issuer_len_dec} + 1]]] H* issuer_hash ## Store the SHA1 issuer hash:cert serial in a short-lived table with the AIA URL set AIA [findstr [X509::extensions [SSL::cert 0]] "OCSP - URI:" 11 "\n"] set serial [X509::serial_number [SSL::cert 0]] table set -subtable OCSP_AIA "${issuer_hash}:${serial}" "${AIA}" 5 5 } error] } { log local0. "error = $error" } } } } Proxy iRule when RULE_INIT { ## Static ocsp responder URL - if the client cert doesn't have an AIA or the app VIP iRule is unable to parse it, ## include this value as a default OCSP URL. You may optionally just choose to fail the connection. set static::ocsp_host "http://ocsp1.f5testlab.local/" } when CLIENT_ACCEPTED { set AIA "" TCP::collect } when CLIENT_DATA { ## Find the first offset as the position of the SHA-1 OID - based on RFC 2560 (https://www.ietf.org/rfc/rfc2560.txt), ## an OCSP request is an ASN.1-formatted binary structure that contains the following: ## - hashAlgorithm - we know this is SHA-1 because the F5 OCSP is configured to use SHA-1. ## - isserNameHash - a SHA-1 hash of the DER-formatted issuer value. This is the first value we need. ## - issuerKeyHash - a SHA-1 hash of the issuer's public key. We don't need this value. ## - serialNumber - the client certificate serial number. This is the second value we need. set offset [string first \x06\x05\x2B\x0E\x03\x02\x1A [TCP::payload]] ## Set new offset after the SHA1 OID set newoffset [expr ${offset} + 7] ## Get the issuerHash length binary scan [string range [TCP::payload] ${newoffset} [expr ${newoffset} + 8]] H2H2H2H2 t1 t2 t3 issuer_len_hex ## convert the issuerHash length to decimal scan ${issuer_len_hex} %x issuer_len_dec ## Get the issuer hash value - this is the issuer hash that we need. binary scan [string range [TCP::payload] [expr ${newoffset} + 4] [expr ${newoffset} + 3 + ${issuer_len_dec}]] H* issuer_hex ## Set new offset after the issuerHash set newoffset [expr ${newoffset} + 4 + ${issuer_len_dec}] ## Get the issuerKeyHash length binary scan [string range [TCP::payload] ${newoffset} [expr ${newoffset} + 4]] H2H2 type issuerKey_len_hex ## convert the issuerKeyHash length to decimal scan ${issuerKey_len_hex} %x issuerKey_len_dec ## Set new offset after the issuerKeyhash set newoffset [expr ${newoffset} + 2 + ${issuerKey_len_dec}] ## Get the serial length binary scan [string range [TCP::payload] ${newoffset} [expr ${newoffset} + 4]] H2H2 type len_hex ## Convert the serial length to decimal scan ${len_hex} %x len_dec ## This is the serial number that we need. binary scan [string range [TCP::payload] [expr ${newoffset} + 2] [expr ${newoffset} + 1 + ${len_dec}]] H* serial ## Look up the table entry for the issuerHash:serial set AIA [table lookup -subtable OCSP_AIA "${issuer_hex}:${serial}"] ## Optionally close the connection or doing something else if a table entry isn't found. Otherwise release. TCP::release } when HTTP_REQUEST { if { ${AIA} ne "" } { ## If AIA exists, dynamically change the URI to map to the client cert OCSP AIA URL ## This is the "proxyification" function to allow unencrypted HTTP to flow through an explicit proxy. ## Most, if not all public OCSP responders perform OCSP over unencrypted HTTP, so there's no need ## to deal with messy HTTP CONNECT logic. HTTP::uri "${AIA}" } else { ## Otherwise use the system default OCSP URL HTTP::uri $static::ocsp_host } } To recap, an OCSP responder configuration (LTM or APM) points to a local "proxy" VIP (and ignores AIA). The application VIP iRule first grabs the client certificate AIA URL, serial number, and issuer hash, and throws those values into a table. Upon client certificate authentication, the OCSP responder client issues an OCSP request that flows to the proxy VIP. The proxy VIP grabs the issuer hash and serial number from the OCSP request, looks up the AIA URL in the table, and dynamically changes the HTTP URI value in the outbound request to the explicit proxy, to effectively proxify the OCSP request. As stated, this should work with sha1WithRSAEncryption and sha256WithRSAEncryption certificates. If you come across a certificate that uses something else, please let me know. Thanks. - Kevin Edit: If you want to do this completely inside APM, using an On-Demand Cert Auth agent: Insert an iRule event agent between the On-Demand Cert Auth agent and the OCSP Auth agent in the VPE. Use "GETISSUER" as the iRule event agent ID. Switch out the application VIP with the following: Access Application VIP when ACCESS_POLICY_AGENT_EVENT { if { [ACCESS::policy agent_id] eq "GETISSUER" } { set strippedcert [findstr [ACCESS::session data get session.ssl.cert.whole] "-----BEGIN CERTIFICATE-----" 27 "-----END CERTIFICATE-----"] if { [catch { b64decode ${strippedcert} } string_b64decoded] == 0 and ${string_b64decoded} ne "" } { if { [catch { ## sigAlg OID (1.2.840.113549.1.1.5) = sha1WithRSAEncryption = HEX \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x05 ## sigAlg OID (1.2.840.113549.1.1.11) = sha256WithRSAEncryption = HEX \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x0B ## find the position of sigAlg in the certificate if { [expr [set offset [string first \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x0B ${string_b64decoded}]] > 100] } { if { [expr [set offset [string first \x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x05 ${string_b64decoded}]] > 100] } { ## Error: unknown signature algorithm } } ## offset this position by the size of the sigAlg set newoffset [expr ${offset} + 13] ## get the length of the DER-formatted issuer value binary scan [string range ${string_b64decoded} ${newoffset} [expr ${newoffset} + 4]] H2H2 type issuer_len_hex ## convert the length to decimal scan ${issuer_len_hex} %x issuer_len_dec ## SHA1-encode the DER-formatted issuer value binary scan [sha1 [string range ${string_b64decoded} ${newoffset} [expr ${newoffset} + ${issuer_len_dec} + 1]]] H* issuer_hash ## Store the SHA1 issuer hash:cert serial in a short-lived table with the AIA URL set AIA [findstr [ACCESS::session data get session.ssl.cert.x509extension] "OCSP - URI:" 11 "\n"] set serial [ACCESS::session data get session.ssl.cert.serial] table set -subtable OCSP_AIA "${issuer_hash}:${serial}" "${AIA}" 10 10 } error] } { log local0. "error = $error" } } } }Configuring OCSP Stapling on BIG-IP
When setting up an SSL connection the cert tells you its expiration, but how do you tell if the SSL Cert has been revoked? There are multiple ways to do this. The first is the Certificate Revocation List (CRL). When the client requests the CRL, the cert provider will send a list of revoked certificates. The problem is that over time this list becomes very large as certs are added. Case in point, heartbleed casued a spike in the number of certs added to CRL list. To get around these large lists when all the client is looking for is one cert is the Online Certificate Status Protocol (OCSP.) This allows the client to query the CA for the validity of the cert in question. There are still problems, for example there can be a large number of clients that query the OCSP responder. If the OCSP responder takes too long and times out, then most clients will ignore the problem and move on. With OCSP stapling the client can ask the server to staple the OCSP response with the SSL server certificate response from the server. This allows the server to deal with the OCSP message and not require the client to query the OCSP responder. Doing this offloads the process from the OCSP server to the server, spreading the load around, making it quicker in most cases and limiting OCSP timeout. Once the server gets the OCSP response it can cache the response for the valid period, so one request to the OCSP server will serve many responses to the client. Requirements for OCSP Stapling on BIG-IP The OSCP responder for the cert in question. In this case startSSL.com allows you to generate a real cert for the test. The OSCP responder is http://ocsp.startssl.com You need to make sure the cert has the full chain for the client and f5 to trust Test both the responder and the chain with the following openssl command To test the SSL chain run the following command: openssl verify -CAfile \:Common\: \:Common\:"cert in question" The output should be like the following :Common:"cert in Question": OK Now test OCSP response from openssl openssl ocsp -issuer \:Common\: -cert \:Common\: -text -header "HOST" "host name of ocsp" -url http:/// -CAfile \:Common\: You should get an output like below: OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Class 1 DV Server CA OCSP Responder Produced At: Jan 14 18:19:02 2016 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 5168159AB1999B3A55E860C022C9D519E0303D29 Issuer Key Hash: D7914E01C4B0BFF8C86793449CE733FAAD930CAF Serial Number: 346F8F9596F4A3AEB2B0C3AE693B5A7F Cert Status: good This Update: Jan 14 18:19:02 2016 GMT Next Update: Jan 18 18:29:02 2016 GMT Once you have tested and know the cert and CA are correct you can connect to the correct OCSP responder now it time to setup the f5. BIG-IP Configuration Steps First we need to Create the DNS resolver this is located in Network -> DNS Resolvers. The defaults are fine here you just need to add a name Next you will need to create a forward zone. For the name put . and enter the DNS server that the unit should use. Now we can create the OCSP Stapling profile. For the DNS Resolver put the one in that you setup in the steps above For the Trusted Certificate Authorities this is the CA file you test with earlier Responder URL us the URL from earler that the f5 will direct all OCSP requests to. By default Sign Hash is set to SHA256 there responders that will not work with this and it will need to be set to SHA1 Timeout is the amount of time till the f5 drop the connection to the OCSP server. This has to be smaller them the Handshake timeout in the SSL Profile. Status Age is the age of the from this update, most servers will have a range that this update is good for. By default the f5 1 day make sure you check your server to make sure the Status Age is large enough to handle this Cache Timeout this is how long the f5 will cache the response, default is Indefinite this allows the f5 to cache the request for the length of the validity period the server sets Next step is to create the SSL profile and add the Stapling Profile Now after the ClientSSL profile is add to the VIP you are ready to test. Testing it out If your site is open to the Internet you can use tools like Qualys SSL Labs, or you can test with OpenSSL with the following command: certificate_d # openssl s_client -connect VIP IP:443 -tls1 -tlsextdebug -status | grep -i "ocsp response" -B 5 -A 10 The output from a successful OCSP stapling OCSP response: ====================================== OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Class 1 DV Server CA OCSP Responder Produced At: Jan 14 18:19:02 2016 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 5168159AB1999B3A55E860C022C9D519E0303D29 Issuer Key Hash: D7914E01C4B0BFF8C86793449CE733FAAD930CAF Serial Number: 346F8F9596F4A3AEB2B0C3AE693B5A7F Cert Status: good Much thanks to Richard Harlan, one of F5's fine field systems engineer for contributing this write up!
