Building and Configuring the OCSP Responder

After completing the VA installation according to the Standalone VA installation instructions, continue with the following steps to complete the installations:

Step 1: On the EJBCA VA - Accessing the Admin GUI

Step 2: On the EJBCA CA - Create the OCSP responder CA

Step 3: On the EJBCA VA - Set up the responder signing keys

Step 1: On the EJBCA VA - Accessing the Admin GUI

The OCSP responder has the same Admin GUI as the CA, so you can manage all your Crypto Tokens and Key Bindings using the Admin GUI (or the CLI see below).

In an OCSP responder, you normally only use a few functions of the Admin GUI, although all of them are available. The important functions for an OCSP responder are:

  • Crypto Tokens

  • Internal Key Bindings

Prerequisites for Admin GUI access:

  • Available TLS keystores as p12/tomcat.jks and p12/truststore.jks (copies from the EJBCA CA), to be deployed with deploy-keystore and web-configure (may require configuration of keystore password in conf/web.properties).

  • An imported Management CA certificate (the certificate of the CA that issues administrator certificates).

  • Configured Administrators with access rules.

If you only want to set up a super administrator, the initial super administrator access rule is automatically set up during the initial startup (see database tables AdminGroupData and AccessRulesData). You can run the following commands to import a Management CA certificate and add a SuperAdmin, that has a certificate with "CN=SuperAdmin" issued from this CA (this will create a record in database table AdminEntityData).

bin/ejbca.sh ca importcacert ManagementCA /home/user/adminca1.pem
bin/ejbca.sh roles addmember "Super Administrator Role" ManagementCA WITH_COMMONNAME TYPE_EQUALCASE SuperAdmin

If you do not want to import the administrator certificate into EJBCA, you can configure web.reqcertindb=false in conf/web.properties.

Otherwise the administrator certificate must be present in the database (can be imported using the CLI).

Step 2: On the EJBCA CA - Create the OCSP responder CA

If the CA that is meant to be the OCSP responder does not already exist, create it now. All certificate profiles for certificates that should be available to the OCSP responder should reference this publisher. Super administrator access is required for this configuration.

Step 3: On the EJBCA VA - Set up the responder signing keys

If you haven't done that already, import the CA that is meant to be the OCSP responder from the EJBCA CA.

The keys used to sign the OCSP response are referenced through Crypto Tokens (that could be either soft or HSM/PKCS#11 based). There should be one key for each CA, and the each CA the responder answers for an OCSP signing certificate must be issued.

The certificate profile could be the same for all issued OCSP signing certificates.

To issue OCSP signer certificate from EJBCA, define a new certificate profile and use 'OCSPSIGNER (FIXED)' as template (clone). This certificate profile is like a normal end entity profile, but with the following key usages:

- Key Usage: Digital Signature
- Extended Key Usage: OCSPSigner

Configure the newly created certificate profile to use the OCSP publisher defined above. You also need to create a new End Entity Profile to use the new Certificate Profile. You should then create a user for each CA using this certificate profile. Use the token type User generated.

The OCSP responders certificate(s) AND the CA certificate(s) need to be published from the CA to the OCSP responder. For the CA you do this by setting the CRL publisher to the OCSP publisher.

No Password in Memory

To avoid that passwords are kept in memory, use manual activation of your referenced Crypto Tokens.

Database Index

As your OCSP database grows with revoked, and active, certificates you will need database indexes to maintain good performance. See the file doc/sql-scripts/create-index-ejbca.sql (section for certificate data) for indexes needed for CA and OCSP operations.

Setting the Default Responder

The default responder is the valid CA or OCSP Keybinding set to sign responses to requests that come in for unknown issuers.

For all unknown issuers the default responder will reply with an 'UNKNOWN' response. For external CAs without dedicated OCSP keybindings the default responder will perform standard OCSP lookups. Be aware that this may cause unexpected behavior in the case of where an inactivated (due to responder certificate being revoked or expiring) keybinding exists, and that keybinding has a different behavior in regards to unknown certificates than the default responder.

If no default responder is defined, is defined incorrectly, or the chosen responder doesn't have a certificate, the responder will reply "Unauthorized" (as per RFC2560) with a null payload.

Setting the Default Responder from the GUI

You can choose the default responder from the list menu in the OCSP Internal Keybindings page in the GUI, which will show all valid CAs and keybindings. It will also provide the option to choose none and allow retaining an old but unmatched value imported via migration from configurations earlier than version 6.2.4

Setting the Default Responder from the CLI

The default responder can also be chosen from the CLI with the following command.

bin/ejbca.sh ocsp setdefaultresponder <DN>

To see a list of valid responders, run the command with the --help switch. This will also show the current chosen responder.

Responder ID Type for CAs

Local CA's will automatically answer OCSP responses for themselves, unless an OCSP Keybinding has been set up for them. This setting defines the general responder ID type for CA's acting as their own responders. Just like for an OCSP Keybinding, the responder ID type is either a Name (SubjectDN of the signing certificate used for response) or Keyhash (SHA-1 digest of the public key of the signing certificate used for response).

CLI Example: Setting up a Responder

In this example, there is a CA that can be offline and an OCSP responder will be set up using the CLI that answers for this CA.

A basic EJBCA instance that you can use CLI commands on (no CA needed) should be installed prior to performing the following steps.

The order of events are as the workflow above, with an extra step of importing the CA certificate:

  1. Import the CA certificate (of OCSP_CA) as an External CA in the OCSP responder.

  2. Create a Crypto Token and generate the OCSP responders signing key.

  3. Create an OCSP Key Binding, which is the configuration of the OCSP responder answering queries.

  4. Generate a CSR for the OCSP Key Binding, sending the CSR to the External CA and getting a signed OCSP signer certificate back.

  5. Import the OCSP signer certificate and activate the OCSP Key Binding.

Use the following commands and note that the External CA is called OCSP_CA and has DN 'CN=OCSP_CA'.

bin/ejbca.sh ca importcacert OCSP_CA /home/tomas/tmp/OCSP_CA.pem
bin/ejbca.sh cryptotoken create OCSPCryptoToken foo123 true SoftCryptoToken true
bin/ejbca.sh cryptotoken generatekey OCSPCryptoToken ocspsignkey RSA2048
bin/ejbca.sh keybind create OCSP_CA_KeyBinding OcspKeyBinding DISABLED null OCSPCryptoToken ocspsignkey SHA256WithRSA -nonexistingisgood=false -includecertchain=true
bin/ejbca.sh keybind gencsr OCSP_CA_KeyBinding csr.pem
 
(send the csr to OCSP_CA and get signed certificate back)
 
bin/ejbca.sh keybind import OCSP_CA_KeyBinding ocsp.pem
bin/ejbca.sh keybind setstatus OCSP_CA_KeyBinding ACTIVE
 
(now your OCSP key binding is active and can be used to sign OCSP queries)

Test the responder by querying for status of the OCSP signer certificate itself:

openssl ocsp -issuer OCSP_CA.pem -CAfile OCSP_CA.pem -cert ocsp.pem -req_text -url http://localhost:8080/ejbca/publicweb/status/ocsp
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: E4A38A2DB963CAA8EEDFE4FBD396EE1E9B82FC19
Issuer Key Hash: EF9C1460AEEF978FCFD30A3E7B1A2CE0BF36F9AB
Serial Number: 054C3D7EA9E92EA5
Request Extensions:
OCSP Nonce:
0410ED1DFBA35756BBBF033FABB4055166E0
Response verify OK
ocsp.pem: good
This Update: Feb 5 12:58:43 2014 GMT

Get a certificate, received on file (qwe.pem), issued by the OCSP_CA. We can feed certificates, as whitelist, to the responder in many different ways (it's a normal database). But before we import it to the OCSP responder, we can check status, which should be unknown (with the current configuration) when it is not present in the OCSP database.

openssl ocsp -issuer OCSP_CA.pem -CAfile OCSP_CA.pem -cert qwe.pem -req_text -url http://localhost:8080/ejbca/publicweb/status/ocsp
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: E4A38A2DB963CAA8EEDFE4FBD396EE1E9B82FC19
Issuer Key Hash: EF9C1460AEEF978FCFD30A3E7B1A2CE0BF36F9AB
Serial Number: 5033A405556C4C26
Request Extensions:
OCSP Nonce:
0410CF2AA349C1EAF562650CE38FC9AD75B7
Response verify OK
qwe.pem: unknown
This Update: Feb 5 13:00:51 2014 GMT

Enabling Nonce Extension On CAs

The OCSP nonce extension can be disabled both per OCSP Keybinding, and also globally for all CAs acting as their own OCSP responders. Disabling nonces globally will not affect whether OCSP keybindings use the nonce extension in their responses.