Introducing the EJBCA RA, Part 1: Introduction

Where we are now

One the primary complaints we here at PrimeKey get about EJBCA is about the design of our interface, or rather the lack of thereof. We've come a long way from being a tiny open source project to being one of the primary PKI software vendors globally, so while we maintain our dedication to delivering a powerful and secure product, it's time for us to give our users a bit of a break.

The Public Web 

A major feature EJBCA has always been lacking is a dedicated RA. The Public Web, while basically functional, is merely a rudimental interface for performing RA functions, one which only works locally, needs to be used in conjunction with the CA web, and is not in a state that can be considered deployable to the end user.

Many of you reading this have in all likelihood designed your own personal RA using CMP, SCEP or our WebService interface, which brings us to our next topic. Most CA installations are understandably hesitant to expose their CAs to the wild in order to interact with an RA, but instead protect it using a firewall. Currently we provide the standalone ExternalRA, an asynchronous proxy meant to reside outside the firewall, restricted to only being polled by the RA.

What is in store

Those of you familiar with EJBCA Enterprise will hopefully be a bit familiar with the EJBCA's RA Web. We released it back in EJBCA 6.6.0, and with the refinements being done in EJBCA 6.8.0 and beyond.

The EJBCA RA in EJBCA 6.7.0

The RA is the herald of the end of the Public Web and of ExternalRA. By the end of this year we will be discontinuing these two modules and removing them. So what does this mean to you? Well, quite a bit, and all of it good. The RA is in fact designed to completely supersede the Public Web, while providing quite a bit more functionality and improved design, aside from being a whole lot prettier.

Not only that, but by using the Peers protocol introduced in EJBCA 6.3.0, one instance of EJBCA can be set up in the DMZ as a proxy to another acting as CA within the confines of the firewall, responding to synchronous polling from the CA and communicating over TLS instead through database polling.

That's it for now, but follow us for an additional couple of blog posts. Part 2 will take a close look at the EJBCA RA and how to transition to it from using the Public Web, while Part 3 will talk about setting up an RA Proxy, as well as discuss some future ideas for the RA.

Cheers!

Mike Agrenius Kushner,

Product Owner EJBCA