Nexus' software components have new names:

Nexus PRIME -> Smart ID Identity Manager
Nexus Certificate Manager -> Smart ID Certificate Manager
Nexus Hybrid Access Gateway -> Smart ID Digital Access component
Nexus Personal -> Smart ID clients

Go to Nexus homepage for overviews of Nexus' solutions, customer cases, news and more.


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.


Expand/Collapse All

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

Related information