Build a high performance OCSP responder using EJBCA. EJBCA is a J2EE enterprise open source PKI that you can deploy as a certificate authority or an 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 post 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
- performance
- 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.
Visit EJBCA.org for downloads and documentation.
Sunday, June 7, 2009
Subscribe to:
Post Comments (Atom)
Posts
6 comments:
Just a minor correction. The post says:
> This profile builds on the usage of http get instead of http put which is the default transport used.
But it should say "post" instead of "put" (see RFC 2560, "A.1.1 Request").
Thanks, I updated the post (impressive that you read these old posts :-))
I was reading this because it clearly exposes the rationale to get HA for the OCSP service as several different independent nodes, instead of, for example, using an HA database (as it could be done for CA nodes) and actually, I think that the following documentation should be somehow in https://doc.primekey.com/ejbca/ejbca-introduction/external-ocsp-responders:
> 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.
Thanks for the suggestions. I added a slightly modified version to the next release of the documentation.
---
OCSP High Availability (HA)
A typical configuration when using External OCSP responders uses two or more OCSP responder nodes. To assure that failure of one node does not affect other nodes, each OCSP responder node can maintains 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 OCSP service as a whole. Similarly each OCSP responder node can use it's own HSM.
OCSP responder nodes can also use a common HA database and a HA cluster of HSM, if that suits your organization better.
Each OCSP responder node can produce transaction and audit logging as documented elsewhere.
I'm new to EJBCA, can you tell me what service i have to use for RA like OCSP
You can find all documentation and installation instructions at https://www.ejbca.org/, it has everything you need. If you need professional services and support, that can also be provided. Please check the website for information.
Regards,
Tomas
Post a Comment