Introducing the EJBCA RA, Part 3: Architecture of an RA Proxy

This blog post will describe features in EJBCA Enterprise which will not be released to the Community Edition. If you're interested in what you read about here and would like to learn more, please mail sales@primekey.com 

Hello there and welcome back to the next feature of our RA series, which is going to discuss a bit about the RA, what led to it and who needs it. I know it's very much belayed, but we've had our hands full with our regular releases =)

The What? 

So for those of you reading who are either running EJBCA in small scale or internally, the new EJBCA RA interface is just a fancy new frontend for EJBCA. We know that many of you are running your own RA services through our SOAP interface, others via CMP or SCEP. 

For those of you running EJBCA Community, that is where it will end once we release the RA into a community release. Those of you running EJBCA Enterprise, or who might have plans on doing so, this is where you perk your ears.

The interface is actually just the tip of the iceberg, because what hides behind it is actually a fully armed and operational battle station RA Proxy.

The Why? 

Many of you already running large scale CA installations will be more than aware of this issue, but I'll say it plainly: exposing your CA server to the internet is a bad thing. You're suddenly vulnerable to every security vulnerability, zero-day and attack vector known to mankind, and a CA is a more than inviting target. 

Yet, most CAs (barring root CAs) need some form of exposure, if not to just publish CRLs and answer OCSP requests. For this reason CAs will be placed behind a firewall allowing only outbound communication, through which CRLs can be published to servers outside the firewall and to VAs placed in the DMZ.

When using EJBCA as a VA, those of you who have been in the game long enough know that we used to support a VA publisher (now considered legacy) that published directly to the VA database (using an extra port opened in the firewall), which has since then been replaced with EJBCA Peers (an Enterprise feature) which allow the CA to communicate to the VA running TLS, with the protocol only making use of outbound communication (with replies) in order to fulfill to security requirements. 

Legacy Features 

RA functionality is on the other hand more difficult, since the communication is by its very nature inbound. Up until EJBCA 6.6.0, PrimeKey offered some solutions for an RA wishing to communicate with a CA sitting behind a one-way firewall: 

• The ExternalRA - known to some of our enterprise customers, the old EJBCA ExternalRA (also known as ExtRA) is an asynchronous proxy designed to run in the DMZ. The ExternalRA doesn't provide more than a very rudimentary RA interface, but instead intercepts SOAP messages and stores them in a message database. By opening an outbound database port in the firewall (much as was done for the legacy VA), the CA can poll the ExternalRA's database and thus handle registration requests. 
• The SCEP and CMP Proxies - while similar to the ExternalRA solution (and sharing some of its codebase) the SCEP and CMP proxies fill a similar role, intercepting inbound communications and storing the payload in the database for future polling. 

The legacy stack, using legacy PrimeKey icons. 

All in all, these solutions are not entirely without warrant. While slow due to their asynchronous nature and extremely limited in terms of communications feature sets, they do not only provide RAs with a means to communicate with a secure CA but also mitigate some DOS attacks by vetting inbound communications before the CA needs to handle them. 

The How?

As I mentioned before, back in EJBCA 6.3.0 we introduced the EJBCA Peers protocol, in essence a method for two EJBCA instances to be able to communicate with each other over TLS, but in practice a secure alternative to direct database publishing for VAs (see this old blogpost). EJBCA finally saw the long awaited expansion of the Peers protocol to also encompass RA communications, and in doing so introduced new demands. 

Our Initial Implementation

While designing the protocol to communicate between CA and VA, one constraint that we introduced was generality: there should in essence be no difference between a CA installation of EJBCA compared to a VA installation. We want our customers to be able to follow a standard installation procedure up until the point where it's time to designate the purpose of the actual instance, and this counts doubly when using a PrimeKey appliance. Between a CA and VA this is relatively simple: an instance is always a CA, and can also act as a VA for an externally imported CA. Communication is always initiated by the CA. 

Introducing RAs into the Mix 

Adding RAs implies another few layers of complexity. Communication goes inherently upstream, breaking the outbound-traffic-only constraint on the CA security environment. Thinking ahead, we realized that proxies can exist in several layers (communications being routed through several instances of EJBCA before reaching their final installation), with any installation acting as CA and RA proxy simultaneously. As developers we direly want to avoid reinventing our own wheel, so we direly want to avoid maintaining one interface for designated RAs and another for RA tasks on the CA. 

We solved this in EJBCA 6.6.0 by adding another layer of abstraction on top of RA calls, the RaMasterApi. The API checks the source of the message, availability of peers upstream to itself and the message type and from that decides on whether to process the message locally or pass it on. 

The beauty if this design is that it's essentially stateless. A new EJBCA instance born to this world can simply be set up to accept incoming peer messages, and that's basically all the configuration required to make it into an RA. Adding an outgoing peer to this instance and configuring it for RA communications would in no way detract from its capacity to act as RA, but it would also relay messages from downstream up to the CA.

Even for the RA, all communications are still initiated by the CA, specifically by the CA leaving long hanging message thread in a pool for the RA to use as needed.

Lastly, the CA is also protected by a rights system, in which any credentials used to identify on the RA are nestled within the credentials set on the CA for the RA itself. In other words, if an RA has been limited to a certain subset of RA operations, and a certain subset of CAs, even logging in with a superadmin certificate on the RA won't allow any more privileges than those allowed to the RA. It means that there are essentially watertight compartments between different RA instances, allowing the CA to serve several different entities with RA services without risk of leaking information between them.

So, in our next and final instalment I'll be showing a quick tutorial on how to set up an RA to speak to a VA and demonstrate some of the concepts I've spoken about in this post. Until then!

Cheers!
Mike Agrenius Kushner
Product Owner EJBCA