Validation section
This article is valid for Nexus OCSP Responder 6.2.2 and later.
This article describes how to configure Nexus OCSP Responder to validate a certificate. This is done in the "Validation" section of the Nexus OCSP Responder configuration file. Certificates can be validated by checking for revocation data locally in a CRL (Certificate Revocation List) or (if enabled) in a CIL (Certificate Issuance List) cache or by forwarding the request to a remote OCSP responder.
It is recommended to configure no more than one validator per type (CRL or CIL). A validator can be configured with multiple providers of different types (pull or push).
Each validator works against a cache, where all the CRLs/CILs that are obtained by the configured providers are placed. The cache is stored in a directory on disk where every new CRL/CIL is saved. The default cache directories are crls for the CRL validator and cils for the CIL validator. At restart, the caches are initialized from these directories. You can manually copy certain CRLs/CILs to the directories before you start Nexus OCSP Responder the first time.
Specify validator types
A validator can be of type: CRL or CIL.
In the OCSP configuration file, specify as follows:
CODEocsp.validation.<v#>.type=[crl|cil]
Description of constants and values:
Constants and Values | Description |
---|---|
| Replace |
| Enter Enter |
Specify providers for the validators
For each validator:
Specify at least one provider to keep the CRL cache constantly up-to-date. This can be done by pull or push methods:
type=pull
- Periodically polling a directory for new CRL versions. Note that pull is not available for CILs.type=push
- Waiting for incoming CRLs/CILs, pushed from a CA, for example, Nexus Certificate Manager.
For each provider, specify as follows in the OCSP configuration file:
ocsp.validation.<v#>.provider.<p#>.type=[pull|push]
Description of constants and values:
Constants and Values | Description |
---|---|
| Replace |
| Replace |
pull | push |
|
CRL providers with type=pull
are not available for CILs.
Configure CRL provider type Pull
The CA that provides the directory service can supply one or more alternative site(s). If so, you can specify a list of URLs.
Specify the LDAP/LDAPS URL(s) for the directory according to RFC 2255 The LDAP URL Format. See also Introduction to LDAP.
For each CRL provider with
type=pull
, configure how to find the directory. This can be done by the use of either the LDAP/LDAPS protocol or the HTTP/HTTPS protocol. Identify the specifications for each site by a URL sequence number. In the OCSP configuration file, specify as follows:CODEocsp.validation.<v#>.provider.<p#>.url.<u#>= [[ldap|ldaps]://<host>[:<port>]/<dn>? [certificaterevocationlist|deltacertificaterevocationlist]] | [[http|https]://<host>[:<port>]/<path>]
If login is required for a certain provider you must specify the parameters
...username
and ...password
.CODEocsp.validation.<v#>.provider.<p#>.url.<u#>.username=<user name> ocsp.validation.<v#>.provider.<p#>.url.<u#>.password=<password> ocsp.validation.<v#>.provider.<p#>.period=<time expr> ocsp.validation.<v#>.provider.<p#>.ignoreIDP=[true|false]
Description of constants and values:
Constants and Values | Description |
---|---|
| Replace |
| Replace |
| Replace |
|
|
| Replace |
| Replace |
|
|
|
|
| Replace |
| Replace |
| Replace |
| Replace Default: |
| The CRL may contain an Issuing Distribution Point (IDP) extension. IDP marks a CRL as being incomplete, and thus reliable revocation queries cannot be answered from it. If you have out of band information that a CRL with an IDP is indeed complete, you may force Nexus OCSP Responder to accept this CRL.
Default: |
Example
ocsp.validation.1.type=crl
ocsp.validation.1.provider.1.type=pull
ocsp.validation.1.provider.1.url.1=
ldap://directory/cn=Test CA2,
o=Nexus OCSP Responder,
c=se?certificaterevocationlist
ocsp.validation.1.provider.1.url.1.username=cn=admin,c=se
ocsp.validation.1.provider.1.url.1.password=****
ocsp.validation.1.provider.1.url.2=http://backuphost.com/testca2.crl
ocsp.validation.1.provider.1.period=P1D
Configure CRL/CIL provider type Push
For each provider with
type=push
, specify as follows in the OCSP configuration file:CODEocsp.validation.<v#>.provider.<p#>.listen.url=<URL> ocsp.validation.<v#>.provider.<p#>.ignoreIDP=[true|false] ocsp.validation.<v#>.provider.<p#>.ssl.clientauth=[true|false] ocsp.validation.<v#>.provider.<p#>.ssl.certificate=<certificate pattern> ocsp.validation.<v#>.provider.<p#>.ssl.pin=<PIN> ocsp.validation.<v#>.provider.<p#>.ssl.cipher=<cipher suites> ocsp.validation.<v#>.provider.<p#>.ssl.protocol=<protocols>
Description of constants and values:
Constants and Values | Description |
---|---|
| Replace |
| Replace |
| Replace |
| If HTTPS is used, a key and certificate needs to be specified. See Key management section. |
| If HTTPS is used, a key and certificate needs to be specified. See Key management section. |
| The CRL/CIL may contain an Issuing Distribution Point (IDP) extension. IDP marks a CRL/CIL as being incomplete, and thus reliable revocation queries cannot be answered from it. If you have out of band information that a CRL/CIL with an IDP is indeed complete, you may force Nexus OCSP to accept this CRL/CIL.
Default: |
|
Default: |
| 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. If no ciphers are specified all the following default will be enabled: |
| A comma separated list of TLS protocols that should be enabled. If HTTPS is enabled, then limit the number of enabled security protocols to a subset of the default. If no protocols are specified the following default will be enabled: |
Example
ocsp.validation.1.type=cil
ocsp.validation.1.provider.3.type=push
ocsp.validation.1.provider.3.listen.url=http://ocsphost.com:87/