EST for Certificate Enrollment

There are multiple protocols available to enroll for certificates from a CA. Some are standardized and some are proprietary.
The most popular standardized ones are SCEP, CMP and EST. SCEP has been around since 2000 and show severa ageing issues, most notably the lack of ability to work with EC keys in a usable matter.
CMP has been around since 2005, is multi functional and handles both RSA and EC keys well. It's a true Swiss knife of PKI enrollment protocols. Being so functional is also it largest criticism, being advanced also becomes complex. CMP works well for a large number of uses cases and we have discussed some of them here and here.
The new kid on the block is EST, which in 2013. EST re-uses other standards such as TLS to try to make it easier to use while at the same time providing much functionality. EJBCA Enterprise has implemented EST since EJBCA 6.11 and it can be used for efficient certificate enrollment from a management system (mobile device management, token management system, IoT platform, etc), using both RSA and EC keys. The management system acts as a Registration Authority (RA) in PKI terminology and this is the notation we'll use throughout.

A typical use case for certificate enrollment is to have an RA that handles initial enrollment for users, mobiles or devices. After initial enrollment (provisioning) the device can automatically re-enroll for updated certificates as long as it still have a valid certificate.

We'll walk through this use case, using EJBCA as the CA server supporting EST, and the open source Cisco EST Client. In order to use EST an EST Alias must be configured in EJBCA, as described in the EST documentation.

Adding an EST Alias

Configuring an EST alias is easily done in the EJBCA Admin UI in the EST Configuration section.

Using EST Client

Before doing any enrollment the RA can fetch the latest CA certificate from EJBCA.

estclient -g -s 127.0.0.1 -p 8442 -o certs --pem-output

After a device has been approved by the RA, the RA can get a certificate for the device from the CA.

estclient -e -s 127.0.0.1 -p 8442 -o certs -u estadmin -h foo123 --pem-output --common-name myclient

In this case the RA i authenticates to the CA using a username (estadmin) and a password (foo123). The RA can also use client certificate authentication instead of username/password.
The issued client certificate will contain the distinguished name (subjectDN) "CN=myclient". This command will automatically generate an RA key for the client.

The device can automatically re-enroll for a new certificate, authenticating itself using the private key and certificate it received from the RA.

estclient -r -s 127.0.0.1 -p 8443 -o certs -c certs/cert-0-0.pem -k certs/key-x-x.pem --pem-output

If an EC key is desired instead of RSA, this key must first be generated before enrolling for the certificate.

openssl ecparam -name prime256v1 -genkey -noout -out prime256v1-key.pem
estclient -e -s 127.0.0.1 -p 8442 -o certs -u estadmin -h foo123 --pem-output --common-name myclient -x prime256v1-key.pem

The corresponding re-enrollment command is.

estclient -r -s 127.0.0.1 -p 8443 -o certs -c certs/cert-0-0.pem -k prime256v1-key.pem --pem-output -x prime256v1-key.pem

This command re-enrolls using the same key as used in the initial certificate, but a new key can equally well be generated, which is in general the prefferred option.

Re-using keys for subsequent re-enrollment can be prohibited in EJBCA by a configuration in the EST Alias.

Roadmap: Rethinking our UI

A common point of pain for anybody who has ever tried to interface with EJBCA is the UI.  It stinks like something died, got eaten by something else which then in turn also died but did so after eating a pair of old sneakers and then not being found for two weeks. We know. 

It's a problem which we've been trying to fix for something like the last decade, but in my entire career legacy UIs seem to be the most common technical debt issue that software companies have. I've seen it happen before, and PrimeKey has also tried rewriting our UI from scratch at least once; it always fails for many of the common reasons. Joel Spolsky wrote an article nearly 20 years ago (which I first read something like 10 years ago) describing why redoing your UI from scratch is a bad idea, and what he says mostly rings true.

The Problem(s)

Why change something that works? Well, when designing an interface the concept of quality comes to mind. EJBCA obviously does most of what is required of it - its extensive use out in the wild wouldn't be possible otherwise. The support questions and the frustrations of both our customers and our own staff witness to the fact that much remains to be done though. Looking fairly objectively at the CA UI (still titled the Admin UI), it reflects several issues:

It Was Designed a Long Time Ago

EJBCA has been alive and kicking since 2001, which of course means eons in internet time. Not that frames were a modern concept even then (and hey, we kicked ours last year!), but it's from a day that preceded widespread adoption of proper MVC design, and the existence of fancy javascript libraries. As a consequence...

It Doesn't follow Consistent MVC Design 

Through the years we've put a lot of effort into moving functionality to where it belongs  - moving down logic into the business beans and caching into the session beans from the UI layer (in some cases even inlined in the UI code) while moving up formatting instructions into the MBeans of the view layer - much still remains though. An added difficulty is the fact that...

Large Parts are Still in Ancient JSP

I know, JSF is hardly bleeding edge technology, but that's what we're aiming for at this point. The fact that we have a UI written in two different coding schemes with three different styles make all and any usability changes hell to try to implement. Trying to rewrite the UI to something more modern is difficult because...

It Does a Lot

From Hyperbole and a Half

This is where previous efforts have always failed, as such efforts have in so many software projects. We've made attempts in the past (though only one properly in earnest) of rewriting the UI, and they've simply failed due to the lead times being so great that there has never been a way of updating the spec at the same rate as development, and this is just what we're adding as the tiny development team we are. The huge amount of functionality in EJBCA is one of its greatest strengths, but it adds a huge amount of inertia to any major changes - not only can't we lose features, our huge feature set also adds a risk of causing regressions; these may be anything from annoying to fatal for our users. The other problem about our huge feature set is that a lot of it is quite obscure because...

Our UI is Designed By Developers

Our UI really does cover everything - the problem is that we're a bunch of developers who have designed it. If you want to have a deep understanding for how EJBCA's data model looks like the UI is really a great guide, because it mirrors it exactly. Honestly, do you as a user care what an Internal Key Binding is? Why does setting up a Peer require background knowledge of TLS to be comprehensible? Why are both of these required when setting up a remote VA Responder, and why is that option nowhere in the menu? 

We have a long way to go in usability. 

Where We Want to Go

Does that mean that we've given up? Nope, not in the least. Divide and conquer is a heuristic that never goes out of style, and the RA Web we introduced back in 2016 takes care of some of those concerns. In addition to all the other advantages provided by having a separate RA, it also allowed us to move some functionality from the CA Web into the RA Web. As stated in the last roadmap update, most functionality which is today duplicated between the two interfaces will soon be officially deprecated, then unlinked, then finally deleted. 

Technology Update 

Our goal is to move the entirety of the CA Web to JSF in XHTML. While well aware of the fact that there are tons of neat noun.js javascript libraries out there, due to the business we're in we want as much as possible to avoid dependencies linked to specific corporations, and shy very much away from non-FOSS libraries. JSF does what we need, and there is little risk of it being abandoned. Once there we're at a far better place - changes no longer need to be made in two languages, we can have far more code in common, we're working in an environment which is far less painful. 

This is the first part of our UI project, is currently ongoing, and is slated to be complete by the beginning of Q4 of this year (in parallel with other development). We will be avoiding usability changes as much as possible in order to make keep the usability delta minimal, thus making life easier for our QA staff. 

Layout Update

The next step will be moving the entire layout of the UI to the CSS files, much like the RA Web. 

This not only allows us to be entirely flexible with the layout (you do know you can customize the RA Web as much as you like, right?) but also work with several designs at once, being able to provide both a "legacy" layout and to work on something brand new. 

Customizable stylesheets for the RA web. 

Usability Normalization

EJBCA currently badly lacks consistency - similar functions have been developed by different developers at different periods in different technologies. There are very few unified ways of perform an action, and the learning curve for using our UI is very low as a result. Having normalized technology and layout, our next avenue is to give our design a single voice, a feel. 

Workflow Based Design

Ah, the holy grail - we're I've dreamt about ending up for years. 

Gone will be all connections between data models and frontend, remaining will be an interface based on what you as users actually wish to accomplish within PKI. We have some exciting times ahead.

Cheers,

Mike Agrenius Kushner

Product Owner, EJBCA

EJBCA 6.13.0 - Our VA is GDPR Ready!

What now, another feature release so soon? Fear not, all is well  - instead we felt that some of the work we've put in to the trunk should be made available as soon as possible. We hope that as many of you as possible have had a chance to check out the ConfigDump tool we released with EJBCA 6.12, please give us any available feedback that we can plug in to future versions.

Adapting the VA to GDPR

We've added an option to the VA Peer Publisher to restrict publishing identifying certificate metadata from the CA to VA, such as subject DN, SAN or usernames. 

 Key Ceremony Utilities added to the RA Web

During key ceremonies, auditors typically require a copy of all CA Certificate fingerprints. To spare you the process of downloading CA certificates and computing the fingerprints manually using a third-party tool, we've added the following functionality to the RA Web:

• Download Fingerprints: Downloads a YAML text document with the CA Certificate fingerprints of all CAs you have access to.
• Download Certificate Bundle: Downloads a compressed zip file containing the CA certificates of all CAs you have access to.

For more information, see RA Web CA Certificates and CRLs.

Roadmap Update

As always we tend to be very restrictive with discussing our roadmap, but one very long awaited project we're very pleased to finally have time to redo the CA UI, a point of contention which I'm sure all of you are painfully aware of. As refactoring interfaces is always a minefield we'll be taking it in minor steps, beginning with the conversion of the antiquated JSP pages into more modern-ish JSF before beginning to make more concrete improvements in usability. Expect to see some pages in the UI slightly change appearance in the autumn, and keep tuned to this blog for more updates on this subject. 

Cheers!

Mike Agrenius Kushner

Product Owner EJBCA