Deployment scenario

1. Nexus OCSP Responder is used in an environment that can be considered secure and easily manageable, for instance within an intranet or "test lab" environment.
   Deployment decision:
   1. OCSP can be carried over HTTP (no TLS).
   2. The OCSP clients do not need to authenticate themselves to the server, neither through client authentication in TLS, nor by signing the requests.
   3. No auditing or billing is necessary.
2. Access and file permissions given by the operating system are considered enough for sensitive data.
   Deployment decision:
   1. Security hardware is not necessary to protect the Nexus OCSP Responder's keys; a pin-protected file is enough.

3. The Nexus OCSP Responder will be used as the local source of revocation information from two external CAs, that are used in the organization's PKI. The CAs periodically publish revocation lists and Nexus OCSP Responder must be configured to download these lists.
   The two CAs are:

   1. Acme TrustCenter
      Publishes a certificate revocation list (CRL) every 6 hours at ldap://directory.acme.com, under the CA object entry cn=CA01,o=Acme TrustCenter,c=SE, under the LDAP attribute certificaterevocationlist. Also publishes a delta CRL once every hour to the same location, under the LDAP attribute deltacertificaterevocationlist.

   2. Bank X
      Publishes a CRL every 3 hours at http://www.bankx.com/bankx.crl.

1. Prepare the Nexus OCSP Responder keys and certificate.
   1. In this case, only an OCSP response signing key pair is needed. The corresponding certificate must be issued by a CA, that is trusted by the connecting clients.

   2. The private key and the OCSP signing certificate can be stored in a Hardware Security Module (HSM) or a .p12 file. In this example a .p12 file is used. The certificate must contain the extendedKeyUsage extension (OID 2.5.29.37), including the OCSP-Signing purpose (OID 1.3.6.1.5.5.7.3.9).

      

      Connecting clients will receive a signed OCSP response. The signature will in turn be validated. It is very easy to trigger a dead-lock situation, having clients asking the Nexus OCSP Responder about the status of the responder's own signature certificate. To avoid this situation, it is recommended that the OCSP signature certificate also contains the OCSP NoCheck extension (OID 1.3.6.1.5.5.7.48.1.5). Also, consider the possible security ramifications of adding this extension (revoking this certificate will have no effect).

   3. In this example, the OCSP responder certificate is issued by the local organization's own CA, and contains the following extensions:

      1. keyUsage: digitalSignature

      2. extendedKeyUsage: OCSP-Signing

      3. OCSP-NoCheck: (null)

2. Collect information about trusted certificates.
   Make sure you have the certificates of the external CAs, as well as the CA certificate used to sign the OCSP signing certificate.

3. Install Nexus OCSP Responder on a (dedicated) machine. See Install and upgrade Nexus OCSP Responder.

4. Install the OCSP signing certificate.

   1. Copy the file containing the OCSP responder private key and certificate locally to the machine where Nexus OCSP Responder is installed.

   2. Point out the location of the file in ocsp.conf.

5. Set up the trust store.

   1. Use the certadm tool to add all certificates used for terminating trusted certificate chains.
      In this example, those certificates would be:

      1. the Acme TrustCenter CA certificate

      2. the Bank X CA certificate

      3. the local root CA certificate

Example:

% cd <ocsp install directory>/bin
% certadm new --store=../certs/trust.store
% certadm add --store=../certs/trust.store --file=acmeca.crt
% certadm add --store=../certs/trust.store --file=bankxca.crt
% certadm add --store=../certs/trust.store --file=rootca.crt
% certadm list --store=../certs/trust.store
(1) cn=CA01,o=Acme TrustCenter,c=SE
(2) cn=Customer CA,o=Bank X,c=US
(3) cn=Local CA,o=OurCompany,c=SE

1. Open the configuration file ocsp.conf for editing.
   This file is by default located in the config directory under the installation directory in Linux environments, and under C:\ProgramData\Nexus\ocsp\config in Windows environments.
2. Specify a validator that works against CRLs. See Validation section.
3. Add CRL providers that will periodically pull CRLs to the local CRL cache.
   

   1. Specify the provider for the Acme TrustCenter CRL. Use the output of the certadm program when entering the LDAP URL, to ensure to get the object entry correct (cut & paste).

      CODE

      ocsp.validation.1.type=crl
      ocsp.validation.1.provider.1.type=pull
      ocsp.validation.1.provider.1.url.1=ldap://directory.acme.com/
      cn=CA01,o=Acme TrustCenter,c=SE?certificaterevocationlist

   2. Add another provider for the the Acme TrustCenter delta CRL.

      CODE

      ocsp.validation.1.provider.2.type=pull
      ocsp.validation.1.provider.2.url.1=ldap://directory.acme.com/
      cn=CA01,o=Acme TrustCenter,c=SE?deltarevocationlist

   3. Add a provider for the Bank X CRL.

      CODE

      ocsp.validation.1.provider.3.type=pull
      ocsp.validation.1.provider.3.url.1=http://www.bankx.com/bankx.crl

Use the default settings in this scenario.

• Allow requests to come in from all network interfaces.
• The load on the machine is unknown, but allow a maximum of 10 requests to be processed simultaneously.
• At the same time, it safeguards against flooding the computer CPU usage at times with intense loads.
• Assume that there is no web server or other application that will cause conflicts when using port 80 (the default HTTP port).

1. Configure the responders:

   CODE

   responder.1.type=basic
   responder.1.url=http://*:80/
   responder.1.workers=10

2. To configure the responder key, specify a trusted issuer and a responder certificate found in a key store. The certificate is identified by a simple certificate matching pattern; in this case the CN portion of the responder certificate subject DN, as is.

   CODE

   responder.1.signer.1.issuerdn=cn=CA01,o=Acme TrustCenter,c=SE
   responder.1.signer.1.certificate=cn=Local OCSP Responder
   responder.1.signer.1.pin=secretPIN1234

3. Specify where to find this certificate and key. In this example, a PKCS #12 file is used.

   CODE

   key.store.store.1=local-ocsp-responder.p12
   key.store.store.1.pin=secretPIN1234

1. Use the default settings in this scenario. See Log messages and log filters.
2. Start the system.
   1. Examine the logs for any "critical" or "error" messages.
   2. To double-check that the CRL providers are downloading CRLs, look in the CRL cache directory (default <ocsp installdir>/crls on Linux, or %ALLUSERSPROFILE%\Nexus\ocsp\crls on Windows).
      

1. Configure all OCSP clients to point their OCSP questions to the HTTP URL specified in the "Configure Nexus OCSP Responder, part 2: Responder" section above.
2. The system can be left as-is until it is time to renew the responder certificate.