Using the UI on a Remote VA

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

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

• Crypto Tokens

• Internal Key Bindings

Prerequisites for CA UI 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).

Setting up the OCSP Responder Keys

If working on a remote VA, make sure to 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 one OCSP signing certificate must be issued from each CA the responder answers for.

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

To issue an OCSP signer certificate from EJBCA, define a new certificate profile and clone the built-in certificate profile 'OCSPSIGNER'. This certificate profile is like a normal end entity profile, but with the following key usages:

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.

Using a Publisher on the CA

We currently provide two publishers, the EJBCA Peer Publisher which publishes certificates synchronously over TLS and the Legacy VA Publisher which uses direct database publishing.

Using the CRL Download Service

To configure a Service that automatically downloads and populates the mentioned fields from a CRL, do the following:

• Select CA UI → Certification Authorities → Import CA certificate for the CA that you want to serve OCSP responses for.

• Select CA UI → Certification Authorities → Edit CA for the imported CA → Configure an external CDP where the CA makes its CRLs available (must begin with "http://").

• Select CA UI → Services and Add a new Service "CRLDownloadService".

• Select CA UI → Services and Edit "CRLDownloadService":

  • Select Worker: CRL Downloader.

  • CAs to Check: Select the imported CA (or select ANY to process all external X509 CAs with a configured external CDP).

  • Ignore nextUpdate and always download the CRL: Select this option to force a download of the CRL whenever the service is executed instead of only downloading the CRL when the last known CRL indicates that a new one will be available.

  • Maximum allowed size to download (bytes): The Service will refuse to process CRLs that are larger than this limit.

  • Period: How often the Service should check if a new CRL needs to be downloaded.

  • Active: Select to activate the service.

The next time the service is executed, there will be log entries showing if the CRL download and processing was successful. After the first execution of the service you should be able to download the CRL from the VA's Public Web pages.

Next, setup an OcspKeyBinding as described for the case where direct database publishing is used. The only difference is that there is no way for the VA to know if a certificate has ever been issued, so it makes sense to respond OCSP status "good" for unknown certificates.

If the downloaded CRL from the external CDP contains the Freshest CRL extension, the service will try to download and process any such URL that uses "http" as protocol.

Using a Custom Implementation

When running the OCSP responder answering queries from CAs in an EJBCA installation, populate the database using the External OCSP Publisher. For more information, see Building and Configuring the OCSP Responder.

When using other CA software than EJBCA you can populate the database based on data from that system. The only thing needed is to insert data in the CertificateData table on the external OCSP responder.

The values used by the OCSP responder are:

CA certificates and OCSP signer certificates must also be in the database. For these certificates the fingerprint, subjectDN, and base64Cert fields must also be included.

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.

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

Nonce

Nonce is the only standard extension defined. The nonce allows a client to verify that a response really is in response to the specific requests, and not a replayed response. It is recommended that if the OCSP requests contains the nonce extension, the OCSP response also contains the nonce. EJBCA includes the nonce from the client requests in the server response if the requests contain a nonce. 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.

Fnr-Unid Mapping Extension

For information on the Unid functionality, see Unid FNR.

CertHash OCSP Extension

For information on the CertHash functionality, see CertificateHash.

Archive Cutoff

The archive cutoff extension is defined in RFC 6960 section 4.4.4 and is used to "contribute to a proof that a digital signature was (or was not) reliable on the date it was produced even if the certificate needed to validate the signature has long since expired".

The timestamp in the archive cutoff extension can be derived either from the time the OCSP response was produced (as described in RFC6960) or from the notBefore date in the issuer's CA certificate (as mandated by ETSI EN 319 411-2, CSS-6.3.10-08).

The archive cutoff extension is only present in OCSP responses when an OCSP key binding is configured for the CA. For more information and configuration instructions, see Archive Cutoff.