Summary
The Enrollment over Secure Transport, or EST is a cryptographic protocol that describes an X.509 certificate management protocol targeting public key infrastructure (PKI) clients that need to acquire client certificates and associated certificate authority (CA) certificates. EST is described in RFC 7030. EST has been put forward as a replacement for SCEP, being easier to implement on devices already having an HTTPS stack. EST uses HTTPS as transport and leverages TLS for many of its security attributes. EST has described standardized URLs and uses the well-known Uniform Resource Identifiers (URIs) definition codified in RFC 5785.
Operations edit
EST has a following set of operations:
| API Endpoint | Operation | Description |
|---|---|---|
| /.well-known/est/cacerts | Distribution of CA Certificates | The EST client can request a copy of the current CA certificates with HTTP GET operation (RFC 7030 Section 4.1). |
| /.well-known/est/simpleenroll | Enrollment of Clients | EST clients request a certificate from the EST server with an HTTPS POST operation (RFC 7030 Section 4.2). |
| /.well-known/est/simplereenroll | Re-enrollment of Clients | EST clients renew/rekey certificates with an HTTPS POST operation (RFC 7030 Section 4.2.2). |
| /.well-known/est/fullcmc | Full CMC | An EST client can request a certificate from an EST server with an HTTPS POST operation (RFC 7030 Section 4.3). |
| /.well-known/est/serverkeygen | Server-Side Key Generation | An EST client may request a private key and associated certificate from an EST server using an HTTPS POST operation (RFC 7030 Section 4.4) |
| /.well-known/est/csrattrs | CSR Attributes | CA policy may allow inclusion of client-provided attributes in certificates that it issues, and some of these attributes may describe information that is not available to the CA. In addition, a CA may desire to certify a certain type of public key and a client may not have a priori knowledge of that fact. Therefore, clients SHOULD request a list of expected attributes that are required, or desired, by the CA in an enrollment request or if dictated by local policy. (RFC 7030 Section 4.5) |
Usage example edit
The basic functions of EST were designed to be easy to use and although not a REST API, it can be used in a REST-like manner using simple tools such as OpenSSL and cURL. A simple command to make initial enrollment with a pre-generated PKCS#10 Certificate Signing Request (stored as device.b64), using one of the authentication mechanisms (username:password) specified in EST is:
curl -v --cacert ManagementCA.cacert.pem --user username:password --data @device.b64 -o device-p7.b64 -H "Content-Type: application/pkcs10" -H "Content-Transfer-Encoding: base64" https://hostname.tld/.well-known/est/simpleenroll
The issued certificate, returned as a Base64 encoded PKCS#7 message, is stored as device-p7.b64.
See also edit
References edit
- RFC 7030, official specification
Implementations edit
- The library libest is a client and server implementation of EST.
- Bouncy Castle API offers EST API library for Java.
- DigiCert IoT Trust Manager is a server implementation of EST.
- EJBCA, a CA software, implements a subset[1] of the EST functions.
- Evertrust Horizon implements RFC 7030.
- Entrust CA PKIs support EST functions
- Sectigo Certificate Manager implements RFC 7030.
- The strongSwan pki --est tool is a client implementation of EST.
- ^ "EJBCA - The Java EE Certificate Authority". Archived from the original on 2019-06-07. Retrieved 2019-06-07.