EST

ENTERPRISE This is an EJBCA Enterprise feature.

Enrollment over Secure Transport (EST) is an X.509 certificate management protocol targeting public key infrastructure (PKI) clients that need to acquire client certificates and associated certificate authority (CA) certificates.

    Introduction

    EJBCA supports the EST protocol as defined in RFC 7030. Support for EST was added in EJBCA version 6.11.

    EST provides a basic protocol for certificate enrollment and management similar to SCEP, with the following distinct advantages:

    • While SCEP communicates over HTTP and ensures integrity by wrapping the payload in a cryptographic envelope, EST requests are always over TLS and thus inherently secure.

    • EST supports ECC, while SCEP does not.

    • While SCEP requires a shared secret to authenticate CSRs, in EST authentication is implicit when negotiating the TLS connection.

    • Certificate renewal is an integral part of EST, while in SCEP it is rather an afterthought.

    • While not supported in EJBCA, EST supports server-side key generation, which SCEP does not.

    EJBCA can work in the following modes with EST:

    • Client mode: Client mode works like any other enrollment in EJBCA. When a request comes in, EJBCA verifies the request and issues a certificate to a user that has been previously registered in EJBCA (pre-authorized). The certificate contents are (by default) based on the pre-registered data instead of the request data, albeit Override functionality in certificate profiles can be used.

    • RA mode: Used when the EST client acts as an RA to EJBCA where the RA sends a certificate request to EJBCA, expecting the CA to issue a certificate with approximately the contents request by the CA. No user is pre-registered in EJBCA, but when authenticated RA EST messages arrive, a user is created in EJBCA and a certificate is issued.

    Supported Operations

    The following operations in EST are supported:

    Name

    Description

    cacerts

    A GET request that returns a cert-only pkcs#7 blob containing the CA certificate (and possible chain) for the given alias that is used to issuing certificates via enrollment operation. This operation requires no authentication.

    simpleenroll

    A POST request with a CSR in PKCS#10 format and Base64 encoded to be signed by the specified CA for the given alias. Requires an existing client certificate for authentication and/or HTTP Basic authentication via username and password.

    The end entity username will be set according to the specified RA name generation scheme. If there is no existing end entity with the generated username, a new end entity will be created. If an end entity with the specified username already exists, it is treated as a renewal: a new certificate is issued for the existing end entity (as long as no settings block this behavior: e.g. Enforce Unique DN or Enforce Unique Public Keys).

    simplereenroll

    A POST request with a CSR in PKCS#10 format and Base64 encoded to be signed by the specified CA for the given alias. Requires authenticating with the original certificate, which has to be valid (to establish a TLS connection) and not revoked.

    A request with an unsupported operation will result in an HTTP not found (404) response from the server.

    EST Configuration

    Access

    The EJBCA EST implementation uses the Well-Known Uniform Resource Identifiers (URIs) definition codified in RFC 5785.

    Like SCEP and CMP, EJBCA supports using EST for multiple CAs by the use of aliases. Each alias is then accessible using:

    $ /.well-known/est/<alias>/<operation>

    When an alias with the name est is configured, this alias is available over the default EST URL, which is the URL used by the estclient, see Testing - Client Interoperability in EST RA Mode Configuration.

    $ /.well-known/est/<operation>

    A request with an unknown alias will result in an HTTP bad request (400) response from the server.

    Configuring the Truststore

    When renewing a certificate using EST, the certificate which is to be renewed is used as a client certificate to authenticate to the CA. The CA must then trust the issuer of this certificate to be able to establish a TLS connection to the PKI client. If TLS connections are handled by WildFly, you need to add the issuer chain to WildFly's truststore. If TLS connections are handled by an HTTP proxy in front of WildFly, you need to add the issuer chain to the truststore of the HTTP proxy.

    WildFly

    To add an issuer to WildFly's truststore, you can use keytool.

    1. Download the CA certificate of the issuer as a PEM file, e.g. by going to CA Certificates & CRLs in EJBCA.

    2. Transfer the CA certificate to the machine where EJBCA is installed.

    3. Use keytool to add the CA certificate to Wildfly's truststore.

      $ keytool -keystore /opt/wildfly/standalone/configuration/keystore/truststore.jks -alias <NAME_OF_CA> -importcert -file <ISSUER.PEM> -storepass changeit

    Appliance

    If you are using the EJBCA Hardware Appliance, you can use WebConf to modify the truststore on the appliance.

    1. Download the CA certificate of the issuer as a PEM file, e.g. by going to CA Certificates & CRLs in EJBCA.

    2. Go to WebConf, and click Access > Client TLS trust anchors in the menu.

    3. In the Application interface section, click Add.

    4. Upload the CA certificate and click Activate new CA certificate to add it to the appliance truststore.

      images/download/attachments/143722605/appliance_add_ca_certificate.png

    Configuring Aliases

    For information on configuration and examples, see: