For the latest version, please use Certificate Lifecycle Manager 6.16.0!

MTG EST


Introduction

This page describes the basic functions of MTG EST, an implementation of an EST server according to RFC 7030 🔗 and its integration with MTG CLM.

Some certificate providers might not be compatible with EST protocol. For more details, please refer to the supported certificate providers section.

MTG CLM Integration

To enable integration with MTG CLM, MTG EST uses the credentials of an API client. Additionally, MTG EST uses a policy to handle certificate management. It identifies the CA that will issue the certificate and the template to be used. It can also contain additional restrictions and configurations for the certificate lifecycle.

Defining Default Policy

API clients are optionally associated with a default policy. By default, MTG EST uses the default policy of the associated API client to handle certificate management. In case the API client is not associated with a default policy and the client does not specify a different policy in the request (see Different Policies Endpoints), MTG EST will respond with an invalid identifier error.

Defining Different Policy

MTG EST supports specifying a different policy as the policy to be used instead of the API client’s default policy. The new policy ID must used in the requests towards EST server as described in Different Policies Endpoints.

Set up Password Login

MTG EST supports basic authentication (see RFC 7617 🔗). The credentials for this type of authentication can be obtained by creating an end entity and an associated end entity password. More details can be found in end entities passwords. Configure the end entity ID of the end entity and its password to execute basic authentication requests.

EST Modes

EST can be used either by end entities to request certificates, or by registration authorities (RAs) to request certificates on behalf of end entities. The first option is call EST in EE mode(the default use case) and the second option is called EST in RA mode.

In EE mode the end entity client can initially use an end-entity password and the end-entity UUID, to request a certificate using Basic Authentication. The received certificate can then be used by that end entity, to request another certificate for themselves, using mTLS. The configured API client requires following permissions:

  • read permission on provided policy and corresponding realm

  • read permission on provided end entity

  • read permission on provided certificate

  • create permission on corresponding realm for provided end entity and policy

In RA mode a RA certificate and key is required to be present in MTG CLM: this can be done by selecting one of the MTG CLM users in the system and issuing a certificate for them. This certificate can then be used to authenticate the CLM user using mTLS. In this case, the EST server creates certificates for end entities on behalf of the MTG CLM user, and thus its API client requires some additional permissions:

  • global permission USERS_READ

  • read permision on configured SYSTEM realm

  • read permission on provided policy and corresponding realm

  • read permission on end entities and create permission for end entities on corresponding realm

  • create permission on corresponding realm for provided end entity and policy

Custom Features

Different Policies Endpoints

By default, MTG EST offers the following endpoints:

  • EST_SERVER_BASE_URL/.well-known/est/cacerts

  • EST_SERVER_BASE_URL/.well-known/est/simpleenroll

  • EST_SERVER_BASE_URL/.well-known/est/simplereenroll

Client requests to these endpoints use the default policy.

MTG EST provides supplementary endpoints to support requests that require a different policy. Requests towards these endpoints specify a different policy to use, rather than the default policy of the associated API client. These are the endpoints for the different policy endpoints:

  • EST_SERVER_BASE_URL/.well-known/est/<identifier>/cacerts

  • EST_SERVER_BASE_URL/.well-known/est/<identifier>/simpleenroll

  • EST_SERVER_BASE_URL/.well-known/est/<identifier>/simplereenroll

The <identifier> needs to be replaced with a valid policy ID. For example to request a certificate that is issued under the policy ffc0d281-f9df-45cd-a30d-1881cd67012a use the URL: EST_SERVER_BASE_URL/.well-known/est/ffc0d281-f9df-45cd-a30d-1881cd67012a/simplereenroll.

Troubleshooting EST Connections

EE Mode

  • Did you create an end entity and a corresponding end entity password for the correct policy you are planning to use?

  • When issuing a certificate using Basic Authentication, did you provide the correct username and password? The username is the end entity UUID.

  • Did you provide the correct policy identifier in the EST server URL? This is required if the policy is not the default one for the EST API client.

  • When using mTLS, do you trust the root certificate on the reverse proxy?

  • When using mTLS, did you send all CA certificates up to the root CA together with the client certificate? The SubCA certificate should be appended to the client certificate, so that the reverse proxy can verify the client and complete the TLS handshake.

RA Mode

  • Did you add the RA root CA to your reverse proxy truststore?

  • Are you using a MTG CLM user RA certificate with mTLS?

  • Does the CARA template for the RA certificate include the correct extension to identify a user certificate as a RA certificate? The extension is:

    <extendedKeyUsage clientAuth="true">
    <keyPurposeId>
        <default>1.3.6.1.5.5.7.3.28</default>
    </keyPurposeId>
</extendedKeyUsage>

  • Does your user have access to MTG CLM and permission to create certificates in the realm where the policy is located?

  • Does the EST API client have access to the SYSTEM realm to read the user RA certificate?