What's new in EJBCA 6. Part 2: CMP aliases and GUI configuration

Welcome to the second part of the series about what is new in the upcoming EJBCA 6.
For the first part in the series, read Part 1: Crypto Tokens in GUI.

In part 2 we will take a look at new major features in the EJBCA support for the CMP protocol, RFC4210.
EJBCA has supported RFC4210 all the way since EJBCA 3.4 in 2005.
(for the history inclined, see ECA-99).

CMP is a very complex protocol with literally hundreds of different options. And those are just the options that are specified in the RFC, then there is also the question how to process them in the back-end with different types of authorization, auto enrollment, support for both end clients and RAs etc etc. The support in EJBCA for different types of clients and different CMP options have grown step by step over the years and we even implement the somewhat cryptic NestedMessageContent as "Multiprotection support".

Currently there is a single URL to access the CMP server, and a single configuration, cmp.properties, for CMP. This means that when you configure CMP in EJBCA for a specific client (or RA), this is the client that will be interoperable.
If you want to run two different clients against the server, with two different configurations, this is not possible since there is only one URL and one configuration. You can of course deploy two separate servers in a cluster, each server running different configurations, but this is not very nice and feels more like a hack.

Introducing CMP aliases. With the arrival of EJBCA 6 you will be able to configure as many CMP URLs (CMP aliases) as you want, each one with a different configuration. There is a set of default (secure by default) options that each new alias configuration inherits and that you can override for each individual URL.

As an example, I set up this test environment for testing with cmpforopenssl.

• Client mode with HMAC password authentication on server-address:8080/ejbca/publicweb/cmp
• Client mode with client certificate authentication on server-address:8080/ejbca/publicweb/cmp/alias1
• RA mode with fixed HMAC RA password 'password' on server-address:8080/ejbca/publicweb/cmp/alias2

Needless to say, alias1 and alias2 are just strings and you can use anything you like.

At first shot this was configured in a new configuration file, cmpaliasconf.properties.
cmp.alias1.operationmode=client
cmp.alias2.operationmode=ra
etc.

But heck, some people here were not satisfied with that, so lets configure everything in the Admin GUI instead.
You heard it, in EJBCA 6 you will configure CMP in the Admin GUI, and you can select and add new aliases simply by clicking some buttons.
Of course there will also be a command line interface (CLI) so you can script it or simply use the CLI if your administrator certificate has expired (but you don't let that happen do you?).

The new CMP configuration is stored in the database so there is a single configuration across your cluster, configure on one node, see the effects on all.
There will also be a possibility to read in an old configuration file in the CLI, so upgrades from the old style file configuration is easy.

All currently available CMP features, such as the CMP proxy is of course available just as before.

Needles to say, we think this new feature is awesome. Since I don't know much about other products I can't say it is unique, but it's a leap forward in usability for us.
With CMP being used more and more now (after all these years as an RFC) and replacing the simple SCEP protocol, this will ensure that EJBCA can work with many different CMP clients out there, all at the same time.

Part 3 of "What's new in EJBCA 6" will be about a completely new feature called Internal Key Bindings and OCSP Key Bindings. Anyone longing for an Admin GUI for EJBCA standalone OCSP responder?

Until then...check in with PrimeKey, or follow us on Twitter, for the latest news and events.