Selection of OCSP Signing Certificate from a Request

In the OCSP request as defined in RFC 6960, the hash of both issuing CA's Subject DN and public key is available:

EJBCA selects OcspKeyBinding based on the subject DN and public key of the CA certificate that issued an OCSP signing certificate. The issuing CA certificate is determined from the OCSP certificate chain and the construction of the chain is described below.

CA Key Renewal Considerations

EJBCA considers two X.509 CA certificates as the same CA if they share the same Subject DN and as different versions of the same CA if the public key is different. Since both subject and key pair is used in the request, you will need two OcspKeyBindings (one issued before key renewal and one after) to be able to serve OCSP requests where clients use CA certificate for both the old and new key pair in their requests.

OCSP Service Logs

The OCSP service logs using Log4j to the JBoss server.log. The JBoss server log is located in JBOSS_HOME/server/default/log/server.log and the logging is configured in JBOSS_HOME/server/default/conf/jboss-log4j.xml.

The OCSP Transaction Log

The OCSP transaction log can be used to log various information about ocsp-requests. Transaction logging logs summary lines for all OCSP request/responses, which can be used for charging clients if you are running a commercial OCSP service.

To turn on transaction logs logs, copy ocsp.properties.sample to ocsp.properties and change:

to

then uncomment the other lines below that starts with ocsp.trx-log. Change the ocsp.trx-log-log-date line if you want to change how the time recorded in logging should be output. The value should be on the same format as for javas DateFormat, information on valid configurations can be found here.

ocsp.trx-log-pattern is a pattern for use with ocsp.audit-order to replace constants with values during logging. For most purposes you will not need to change this string.

Use ocsp.trx-log-order to specify what information should be logged and in what order. You can also configure what characters you want in between. If you want your log to display all of the values available you only have to un-comment it.

Available values for the transaction log are:

The OCSP Audit Log

The OCSP audit log logs entire requests and responses. This can be useful when requests and responses are signed because the information can be used to verify requests and responses afterwards. Audit logging is configured in the same way as transaction logging. Valid values for audit logging are:

Note that LOG_ID are of the same value in both trx log and audit log for any request. This means they can be cross referenced. You can retrieve information from the transaction log and verify that the information is valid by using the audit Log.

Configuring Output Files for OCSP Logging

For JBoss you can configure logging in JBOSS_HOME/standalone/configuration/standalone.xml to put the transaction and audit logs in separate files:

Safer Log4j Logging

The default behavior when logging fails, such as when the destination disk is full or disconnected, is to continue responding as normal. If you prefer the responder not to send OCSP-responses when logging fails you can use the following configuration:

1. From your EJBCA folder, run:
   ant jbosslog4jsafer

2. On JBoss 7 / EAP 6 build and deploy a new ejbca.ear that includes jbosslog4jsafer.jar with:

   ant ejbca.ear

   ant deployear

3. Set 'ocsp.log-safer = true' in ocsp.properties (and enable ocsp.trx-log and ocsp.audit-log of course).

4. Modify your JBoss logging to use the SaferDailyRollingFileAppender and ProbableErrorHandler. For example:

   <appender name="OCSPTRANSACTION" class="org.cesecore.util.log.SaferDailyRollingFileAppender">

   <errorHandler class="org.cesecore.util.log.ProbableErrorHandler" />

   <param name="File" value="${jboss.server.log.dir}/transactions.log" />

   <param name="Append" value="true" />

   <!-- Rollover at midnight each day -->

   <param name="DatePattern" value="'.'yyyy-MM-dd" />

   <layout class="org.apache.log4j.PatternLayout">

   <!-- The default pattern: Date Priority [Category] Message\n -->

   <param name="ConversionPattern" value="%d %-5p [%c] %m%n" />

   </layout>

   </appender>

   <appender name="OCSPAUDIT" class="org.cesecore.util.log.SaferDailyRollingFileAppender">

   <errorHandler class="org.cesecore.util.log.ProbableErrorHandler" />

   <param name="File" value="${jboss.server.log.dir}/audit.log" />

   <param name="Append" value="true" />

    

   <!-- Rollover at midnight each day -->

   <param name="DatePattern" value="'.'yyyy-MM-dd" />

   <layout class="org.apache.log4j.PatternLayout">

   <!-- The default pattern: Date Priority [Category] Message\n -->

   <param name="ConversionPattern" value="%d %-5p [%c] %m%n" />

   </layout>

   </appender>

   <logger name="org.cesecore.certificates.ocsp.logging.TransactionLogger">

   <level value="DEBUG" />

   <appender-ref ref="OCSPTRANSACTION" />

   </logger>

   <logger name="org.cesecore.certificates.ocsp.logging.AuditLogger">

   <level value="DEBUG" />

   <appender-ref ref="OCSPAUDIT" />

   </logger>

   If you use category instead of logger Log4j will output warnings on startup.

5. Start JBoss and you are ready.

Responses with longer validity and caching

RFC 6960 (and RFC2560) defines thisUpdate, nextUpdate and producedAt. producedAt is always included in the response and is the time the response was created. thisUpdate and nextUpdate is enabled by configuring 'ocsp.untilNextUpdate' in ocsp.properties or in the OcspKeyBinding. thisUpdate will be the time a singleResponse is embedded in the main response and nextUpdate will be 'untilNextUpdate' seconds later than thisUpdate. This enables clients that supports this feature to re-use a valid response and decrease to load on the OCSP-responder.

RFC 5019 defines how to use HTTP cache headers as defined in RFC 2616 for OCSP HTTP GET requests. By using the headers Last-Modified, Expires, max-age and Date, less intelligent nextwork component like HTTP caches can cache respones. This enables re-use of responses to decrease the load on the OCSP-responder and can shorten reponse times by deploying caches closer to the actual OCSP consumers. HTTP cache headers is enabled by configuring configuring 'ocsp.maxAge' in ocsp.properties or in the OcspKeyBinding.

When using RFC 5019 style HTTP headers, JBoss users should be aware that the Date header is overwritten with a cached value. Since generating the Date-string is computationally heavy for regular small GET requests, it is generated about once per second. So a response will have a Last-Modified that is one second in the future from Date from time to time.

A regular Apache HTTP server can be used for caching requests, load-balancing and dropping some unwanted requests:

Adobe Reader

A good example of using OCSP is to check digitally signed PDF documents using Adobe Reader.

To verify certificates in Adobe Reader, you must first add the CA certificate as trusted in Adobe Reader. You can do that in the menu Document > Trusted Identities. Choose Certificates in the list menu and click Add contacts to browse to the CA-certificate that you have downloaded in DER format (for example by choosing download to IE on the public EJBCA pages). The CA certificate must have been saved with a name ending with .cer. After adding the new contact, click Edit trust and check at least Signatures and as trusted root and Certified documents. Applies for both internal and external OCSP responders.

Certificates that have an OCSP service locator will be verified against the OCSP responder. You can configure this in the certificate profile used to issue certificates.

If you sign PDF documents with embedded OCSP responses, these responses must include a nextUpdate field, and the timestamp must be within the thisUpdate and nextUpdate period of the OCSP response.