3.9.0 has been released, suitable for building a high performance OCSP responder
EJBCA is a J2EE enterprise open source PKI that you can deploy as a certificate authority or an ocsp responder.
With the release fo EJBCA 3.9.0 it is easier than ever to set up a high performance, high reliability OCSP responder.
OCSP stands for online certificate status protocol and is defined in RFC2560. In short it provides an online service for validating that a certicate, as used by SSL or VPN etc, has not been revoked. OCSP has the basic functionality defined in RFC2560 and this, in it's plain form, it widely used. If using a high speed hardware security module (HSM) for signature operations you can easily answer 500 requests per second with the EJBCA external OCSP responder. Certificate status information is kept in a regular database, such as MySQL, making it very suitable for online services because you can really update the information on line without waiting for the certificate authority to issued certificate revocation lists (CRLs).
To further improve scalability of OCSP IETF has defined a lighweight OCSP profile in RFC5019. This profile builds on the usage of http get instead of http put which is the default transport used. Using http get the responder can set http headers to enable caching by regular proxies. Caching makes the service slightly less online, in the meaning that you always gets fresh information, but can improve performance across networks. EJBCA 3.9.0 improves the EJBCA external OCSP responder with full support for RFC5019.
If you plan on building an OCSP service there are many things to consider:
- standards support
- scalability by adding cluster nodes
- transaction and audit logging
- authentication of callers, possibly requiring signed requests
- use of custom OCSP extensions
- OCSP responder independent of CA service provider
- renewal of OCSP responder keys
A typical configuration for OCSP uses two or more OCSP responder nodes. Each OCSP responder keeps it's own database. By using it's own database you can assure truly high availability because the nodes are completely independent and you can do maintenance on one node, including the database, without affecting uptime of the service. The OCSP responder nodes should be connected to a set of HSMs in a high availability setup, if one HSM breaks, another keeps the service running albeit with less available performance.
Each OCSP responder will produce full transaction and audit logging. Audit logging is needed in order to maintain trust, since a validation service such as OCSP is about trust. Transaction logging will be needed if you want to keep records of users of the service either for billing purposes or to keep statistics.
for downloads and documentation.