Enlightened Enrollment: The Book of Five Certificate Enrollment Protocols

In this blog post, Mike Agrenius Kushner in his role of Product Architect is going to present a layman’s guide to PKI enrollment over API and five of the protocols supported today by EJBCA. 

Remember, if you were there, your first day of university. The first act was going up to a desk and pointing to your name on a ledger, after which you were handed a flimsy piece of paper with a username (based on a likely embarrassing contraction of the letters of your name) and an auto-generated password (that you were allowed to change sometime after passing the course in Differential Transforms in year three). This whole process was called enrollment.

This is very much like the first stage of a certificate’s lifecycle, when the bearer of a key presents itself and its credentials to a Certificate Authority, which then bestows that entity with a certificate allowing it to go forth and be excellent. We’ve all performed enrollment using certificate signing requests (CSRs) and manual submissions of them to various tools and applications through command lines, scripts or maybe even a user interface. The true magic happens when you’re able to  let your device enroll completely on its own. If you were really lucky, you never even knew it happened.

In this blog post we’re going to look at five of the enrollment protocols supported by EJBCA: ACME, SCEP, CMP, EST and our own REST API suite. We’re going to look at the history of each protocol, the pros and cons and where you would be likely to apply them. For this blog, we’ll treat Microsoft Auto-enrollment as a completely different use case.

The Certificate Management Protocol (CMP) is the oldest of the protocols supported by EJBCA, first drafted in the bygone days of 1996, reaching RFC status with RFC 2510 in 1999 and reaching its current state with CMPv2 with RFC 4210 in 2005.

As a protocol, CMP certainly shows its age, both in terms of design and in terms of unwarranted complexity, partly owing to the nascent state of PKI back when it was designed. The complexity (and in some cases ambiguity) of the RFC means that various server and client implementations can and do deviate when it comes to the fine details.

The main strength of CMP is thus also its main weakness – that it is one of the most encompassing protocols in terms of available operations and various permutations. This also results in clients with fair claims to support all of RFC 4210 few and far between.

This age and resilience also means that CMP as a protocol doesn’t rely on many technology stacks. Itcan be sent over HTTP, TCP or carrier pigeon for that matter.

One of the main aspects that’s keeping CMP relevant today is the 3GPP LTE framework originally developed for and by the Telecom industry, which adds vendor certificate support to CMP. This allows a manufacturer to provision a device with a signed certificate from its own CA. This certificate can then be proffered by an end device user to enroll to their PKI.CMP is also relevant in other industries. One more example is rail networks, where CMP is defined as the standard protocol for ERTMS systems.

If you’d like a head start with playing around with EJBCA and CMP, I can recommend this section from the PKI at the Edge video for the Keyfactor Community.

+ If you need a protocol with a full suite of operations

+ You’re a telecom manufacturer or somebody else in an industry that relies on 3GPP

– You’re not ready to maintain a complex client which may need to take different takes on the RFC from different CA vendors into account.

Nearly as old as CMP, the Simple Certificate Enrollment Protocol saw its first draft back in 2000. In contrast to CMP, SCEP was designed to be as lightweight and simple as possible, based on a proprietary protocol originally developed for Cisco, who also submitted the first draft for SCEP.

Compared to CMP, SCEP’s set of operations is far more limited, culling a few commands for enrolling and for retrieving certificates and CRLs, with later versions of the draft seeing some slightly oblique ability to perform renewal as well. SCEP was stuck in draft hell between the publishing of version 23 of the original draft in 2011 to the final publishing of RFC 8894 in 2020, meaning that draft version 23 is still the de facto version supported by most CA software, including EJBCA.

Due to its legacy and widespread use SCEP remains to this day a popular enrollment protocol, especially for lightweight applications such as device enrollment. Microsoft’s choice to extend SCEP in defining its Intune service for enrolling devices against the Azure cloud has cemented SCEP as a protocol to support for many years to come.  

Due to the focus on being lightweight, SCEP lacks support for several features which might be considered essential, including revocation and explicit renewal (which exists in the RFC, but not in draft 23). SCEP’s payload encryption is also one of its main downsides, as the encryption method relies on the CA’s public key. This means that SCEP only supports RSA keys and is very unlikely to have any use in a post-quantum future. Arguably, the encryption process itself is complex enough to nullify the ‘S’ in SCEP.

+ As a legacy protocol still sees widespread use and support

+ A given if your use case involves Microsoft Intune

– The as-of-yet limited adoption of the RFC as opposed to the draft may lead to compatibility issues in the future

– Operations set does not include complete certificate lifecycle

– No support for elliptic curves and limited crypto agility

– Cisco themselves recommend EST for new applications

In many ways the spiritual successor to SCEP, the Enrollment over Secure Transport protocol (EST) was written by elements of Cisco and Aruba Networks as a lightweight enrollment protocol with TLS in mind, as well as incorporating lessons learned by the time of its publication in 2013. As with SCEP, EST lacks a message type for revocation, but supports renewal out of the box. EST is described in RFC 7030.

One of the tenets of EST is specifically its reliance on TLS, which allows payloads to be transmitted over an encrypted channel and thus negating the need to encrypt them using a shared secret. This in turn allows EST to handle elliptic curve-based keys, unlike SCEP.

As with SCEP, EST can use a shared secret (password) for client authentication, but can also make use of a client certificate issued by a trusted third party.

Relying on the HTTPS stack leads to simpler queries (EST can be called with curl), which allows for lightweight client implementations. Additionally, EST can be used to have the keys generated on the server side. These details make EST the natural choice for IoT and other lightweight PKI use cases.

+ If you need a protocol with a full suite of operations

+ You’re a telecom manufacturer or somebody else in an industry that relies on 3GPP

– You’re not ready to maintain a complex client which may need to take different takes on the RFC from different CA vendors into account.

ACME is one of the few protocols developed with a very singular purpose in mind – it was developed by a public-benefit corporation known as the Internet Security Research Group (ISRG) as part of a concerted effort to make TLS widely available and used across the internet. The other elements of this effort are the Let’s Encrypt Certificate Authority and the attendant CertBot certificate client.

Where ACME diverges from other enrollment protocols is the complete focus on automation, throughout the lifecycle of the certificate and especially in allowing the client to provide proof of identity (ownership of a specific DNS name) without any manual interaction or verification needed from the CA.

To do so, ACME provides a framework of challenges, which allow the CA to specify a number of ways for the client to prove ownership over whatever resource is to be specified as the identity of that certificate, be it a DNS name or an e-mail address for an S/MIME-certificate.  Theoretically, a client running ACME is meant to be fire-and-forget, enrolling and continuously renewing the certificate for as long as the given identity is still controlled.

While this sounds like a cornucopia of PKI goodness, it is worth keeping in mind that ACME is written with the TLS certificate use case primarily in mind. While the writers of RFC 8555 adroitly allowed for extensions of the RFC to define additional challenge types (and several exist as RFCs or drafts), the ACME protocol still hinges on this interaction being performed – in fact skipping it negates the use case for ACME entirely.

The complexity of this interaction also puts an onus on client support, as any extended challenge or variation on the RFC hosted by the server is meaningless unless the clients (of which CertBot is one, but there is a plethora) choose to honor it. So keep in mind that any use case that diverges from the general model of CA/client interaction needs to be supported both on the server and client side.

+ Best protocol to use for issuing TLS certificates

+ Provides complete operations set and built-in automation for enrollment

+ Automated renewal promotes the use of short-lived certificates, which in turn provides crypto agility

+ Easily extendable RFC provides ample opportunity to find more use cases

– Vanilla RFC is optimized for TLS certificates, whereas other use cases need to ensure that there is 3^rd party client support.

– No matter the use case, ACME relies on a challenge being processed as part of the workflow. If your use case does not involve allowing the CA to verify control of a resource, then ACME may not be the best protocol for you.

Finally, we’re going to talk about our homegrown REST API, supplemented by our legacy WebService API. This API is naturally as capable as all the others, but additionally provides insight and management capabilities, allowing complex workflows such as working with EJBCA’s approval system, managing end entities, crypto tokens and CAs.

Like EST, EJBCA’s REST API relies on TLS for message security and integrity, but authentication can also be provided through OAuth as well as a client certificate. Naturally, our REST API is under constant development, so as new workflows emerge, they can be implemented and rolled out far more rapidly than waiting for an RFC update to pass.

The downside of relying on our REST API is of course locking yourself into EJBCA as a single vendor, as with any proprietary API. This is naturally the case for the whole industry, as there hasn’t been any successful attempt at creating a standardized REST API among PKI vendors.

+ Infinitely extendible, both by request from Keyfactor and to anybody with access to the source code

+ Provides more granular enrollment and issuance workflows compared to other protocols

+ Can be used with EJBCA’s more complex workflows such as approvals

+ Can be used to manage aspects of EJBCA as well, such as crypto tokens, end entities and CAs

– As a proprietary protocol, support for EJBCA’s REST API among third party clients is limited

For you to be able to cover all your PKI use cases today and in the future, you will likely need the flexibility to choose the relevant protocols. EJBCA supports these and other protocols, a wide variety of public key infrastructure (PKI) use cases, scenarios, and integrations into other application ecosystems – and is proven in large deployments worldwide. And as it is available as open source and free trial cloud versions, you can go ahead and try it out already today.

Do you want to get hands on and try it out for yourself?

• Watch part two of the PKI at the Edge training to learn how to generate certificates and CRLs by using EJBCA and Bouncy Castle with CMP as well as REST API.
• For a detailed specification, see EJBCA Interoperability and Certifications.
• If you need support for other protocols or use cases, you are welcome to contact us.