Workflow for Renewal of an OCSP signer

Using VA Publisher

ENTERPRISE EDITION This is an EJBCA Enterprise Edition (EE) feature.

Before renewing the OCSP signer, verify that a publisher (a Peer Publisher) is selected for the Certificate Profile used to issue the new OCPS signer certificate.

  1. Optionally, go to AdminGUI of OCSP > Internal Key Bindings and create New keys for your OcspKeyBinding.

  2. Go to AdminGUI of OCSP > Internal Key Bindings and create a Certificate Signing Request for your OcspKeyBinding. Save this file.

  3. Go to AdminGUI of CA > RA Functions > Search End Entities. Enter username of user previously used to generate OCSP Certificate, Edit this End Entity and set status to New and a new enrollment code.

  4. Go to PublicWeb of CA > Create Certificate from CSR > Use the credentials for issuing an OCSP signing certificate and upload the CSR.

  5. ...(CA publishes new OCSP signing certificate to OCSP instance)...

  6. Go to AdminGUI of OCSP > Internal Key Bindings and click Update for your new OcspKeyBinding. This will find the published certificate by matching the key pair with the certificate.

  7. Go to AdminGUI of OCSP > Internal Key Bindings and click Enable for your new OcspKeyBinding to start processing OCSP responses with it.

Using EJBCA Peer System

ENTERPRISE EDITION This is an EJBCA Enterprise Edition (EE) feature.

Go to AdminGUI of OCSP > Peer Systems > Click Manage for the peer connector representing the CA > Remote Key Bindings > Click Renew for your OcspKeyBinding.

Using the CLI

You can also use the local CLI to do the operations described above. The CLI contains on-line help when you run commands without parameters.

bin/ cryptotoken
bin/ keybind

Automated renewal of an OCSP signer via CA's WebService (a.k.a. Re-keying)

Re-keying as described below will change in a future version of EJBCA. The CA will keep track of the OCSP responders certificates and order key renewal and update the responder's certificates to avoid incoming traffic to the CA. For now, this is the way to do it.

Re-keying allows the OCSP responder to generate new signing keys and obtain a new certificate for these keys from the CA's WebService. Re-keying is configured in the configuration file. The client authentication SSL certificate is configured as an AuthenticationKeyBinding in the Admin GUI (or using the EJB CLI).

Re-keying can be either automatic or manual. Automatic re-keying allows you to specify the maximum expiration period in seconds before the re-keying should happen (i.e. you can set-up the OCSP responder to renew its keys and certificates when its current certificate is about to expire). Manual re-keying allows you to trigger the renewal by sending a GET request to the OCSP responder (with the necessary parameters). Manual re-keying is useful when a greater control on re-keying periods is desired. Since manual re-keying can be done with external tools (like wget or curl), cron jobs can be set-up to trigger it at the desired time.

Both automatic and manual re-keying require that EJBCA CA web-service URL is defined. The web-service URL should point to the EJBCA CA server which has issued the certificates for the OCSP responder. If the URL is not defined, the re-keying won't be enabled.

OCSP responder acts as a registration authority when renewing keys with the EJBCA CA. The OCSP responder uses an AuthenticationKeyBinding for SSL client authentication to the CA's web-service.

Since OCSP responder is acting as a registration authority, its certificate for authenticating (in the AuthenticationKeyBinding) to the EJBCA CA web-service must have the key usage set to Digital Signature and keyEncipherment and extended key usage set to Client Authentication. It is also necessary to set-up the appropriate access rules on the CA side (either by creating a new RA role, or using an existing one). The role for the OCSP responder should have the right to view and edit the end entities (at least for all of the CA's issuing the certificates for the OCSP responder, as well as for certificate profiles used by the OCSP responder's certificates).

For manual re-keying the GET request should contain the parameters renewSigner and password. The renewSigner parameter can be used to specify which OCSP keys should be renewed. It can be either set to all, which will renew all of the OCSP signer keys, or to a specific OCSP responder certificate subject DN. The parameter specified here should be the OCSP's subject DN, not the issuer's. Password should be configured in the file. If the password is not set, manual re-keying will not be enabled.

Manual re-keying can further be limited by specifying the allowed originating IP addresses for the requests. By default the re-keying is allowed only from the localhost ( address. Allowed IP addresses are configured in the configuration file, and multiple addresses can be provided by separating them with a semicolon (;).

The following two examples demonstrate the manual triggering of re-keying on the OCSP responder. The first example triggers the re-keying for all of the OCSP signer keys, while the second one will trigger rekeying for a specific signer (the one matching the subject DN of "CN=OCSP REsponder 123,O=PrimeKey Solutions AB,C=SE"):

If a specific OCSP subject DN is provided, the OCSP responder will look among its keystores/HSM slots for matching certificate and its associated keys. If the specified subject DN is not found, an ERROR message will be output to the server log files specifying the searched subject DN and the available subject DN's. If you're having problems with manual re-keying when providing a specific subject DN, make sure to check the logs and verify that the proper subject DN was specified for the renewSigner parameter. Ordering of subject components matters. You can also copy/paste the subject DN from the log to make sure the spelling and ordering is right (i.e. that it matches with what can be found on-disk or in HSM).

For re-keying to work, the OCSP signer certificates need to be issued to separate end entities on the EJBCA CA (i.e. you cannot re-use the same end entity for multiple OCSP signer certificates for different CA's).

Be aware that the re-keying operation has not been tested on all of the application servers. Some of the application servers may have problematic client web-service implementations.