Workflow for Nexus OCSP Responders

This article describes different workflows for Nexus OCSP Responder. The descriptions refer to the illustration in Nexus OCSP Responder architecture overview.

The expression"authenticating a certificate", used in this article, means subjecting a certificate to the validation process described in Validation process. If the certificate passes the validation process, the certificate is authenticated.

Workflow for responders of type basic, non-issued basic or identrus-basic

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

Workflow for responders of type cached, non-issued cached or identrus-cached

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

Workflow for responders of type fallback

This responder type requires that a CM-SDK connection to Certificate Manager (CM) is configured. See section “Configurations for cmsdk-connection” in Default OCSP configuration for more information.

The Fallback responder type provides a real-time certificate status by querying the CM database with the help of the CM-SDK. In order to achieve real-time status this responder type has some performance tradeoffs in relation to the basic responder type. The number of OCSP requests the fallback responder type can handle compared to the basic responder type decreases by approximately one third in the best case. The performance is very much depending on the network connection between OCSP and the CM instance. If the decrease of requests handled seems a lot greater than this it is possible that the cmconnections configured in cmsdk-connection.conf needs to be increased to allow more parallel connections to CM.

When increasing the cmconnections be observant of the CM instance's performance. The CM instance has a maximum number of connections it can handle in parallel. If this limit is reached and the performance of CM declines it is recommended to consider introducing
multiple CM instances together with load-balancing infrastructure.

The following steps are performed when a client sends an OCSP request to Nexus OCSP responder configured "fallback".

1. Client TLS certificate authentication
   As described in the previous section

2. OCSP Request signature
   As described in the previous section.

3. Authorization
   As described in the previous section.

4. OCSP forwarding
   As described in the previous section.

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. CM Validation
   OCSP responder will fallback to CM sending a CM-SDK request asking for the freshest CertStatus. Fallback will take place in the following cases:
   - If the CertStatus in the response from the local validation was 'Good'.
   - If the CertStatus in the response was 'Revoked' with CRL reason was OnHold, if and only if the checkonhold parameter in ocsp.conf was set to true.

7. Sign the OCSP response

8. Billing
   As described in the previous section.

9. Send the OCSP response