Versions Compared

Version Old Version 4 New Version Current
Changes made by

Ylva Andersson

Ylva Andersson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: OCSP 6.3.0: Updates in the “Workflow for responders of type fallback” section.
Info

This article includes updates for Nexus OCSP Responder 6.3.0.

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

...

This responder type requires that a CM-SDK connection to Certificate Manager (CM) is configured With PGW REST API available. See section “Configurations for cmsdk-connection” in Default OCSP configuration
See section /wiki/spaces/ID/pages/691404808 for more information.

The Fallback responder type provides a real-time certificate status by querying the CM database with the help of the CM-SDKPGW. 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.

PGW.

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.OCSP forwarding
    As described in the previous section.

  4. 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.

  5. CM Validation
    OCSP responder will fallback to CM sending a CM-SDK through PGW by sending an HTTPS 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.

  6. Sign the OCSP response

  7. Billing
    As described in the previous section.

  8. Send the OCSP response