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.