OCSP responder section
This article includes updates for Nexus OCSP Responder 6.2.4.
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.
Specify the OCSP responders
It is mandatory to specify at least one responder and set the following parameters:
...type
...url
...workers
...signer.x.issuerdn
...signer.x.dn
...signer.x.pin
Authentication, authorization and billing are disabled by default.
For each OCSP responder, specify as follows in the OCSP configuration file:
responder.<r#>.type=[basic|cached|identrus-basic|identrus-cached|non-issued-basic|non-issued-cached|fallback] responder.<r#>.url=[http|https]://<host>[:<port>][/<path>] responder.<r#>.ssl.clientauth=[true|false] responder.<r#>.ssl.certificate=<certificate pattern> responder.<r#>.ssl.pin=<PIN> responder.<r#>.ssl.cipher=<cipher suites> responder.<r#>.ssl.protocol=<protocols> responder.<r#>.workers=<# of workers> responder.<r#>.connections=<# of connections> responder.<r#>.socketreadtimeout=<socket read timeout> responder.<r#>.forwarding.enabled=[true|false] responder.<r#>.signer.<s#>.issuerdn=<distinguished name> responder.<r#>.signer.<s#>.certificate=<certificate pattern> responder.<r#>.signer.<s#>.signingalgorithm=<algorithmname> responder.<r#>.signer.<s#>.pin=<PIN> responder.<r#>.signer.<s#>.setnextupdate=[true|false] responder.<r#>.archivecutoff=[true|false]
See this table for description of constants and values:
Constants and Values | Description |
---|---|
| Replace |
|
|
|
|
| Replace Default: The port defaults to 80 when HTTP is used and to 443 for HTTPS. |
|
Default: |
| See Key management section for |
| See Key management section for |
| A comma separated list of TLS cipher suites that should be enabled. If HTTPS is enabled, then limit the number of enabled cipher suites to a subset of the default. By default, all the supported cipher suites of Java's SunJSSE provider described in Java Secure Socket Extension (JSSE) Reference Guide for JDK 11 under the section "SunJSSE provider", are enabled. |
| A comma separated list of TLS protocols that should be enabled. If HTTPS is enabled, then limit the number of enabled protocols to a subset of the default. By default all the supported protocols of Java's SunJSSE provider described in Java Secure Socket Extension (JSSE) Reference Guide for JDK 11Â under the section "SunJSSE provider", are enabled. |
| Replace |
| Replace |
| Replace Default: PT1M |
| Replace If not defined, the signing algorithm will default to |
| Enter Default: false. |
| Replace |
| Replace |
| Replace |
| Replace |
| Enter |
| Enter |
Specify limitations on incoming requests
To read more regarding access control, see Access control and billing.
Specify limitations on the incoming requests to the OCSP responder as follows:
responder.<r#>.incoming.signature.required=[true|false] responder.<r#>.incoming.authorization=[none|bynamematch|byauthentication]
If you enter
bynamematch
you also have to specify a table of rules to find a match of the distinguished name as follows:responder.<r#>.incoming.authorization.match.<n#>=<distinguished name>
See also Distinguished name matching and Access control and billing.
In addition, you can also use a certificate pattern to filter allowed client requests, specify as follows:
See this table for description of constants and values:
Constants and Values | Description |
---|---|
| Replace |
| Enter Default: |
| This configures authorization of the client certificate. If the request is signed, that certificate will be verified during authorization. Otherwise the client certificate used in the TLS handshake will be verified.
Default: |
| Replace |
| Replace |
| A certificate pattern as described in Introduction to LDAP. Filters authenticated certificates on certificate attributes (part of the authorization scheme). Default is not to filter, which allows any authenticated certificate to bypass the filter mechanism. |
Specify responder and responses
In the OCSP configuration file, specify as follows:Â
See this table for description of constants and values:
Constants and Values | Description |
---|---|
| Replace |
| Enter Default: If this parameter is set to  |
|
Default: none The parameter  |
|
Default: |
| Enter Default: This parameter is relevant only when |
|
Default: |
| Set this parameter to Default: |
| Use this parameter to align HTTP responses with RFC9112 by adding a space after the status code, even if there isn't a reason-phrase. If set to Default: |
Specify billing information
Billing is described in Access control and billing.
In the OCSP configuration file, specify as follows:
See this table for description of constants and values:
Constants and Values | Description |
---|---|
| Replace |
| Enter Default: |
| Enter Default: |
| Enter Default: |
| Enter Default: |
| Enter Default: |
Specify forwarding of requests
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.
Use the same syntax as described for the back end client but replace
ocsp.client
withresponder.<r#>.forwarding.client
, where<r#>
is the responder sequence number.
Example:
In this example, forwarding is enabled for queries related to certificates issued by the My CA authority.
These three settings are also available:
This setting allows the back end client to modify the request before it is sent to another responder. OCSP forwarding really means "send the message, as it is, to another responder".
Default:false
This setting defines a match table for what issuers that OCSP forwarding should be enabled for. <
issuermatch
> is matched against the issuer DN. Wildcards are allowed.If the back end client receives a valid response, this response is sent to the requesting client and the validation is finished. The parameter
responseWhenInvalidResponseFromBackEndClient
controls what Nexus OCSP Responder will do if the back end client failed to retrieve a valid response.Enter
unknown
to have Nexus OCSP Responder not respond, but rather continue with other modules, such as CRL/CIL checks. This will most likely result in an "unknown" response to the client. Note that this will cause Nexus OCSP Responder to sign the response using the default signer for that responder.Enter
trylater
to have Nexus OCSP Responder pass back "Try later" in the OCSP response.Enter
internalerror
to have Nexus OCSP Responder pass back "Internal error" in the OCSP response.Default:
trylater
Specify freshness proof
For a description of the freshness proof functionality, see Freshness proof.
In the OCSP configuration file, specify as follows for
type=identrus-cached
:See this table for description of constants and values:
Constants and Values | Description |
---|---|
| Replace |
| Enter Default: |
Specify system control
You can configure Nexus OCSP Responder to automatically shut down if an internal error occurs (when the sent OCSP response has internal error status).
In the OCSP configuration file, specify as follows:
Replace
<n#>
with the number of consecutive internal error responses to return before shutting the system down. A value below 1 disables the functionality.Default value:
-1
.
Specify ping data
In the OCSP configuration file, specify ping data as follows:
Replace
<data>
with a string. When an incoming HTTP POST message contains this data in its body, Nexus OCSP Responder will respond with a simple HTTP 200 OK message and no logs will be produced. This can typically be used by a load balancer to frequently check that the server is up without producing excessive log files in Nexus OCSP Responder.
Examples
View examples
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:
Example 1
Use this sample configuration to set up Nexus OCSP Responder to forward all incoming OCSP requests to another (OCSP) responder using client authentication:
Example 2
Related information
Copyright 2024 Technology Nexus Secured Business Solutions AB. All rights reserved.
Contact Nexus | https://www.nexusgroup.com | Disclaimer | Terms & Conditions