What is EST (Enrollment Over Secure Transport) protocol?

EST is recognized for its ease of use and its security features, including the use of HTTPS for secure transport and transport layer security (TLS) for client and server security. It also supports additional cryptographic algorithms such as elliptic curve cryptography (ECC) and elliptic curve digital signature algorithm (ECDSA), unlike other widely used certificate management protocols like Simple Certificate Enrollment Protocol (SCEP), which was sponsored by Cisco and developed in the 1990s. As a result, EST has been put forward as a replacement for SCEP by the Internet Engineering Task Force (IETF) working group.

Why use enrollment over secure transport?

While there is no stronger, easier-to-use authentication and encryption solution than the digital identity provided by PKI, there are many potential pitfalls inherent in managing PKI certificates manually. Organizations need a certificate management automation standard like EST to ensure certificates are correctly configured and deployed at scale without human intervention.

Busy IT teams can ill-afford to manually deploy and manage certificates as doing so is risky, time-consuming and highly error-prone. Whether an organization deploys a single SSL certificate for a web server or manages millions of certificates across all networked endpoints, mobile devices, and user identities in an organization, the provisioning process from issuance to configuration and then deployment can take up to several hours per certificate.

Furthermore, manually managing certificates also puts enterprises at significant risk of certificates being forgotten until after expiration, resulting in sudden outage of critical business systems and exposure to malicious attacks.

The level of automation enabled by EST not only helps reduce risk but allows IT administrators to gain back precious time in their busy days.

EST vs SCEP for certificate enrollment

Similar to EST, SCEP is also a certificate management protocol that helps IT administrators issue them automatically. SCEP has gained significant traction with businesses as an important component of enterprise security. Both EST and SCEP are satisfactory protocols for automated certificate enrollment and provide similar enrollment processes.

Yet, the IETF working group has established EST as a replacement for SCEP. Being a newer protocol, EST offers an easy-to-use certificate management solution and updated capabilities that deliver several key advantages for today's enterprise PKI environments, including:

• Secure transport: It is inherently secure as all client and server requests and responses are communicated over TLS without the need for authentication of messages by encoding them with a shared secret identifier like SCEP does or by a challenge password like the Automated Certificate Management Environment protocol (ACME) does.
• Designated certificate requestors: With EST, the certificate signing request (CSR) can be associated with a specific trusted requestor that is authenticated with TLS. Using SCEP, the CSR is authenticated using a shared secret between the client and the CA, introducing security risks if the shared secret is lost or exposed.
• Crypto-agility and algorithm support: It supports the ECC and ECDSA algorithms, which SCEP does not because the PKCS 7 methods it uses for data protection depend only on the RSA encryption algorithm. Additionally, this algorithm independence allows EST a level of crypto-agility that establishes inherent support for future cryptographic algorithms.
• Automated certificate renewal: EST has been developed to support automatic re-enrollment. Though a recently submitted draft to update SCEP introduces renewal messages, it previously did not support re-enrollment. As a result, the many existing SCEP implementations require IT teams to make significant updates to their administration systems to support automated certificate renewal.
• Server-side key generation: Server-side key generation is necessary for resource PKI (RPKI) environments or constrained devices that do not have the ability to generate a random private key. SCEP supports only the private key generation at the client, whereas EST allows the server to generate the private key.
• Transition periods for the incremental root of trust rollover: In instances of CA rollover or any need to change the root of trust, EST adopts the Certificate Management Protocol (CMP) model for CA certificate rollover though it does not use the CMP message syntax or protocol. EST offers the model to refresh the root of trust by using three certificates in a transition period. The transition period allows incremental rollover to the new root CA across all certificates while maintaining communications between clients and the EST server. On the other hand, SCEP requires CA rollover across all certificates to occur at once on a defined date, which puts critical business systems at risk of an outage should a problem occur with the rollover.
• Certificate revocation: There's no mechanism to retrieve a certificate's revocation status. This doesn't really matter though as its lack of certificate revocation list (CRL) retrieval functions is not an impediment. Instead, Online Certificate Status Protocol (OCSP) and OCSP stapling offer complete revocation features and should be used for this function. SCEP does offer a CRL retrieval message so that endpoints can receive the revocation status of a specific certificate, but this has limited value as CRLs were recently deprecated by Firefox in favor of OCSP.

How does the EST protocol work?

The EST enrollment service standardizes the interoperability and secure information exchange between a client and a CA that is required to issue a certificate. It is commonly applied to the enrollment of numerous certificate use cases, including web servers, DevOps, endpoint devices, IoT devices, user identities, email services, and any other place PKI certificates are used.

In a PKI architecture, the EST service is located between a client and the CA and performs several functions traditionally assigned to the Registration Authority (RA) role. Its job is to provide validation of whether EST clients should receive the certificate they have requested or not. If so, it passes the request to CA and returns the resulting certificate to the client. The client communicates with an EST server, which listens for requests on a standard URL path. Clients just need to know the IP address of the server to make requests.

The EST enrollment process is developed to be easy for the establishment of automatic certificate issuance from a trusted CA. The general client/server interaction proceeds as follows:

1. The client initiates a TLS-secured HTTP session with an EST server and validates the certificate offered by the server.
2. The client requests and verifies the chain of trust from the server, including any intermediate certificates that lie between the root and the EST CA, and stores the root certificate.
3. The client generates a key and a CSR and then PKCS#10 certificate request and sends it to the server.
4. The EST server requests and receives the certificate issued from the CA and then returns the signed certificate to the client in PKCS#7 format for storage on the client device.

In addition, an EST client can renew or rekey its existing client certificate by submitting a re-enrollment request to an EST server. And additional optional requests can be transported via EST to support other certificate operations, such as passing CSR attributes that may be desired by the CA and server-side key pair generation.

The standardized request functions a client can make, and the corresponding URI path include:

• Distribution of CA certificates (/cacerts)
• Enrollment of clients (/simpleenroll)
• Re-enrollment of clients (/simplereenroll)
• Full certificate management over CMS (CMC) (/fullcmc)
• Server-sidekey generation (/serverkeygen)
• CSR attributes (/csrattrs)

Sectigo support

Sectigo recognizes the complexity and scale of enterprise certificate needs. Enterprises rely on PKI certificates to authenticate and encrypt everything from web servers both in the cloud and on-premises, to networked devices, mobile devices, user identities, email systems, network appliances, IoT devices, DevOps environments, digital signatures, and more. Sectigo offers SSL, Code Signing, S/MIME, and other X.509 certificates that support EST, as well as an automated end-to-end certificate lifecycle management system that allows enterprises to manage certificates at scale through a single pane of glass.

Configuring a Sectigo EST service is a simple task, and is performed by following these steps:

1. As a prerequisite, Sectigo provisions you with an EST instance and provides the URL and authentication credentials for the EST configuration application.
2. You log into the configuration application in a browser to start the configuration process.
3. You create one or more adapters to connect the EST service to the Sectigo certificate issuance system.
4. You then create one or more templates that map an incoming request to an adapter, allowing you to control what client can request that particular certificate type.

Upon completing those steps, you are ready to test and perform your certificate enrollment or re-enrollment via your Sectigo EST service.

For a complete guide to EST configuration using Sectigo Certificate Manager, including how to create adapters and templates, go to the Sectigo Knowledge Base and refer to the Sectigo Certificate Manager Administration Guides.

For details on values of parameters to be specified in the configuration profile, contact your Sectigo account manager.