- This line was added.
- This line was removed.
- Formatting was changed.
This article describes how to specify the OCSP responders that shall handle the incoming OCSP requests (these OCSP responders are referred to as 'the logical OCSP responders', for more information, see Nexus OCSP Responder architecture overview). The specification is done in the "OCSP responder" section of the Nexus OCSP Responder configuration file. There are predefined OCSP responders with different semantics. Use the
type parameter to specify which one to use. The workflows for different types of OCSP responders are described in Workflow for Nexus OCSP Responders.
- A responder may also forward the request to a remote OCSP responder.
- Each responder can support multiple CAs.
- Configure a signer for each CA that the responder should support.
- In the responders, configure each CA that shall be supported.
The responder replies with status 'Unknown' to OCSP requests for certificates issued by CAs that the responder is not responsible for. When receiving requests related to CAs that are not supported, the first configured signer is used to sign the response. This means that a default "dummy" signing certificate can be configured as the first supported issuer/signer for responding to irrelevant or malicious requests.
To read more regarding access control, see Access control and billing.
Billing is described in Access control and billing.
Forwarding of requests is carried out by the back end OCSP client, which by default will use the settings you made in Back end client section, section"Specify OCSP client request". To override any of these settings, add a new specification here.
In this example, forwarding is enabled for queries related to certificates issued by the My CA authority.
These three settings are also available:
For a description of the freshness proof functionality, see Freshness proof.
If you add freshness proof, be sure that you have specified OCSP response cache renewing. For more information see OCSP response cache section.
The freshness proof process is carried out by the back end OCSP client, which by default will use the settings you made in Back end client section, section"Specify OCSP client request". To override any of these settings, add a new specification here. Use the same syntax as described for the back end client but replace
You can configure Nexus OCSP Responder to automatically shut down if an internal error occurs (when the sent OCSP response has internal error status).
Nexus OCSP responder configuration
In the following examples, different responders are configured. Note that these examples are not complete configurations of the Nexus OCSP Responder.
Nexus OCSP responder proxy configuration
Use this sample configuration to set up Nexus OCSP Responder to forward all incoming OCSP requests to another (OCSP) responder:
Use this sample configuration to set up Nexus OCSP Responder to forward all incoming OCSP requests to another (OCSP) responder using client authentication:
This article is valid includes updates for Nexus OCSP Responder 6.1 and later2.4.
- Access control and billing
- Back end client section
- Configure Nexus OCSP Responder
- Distinguished name matching
- Freshness proof
- Key management section
- Introduction to LDAP
- Nexus OCSP Responder
- OCSP response cache section
- Trust store