Workflow for Nexus OCSP Responders

An OCSP client sends an OCSP request to a Nexus OCSP Responder configured as "basic" or "identrus-basic".

The following steps takes place:

1. Client TLS certificate authentication
   1. If TLS is used and client authentication is turned on, the client's TLS certificate is authenticated as part of the initial TLS handshake.
   2. If the certificate is not authenticated, Nexus OCSP Responder closes down the connection.

2. OCSP request signature
   If Nexus OCSP Responder is configured to require signed requests, the following steps are performed:

   1. If the OCSP request does not have a signature, the request is rejected.
   2. The certificate chain from the signature in the OCSP request is added to the certificate cache.
   3. The certificate cache will be checked for candidates using the request RequestorID as lookup key.

   4. The signature on the OCSP request is verified against the public key in the signature certificate(s).

   5. The signature certificate(s) is authenticated. It is enough if one of the signature certificates passes authentication.

3. Authorization
   If authorization is enabled:

   1. If authorization check is set to byauthentication, authorization is granted provided that either steps 1 or 2 above have resulted in an authenticated certificate.

   2. If authorization check is set to byname, authorization is granted provided that the subject of one of the authenticated certificates from step 1 and/or 2 matches the name match table.

4. OCSP forwarding
   If forwarding is enabled, the back end client is used to forward the OCSP request as is to a remote OCSP responder. If the back end client retrieves an OCSP response, continue with step 7, Billing.
5. Local validation
   For each single request in the OCSP request, query the revocation validation module(s) for revocation information about the certificate identified in the single request.
6. Sign the OCSP response
7. Billing
   If billing is enabled, the appropriate logging takes place.
8. Send the OCSP response

Prerequisites: The OCSP Response cache must be enabled and properly configured to cache responses for the certificate issuers that you want caching functionality for.

A client sends an OCSP request to a Nexus OCSP Responder configured as "cached" or "identrus-cached".

The following steps takes place:

1. Client TLS certificate authentication
   
   1. If TLS is used and client authentication is turned on, the client's TLS certificate is authenticated as part of the initial TLS handshake.
   2. If the certificate is not authenticated, Nexus OCSP Responder closes down the connection.
2. Extract freshness proofs (type= identrus-cached only)
   If the request contains a freshness proof extension, OCSP responses are extracted and added to the OCSP response cache, so that they are available when/if authenticating the signature certificate.

3. OCSP request signature
   If Nexus OCSP Responder is configured to require signed requests, the following steps are performed:

   1. If the OCSP request does not have a signature, the request is rejected.
   2. The certificate chain from the signature in the OCSP request is added to the certificate cache.
   3. The certificate cache will be checked for candidates using the request RequestorID as lookup key.

   4. The signature on the OCSP request is verified against the public key in the signature certificate(s).

   5. The signature certificate(s) is authenticated. It is enough if one of the signature certificates passes authentication.

4. Authorization
   If authorization is enabled:

   1. If authorization check is set to byauthentication, authorization is granted provided that either steps 1 or 2 above have resulted in an authenticated certificate.

   2. If authorization check is set to byname, authorization is granted provided that the subject of one of the authenticated certificates from step 1 and/or 2 matches the name match table.

5. OCSP Response cache
   A cached OCSP response may be retrieved from the OCSP response cache at this stage, provided that the OCSP request contains no nonce and one single request. If an OCSP response is retrieved from the response cache, continue with step 9, Billing.
6. OCSP forwarding
   If forwarding is enabled, the back end client is used to forward the OCSP request as is to a remote OCSP responder. If the back end client retrieves an OCSP response, continue with step 7, Billing.
   
7. Local validation
   For each single request in the OCSP request:
   
   1. Check the response cache for an existing. If not found, continue with b.
      
   2. Query the revocation validation module(s), as described in the previous section.
      
8. Sign the OCSP response
   For type=identrus-cached, possibly add freshness proofs for the certificates in the signature chain before signing.
   
9. Billing
   If billing is enabled, the appropriate logging takes place.
   
10. Send the OCSP response