Key management section

This article includes updates for Nexus OCSP Responder 6.3.0.

This article describes how to configure key stores in the Nexus OCSP Responder configuration file. The respective OCSP responder must sign their responses using a key.

As the Nexus OCSP Responder is answering on behalf of the CA, compromise of the keys could have far going consequences, depending on the trust in the relationship between the CA and the Nexus OCSP Responder. Therefore you should take whatever measures necessary to protect the OCSP responder keys.

You can, for example, use Hardware Security Modules (see Set up hardware token.)

If the OCSP responder keys are compromised, there is an inherent problem in revoking them. A solution to this would be to have a very short life span for the OCSP responder certificates and have them reissued and reinstalled that often. When the keys are revoked, the CA cannot reissue the certificate any more.

Key location

Keys can be located in:

PKCS#12 file	Nexus OCSP Responder is able to use keys stored in PKCS #12 (.p12) files. This file is pointed to in ocsp.conf.
3rd party devices	Key pairs may also be located in 3rd party devices, such as hardware security modules (HSMs). This can be done if the HSM has a PKCS #11 library (.dll/so file) that allows certificate objects to be stored in the same token as the key pairs. See Initialize Hardware Security Module for use in Certificate Manager for more information. See also Introduction to PKCS#11.
Cryptographic Library	Key pairs may be located in software tokens in the Cryptographic Library. For information on how to update the library, see Adding Key Pairs to Cryptographic Library. The Cryptographic Library will always be initialized at Nexus OCSP Responder startup.

Specify key location

To be able to find keys, you must always specify at least one key location (key store).

In the Nexus OCSP Responder configuration file, specify as follows:
CODE
```
key.store.store.<#>=<file>
key.store.store.<#>.pin=<pin>
key.store.store.<#>.nopinpad=<false|true>
key.store.store.<#>.tokenlabel=<label>
key.store.store.<#>.reinitializedeviceonerrors=<reinitializedeviceonerrors>
```
For information on how to encrypt the pin, see Encrypt sensitive configuration parameters.
See this table for description of constants and values:

Constants and Values	Description
`<#>`	Replace `<#>` with the sequence number.
`<file>`	Replace `<file>` with either an absolute path or a relative path from `<configuration root>` to either a PKCS #11 library or a PKCS #12 file.
`<pin>`	Optional. Used for decrypting the PKCS #12 file.
`<nopinpad>`	Optional. Will ignore reports from the PKCS#11 library that the HSM has a protected authentication path, that is, a pin pad reader or some other means of authenticating without passing the PIN through the PKCS#11 library. This setting should not be needed other than in special cases of certain HSM vendors with non-standard PKCS#11 implementations.
`<tokenlabel>`	Optional. Specifies the token label name of the PKCS#11 token where the signing certificate/key resides. If specified, the PKCS#11 keystore will only make sessions to the specified token. This parameter is optional but highly recommended.
`<reinitializedeviceonerrors>`	Optional. Controls on which errors the PKCS#11 library should be reinitialized when performing a login or private key operation. The device is not reinitialized by default. By default, the device is reinitialized for errors 0x30, 0x32, 0xE1, 0xE2, 0x101 and 0x190. Specify as list of error codes (comma or space separated), for example reinitializedeviceonerrors=0x30 0x101. Adding this parameter will override the default values.

Example:

CODE

key.store.store.1 = ocsp_signer.p12
key.store.store.1.pin = 1234
key.store.store.2 = lib/libcs_pkcs11_R3.so
key.store.store.2.nopinpad = false
key.store.store.2.tokenlabel = ocsp-token
key.store.store.2.reinitializedeviceonerrors= 0x30 0x101

Specify keys

Before performing an operation that requires a key, the Nexus OCSP Responder gets the applicable key from the configured key source. Nexus OCSP Responder can use any of the keys available in the configured key stores, as described above in section "Specify key location”.

The following types of keys may be required by Nexus OCSP Responder:

For signing responses:	Specify one key per supported issuer per OCSP responder.
For signing requests:	Specify one key to be used by the back end client. If this setting is to be overridden by a forwarding OCSP responder, you have to add a corresponding key.
For TLS server authentication:	Specify one key per interface and port that will be used by an OCSP responder or a CRL / CIL provider with `type=push`, using the HTTPS protocol.
For SSL client authentication:	Specify one key to be used by the back end client. If this setting is to be overridden by a forwarding OCSP responder, you have to add a corresponding key.

When a key is required, a PIN must also be provided. You can specify the PIN value for each key entity in the configuration file (parameter ...pin). For information on how to encrypt the PIN, see Encrypt sensitive configuration parameters.
Specify as follows in the Nexus OCSP Responder configuration file:
CODE
```
<prefix>.certificate=<certificate pattern> <prefix>.pin=<PIN>
```
See this table for description of constants and values:

Constants and Values	Description
`<prefix>`	Configuration parameter prefix depending on which type of key is being configured. For example, an OCSP response signing key is configured with the `responder.<#>.signer` prefix, as shown in OCSP responder section.
`<certificate pattern>`	Replace `<certificate pattern>` with the certificate pattern to specify the key pair. For a description of the syntax, see Introduction to LDAP, heading "LDAP certificate patterns".
`<PIN>`	Replace `<PIN>` with the PIN for the key pair.

Examples

Example: OCSP response signing

Two OCSP responders are specified with the following URLs:

CODE

responder.1.url=http://ocsphost:90/basic
responder.2.url=http://ocsphost:90/cached

The key these responders will use for signing are specified as follows:

CODE

responder.1.signer.1.issuerdn=cn=myCA,c=SE
responder.1.signer.1.certificate=&(issuer=myCA*)(serialNumber=72)
responder.1.signer.1.pin=secretPIN1234
responder.2.signer.1.issuerdn=cn=CA3,c=SE
responder.2.signer.1.certificate=cn=User issued by CA3
responder.2.signer.1.pin=secretPIN1234

Example: Back end client

A back end client is specified with the following ...signature.key parameter:

CODE

ocsp.client.request.signature.key.certificate=&(cn=myCA*)(keyUsage=DigitalSignature)
ocsp.client.request.signature.key.pin=secretPIN1234

Example: TLS server authentication

Three OCSP-responders are specified with the following URLs:

CODE

responder.1.url=https://*:88/secure1
responder.2.url=https://*:88/secure2
responder.3.url=https://ocsphost:89/secure1

The keys these responders will use for TLS server authentication are specified as follows:

CODE

responder.1.ssl.certificate=&(cn=ocsphost)(Issuer=TLS Trust CA*)
responder.1.ssl.pin=secretPIN1234
responder.2.ssl.certificate=&(cn=ocsphost)(Issuer=TLS Trust CA*)
responder.2.ssl.pin=secretPIN1234
responder.3.ssl.certificate=cn=Nexus OCSP Responder*
responder.3.ssl.pin=secretPIN1234

Example: TLS client authentication

A back end client uses a TLS client certificate with the following parameter:

CODE

ocsp.client.authentication.key.certificate=(serialNumber=72)
ocsp.client.authentication.key.pin=secretPIN1234

Key location

Specify key location

Specify keys

Examples

Example: OCSP response signing

Example: Back end client

Example: TLS server authentication

Example: TLS client authentication

Related information