OCSP Fallback Responder

This article is new for Nexus OCSP Responder 6.3.0.

This article describes the Nexus OCSP responder Fallback type and how to configure it.

Introduction

The Fallback responder is the de facto responder to use when OCSP response freshness (when up-to-date revocation status) is an absolute must.

When to use the Fallback Responder

Nexus OCSP responder typically employs a push/pull mechanism to get the latest Certificate Revocation List (CRL). By use of Delta CRLs configured to be issued immediately by the CA upon revocation of a certificate, the OCSP responder can be updated very fast. Depending on latencies in networks, etc, this approach may still result in a temporary desynchronization between the OCSP responder and the CRL information, typically lasting only a few seconds. When such behavior is deemed unacceptable, the OCSP fallback responder can be utilized in combination with Nexus Certificate Manager to ensure the best up-to-date response.

Drawbacks of Fallback Responder.

The fallback responder performs additional checks towards Certificate Manager (CM) REST API when needed, in order to ensure fresh and accurate OCSP response.

Typically, this check is performed when a certificate issued by the Certificate Manager and is not listed on the OCSP's Certificate Revocation List (CRL). In such cases, the OCSP fallback responder will make an additional request to the REST API to use the most recent revocation status, as the OCSP alone cannot confirm whether a new CRL has been issued.

Requirements

The OCSP fallback responder is applicable solely for issuers that are set up in the Certificate Manager. Furthermore, the certificates issued by this issuer must be recognized by CF (either imported or issued by Certificate Manager).
The OCSP fallback responder necessitates a Certificate Manager that is configured with the PGW Rest API and is readily accessible.

Fallback Responder Configuration

Configuration of the fallback responder requires:

A Smart ID Certificate Manager (CM) Officer Officers and roles in Certificate Manager. (Typically a .p12 but can also be a hardware token)
The officer must have all of the roles configured by the requiredRoRoles setting in certificates handler in api.properties in PGW. (Use clients is the default)
The Officer’s root CA Certificate.
The server certificate presented by Protocol Gateway.

Configuration	Description	Type description

Configuration	Description	Type description
`fallback.certificate=<certificate pattern>` `fallback.pin=<PIN>`	Configures the Certificate Manager Officer used to perform HTTPS request towards Certificate Manager (CM) REST API. The Officer token must be configured in the Key management section `fallback.certificate`: specifies the client certificate DN used to perform HTTPS request towards PGW REST API. `fallback.pin`: specifies the pin for the officer token. The PIN code can be scrambled in the configuration.	`<certificate pattern>`: see Introduction to LDAP
`fallback.truststore=<folder path>`	The Trusted Certificate store for the HTTPS client is the designated location for the PGW server certificate. OCSP will not perform requests towards untrusted server certificates, additionally OCSP will perform host name validation on any server certificate presented.	`<folder path>`: path to a folder in the system. Relative paths are relative to <configuration root>.
`fallback.url=<url>`	the URL of the "GET List certificates" endpoint defined by protocol-gateway. Certificate Manager (CM) REST API	`<url>`: URL safe string. configuration error will occur at startup if the URL is not URL safe.
`fallback.checkonhold=[true\|false]`	Defines whether to execute a CF Fallback when a certificate status is found in the CRL with On hold reason code. In this scenario, the certificate may be reinstated, allowing it to be removed from the Certificate Revocation List (CRL) through a new PUSH of CRL. This situation can potentially cause desynchronization between the CRL and the OCSP responder, this situation might lead to the need for an additional check. Default: `false`

Example Fallback Responder Configuration

This configuration has 2 tokens in the key store,ocsp-fallback-signer-1.p12 andocsp-fallback-officer-1.p12 representing the signer and officer credentials.

The ocsp-fallback-officer-1.p12 holds the credentials for the certificate manager officer used to perform the HTTPS request towards Certificate Manager (CM) REST API.

responder.1.type=fallback
responder.1.url=http://*:8080/fallback&checkonhold=false
responder.1.workers=5

responder.1.signer.1.issuerdn=cn=ocsp-fallback-CA
responder.1.signer.1.certificate=cn=ocsp-fallback-signer
responder.1.signer.1.signingalgorithm=SHA256withRSA
responder.1.signer.1.pin=1234

responder.1.fallback.certificate=CN=ocsp-fallback-officer-1,O=OCSP Test,C=SE
responder.1.fallback.pin=1234
responder.1.fallback.truststore=fallback-truststore/
responder.1.fallback.url=https://pgwy:8444/pgwy/api/certificates
responder.1.fallback.checkonhold=false

key.store.store.1=ocsp-fallback-signer-1.p12
key.store.store.1.pin=1234

key.store.store.2=ocsp-fallback-officer-1.p12
key.store.store.2.pin=1234

Logging filtering example

Example: Filter logs from the CfFallback modifier (the one performing the request towards PGW) towards the folder logs/ with file prefix ocsp-fallback.

agent.log.4.type = file
agent.log.4.prefix = log/ocsp-fallback
agent.log.4.filter = type=CfFallback