4.10. Implementing an OCSP Responder

4.10.1. What it is

RFC 6960 describes the implementation of the Online Certificate Status Protocol (OCSP) as a method of providing certificate revocation status. Prior to or in lieu of OCSP, certificate revocation lists (CRLs) are generally the only other option to perform this task and are at times challenging to deploy given that CRLs are binary objects files that must be downloaded and parsed by the client and can sometimes be large. An OCSP transaction is represented as a small and discrete HTTP-wrapped request, minimally containing information about the issuer and a single certificate, and an equally small response containing the revocation status (good, revoked, or unknown) of that certificate. An OCSP server, referred to as a “responder”, locally caches the binary CRLs and responds to client requests with that discrete status information. SSL Orchestrator can work with OCSP in multiple capacities. Most specifically, OCSP can be configured on the server side of an outbound topology to perform revocation checking of the real server certificates. When configured this way, SSL Orchestrator will relay OCSP “stapled” responses back to the client side. Starting in 9.0, SSL Orchestrator supports a full client side OCSP service, in lieu of simple stapling in the TLS handshake. In this method, SSLO can write an authorityInfoAccess (AIA) field in the forged server certificate. That AIA field contains a URL to an OCSP responder service listener (VIP) on the F5 that the client can query, and that will relay the real revocation status of the server certificate.

4.10.2. How to build it

To use this feature:

Configure a DNS resolver - Server-side OCSP will require DNS if it needs to make a direct OCSP request. In the BIG-IP UI, under Network -> DNS Resolvers -> DNS Resolver List, click Create.

DNS Resolver

User Input


Provide a unique name

Click Finished. Now edit this new DNS resolver and click on the Forward Zones tab. Click Add.

DNS Resolver

User Input


Enter “.” (without quotation marks)


Enter your local DNS resolver IP address

Service Port

Enter the local DNS resolver’s listening port (almost always 53)

Click Add to add this resolver. Repeat for any additional resolvers.

Configure and enable server-side OCSP - Server-side OCSP is required here, as this is the information the client-side responder queries to generate an OCSP response. In the BIG-IP UI, under System -> Certificate Management -> Traffic Certificate Management -> OCSP, click Create. The below lists the minimum requirements.

Server-side OCSP

User Input

DNS Resolver

Select the previously created DNS resolver

Response Validation - Trusted Responders

This setting represents the CA bundle used to validate the signed OCSP response. In most cases the built-in ca-bundle.crt bundle will suffice.

Request Signing - Hash Algorithm

Select SHA1 to accommodate the majority of public responders.

On the SSL Configurations page of an outbound SSLO topology, select this new server-side OCSP profile under the OCSP Certificate Validator option.

Define and attach an OCSP Authentication profile - The OCSP Authentication profile creates three new objects:

  • A new iRule attached to the topology interception rule virtual server that injects the AIA URL into the forged certificate. Example:

       SSL::forward_proxy extension AIA "ocsp,http://ocsp.f5labs.com:80"

  • An OCSP profile that defines the Max Age and Nonce settings.

  • A virtual server that listens on the defined IP:port and includes the OCSP profile. Client OCSP requests to this VIP will query the assigned SSL profiles for the server-side revocation status, and relay that back in the client side OCSP response.

On the Authentication page in an outbound SSLO topology, click Add, select OCSP Responder and click the Add button.

OCSP Responder

User Input


Enter the fully qualified domain name of the local responder service. This will be the AIA URL value injected into the forged certificate and should resolve locally to the destination address defined below.


Enter here to allow all clients to connect to the OCSP service, or filter as required.

Destination Address/Mask

Enter an IP address here that will be locally accessible to internal clients.


Enter the OCSP service port number. OCSP is almost unencrypted, so port 80 is recommended.


Select the client facing VLAN(s).

SSL Configurations

Select the same SSL configuration used by the outbound topology. This is the set of SSL profiles that the OCSP responder will query for server side OCSP revocation status.

OCSP Profile

Select Create New.

Max Age in Seconds

his value represents the max age of the OCSP revocation status. The default 604800 seconds is 7 days.


A nonce is a random unique value that cryptographically binds a request and a response to prevent replay attacks. It is recommended to leave this Enabled.

Testing client-side OCSP - Testing client-side OCSP requires a client that will perform this validation. Most modern browsers can do this, however because OCSP failures are still so common, most will “soft fail”. One of the easiest ways to test is with a Firefox browser. Firefox’s default settings query OCSP responders to confirm the validity of SSL/TLS certificates. (You can change this setting in Firefox’s security preferences.)


Figure 76: Firefox OCSP preferences

However, as Firefox (like other browsers) implements a “soft-fail” policy, If you wish to require strict OCSP checking, navigate to about:config and toggle security.ocsp.require to true.

For a more verbose check you can use the following script on a Linux-based client:

  • Copy the script to your client.

  • Copy the local issuer CA certificate to the same directory

  • Make the script executable: chmod +x [script]

  • Execute the script and provide the destination URL and issuer certificate


./test-ocsp.sh www.example.com subrsa.f5labs.com.cer




## get certificate
echo | openssl s_client -connect ${site}:443 2>&1 |sed -n '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > temp.crt

## get ocsp
ocsp=$(openssl x509 -noout -text -in temp.crt |grep OCSP |awk -F":" '{print $2,$3,$4}'| while read var1 var2 var3; do echo "$var1:$var2:$var3"; done)

## issue local ocsp request
openssl ocsp -issuer ${issuer} -cert temp.crt -text -url ${ocsp} -noverify

## cleanup
rm -f temp.crt

You should see something like the following output:

temp.crt: good
    This Update: Apr  5 10:27:01 2021 GMT
    Next Update: Apr 12 09:42:01 2021 GMT