EST protocol for Automated Certificate Provisioning

This feature allows you to enable the EST (Enrolment Over Secure Transport) protocol for all trustpoints while using TLS to secure transport.

EST protocol for automated certificate provisioning

Enrollment over Secure Transport (EST) is a digital certificate provisioning protocol that

  • enhances security by using TLS for secure communication, and

  • automates the renewal of certificates to minimize manual intervention.

Table 1. Feature History Table

Feature Name

Release Information

Feature Description

EST protocol for automated certificate provisioning

Release 25.1.1

Introduced in this release on: Fixed Systems (8200 [ASIC: Q200, P100], 8700 [ASIC: P100, K100]); Centralized Systems (8600 [ASIC:Q200]) ; Modular Systems (8800 [LC ASIC: Q100, Q200, P100])

This release introduces support for Enrollment over Secure Transport (EST), a digital certificate provisioning protocol, which enhances certificate management by offering secure transport using TLS and designated certificate requestors. It enables automated certificate renewal.

EST is an enhancement of the existing Simple Certificate Enrollment Protocol (SCEP), providing improved security and flexibility for certificate management operations over both IPv4 and IPv6 networks.

The feature introduces these changes:

CLI:

YANG Data Model:

  • Cisco-IOS-XR-crypto-cepki-cfg

  • Cisco-IOS-XR-um-crypto-cfg

(see GitHub, YANG Data Models Navigator)

EST protocol—key features and benefits

These are the key features and benefits of the EST protocol:

  • Secure transport—EST utilizes TLS to ensure that all messages and certificates are securely transmitted without the need for additional encapsulation.

  • Designated certificate requestors—With EST, the certificate signing request (CSR) can be associated with a specific trusted requestor that is authenticated with TLS.

  • Automated certificate renewal—The protocol supports automatic re-enrollment, facilitating seamless renewal of certificates.

EST protocol—key components and related terminologies

Understand key components and terms related to the EST protocol:

  • Certificate Management Protocol (CMP)—A protocol with comprehensive management capabilities for managing digital certificates, including their enrollment, renewal, and revocation.

  • Certificate signing request (CSR)—A message sent by the client to the CA to request a digital certificate. It includes the client's public key and identifying information.

  • PKCS 7—A standard used for cryptographic message syntax, which is employed by SCEP to encapsulate messages.

  • Public Key Infrastructure (PKI)—The framework that manages digital certificates and keys, essential for certificate provisioning operations using the EST protocol.

  • Simple Certificate Enrollment Protocol (SCEP)—An older protocol used for certificate provisioning that relies on HTTP and PKCS 7 for securing messages and lacks some of the modern security features of EST.

Client authentication options in the EST protocol

  • TLS certificate-based authentication (mTLS)—Requires the client to have a valid certificate chain signed by a CA in the EST server trust store so that server can verify the client during mutual TLS (mTLS) authentication. The bootstrap certificate is used only during the first enrollment and can be onboarded using existing methods like SCEP. For re-enrollment, the certificate issued during the initial enrollment is used in the mTLS handshake.

  • HTTP-based authentication—Used when a bootstrap certificate is not available for initial enrollment. After establishing a TLS session, the EST client sends HTTP authentication details. The HTTP-based authentication method uses Type6 encryption to secure passwords configured on the router, preventing unauthorized access. Type6 encryption is disabled by default and must be enabled. Additionally, a master key must be created, which is securely stored in TAM. This authentication method involves sending a username and clear text password through the TLS-protected channel, ensuring password security via encryption.

Guidelines and limitations for configuring the EST protocol

Supported key types

  • In IOS-XR release 25.1.1, only RSA keys are supported for signing the Certificate Signing Request (CSR) during enrollment; ECDSA keys are not.

Client authentication methods

  • The EST client supports both TLS certificate-based authentication and HTTP-based authentication. Cisco recommends using TLS certificate-based authentication as per RFC 7030, even though both methods are available.

TLS validation and authentication requirements

  • If client or server certificate validation fails during the TLS handshake, EST enrollment fails. No fallback mechanism switches to HTTP authentication if TLS certificate-based client authentication fails.

Re-enrollment

  • For re-enrollment, the client always uses the previously issued certificate to establish the TLS connection.

  • A re-enrollment profile is required in scenarios where the EST server uses a fixed username and password for re-enrollment, but uses a one-time password (OTP) for initial enrollment. This behavior is optional and depends on how the EST server is configured.

Certificate types and their uses in EST protocol

Learn about the types of certificates used in the EST protocol, along with their issuers and specific uses.

Table 2. Certificates and their corresponding uses

If the certificate type is...

And the issuer is...

Then it is used for...

EST server certificate

EST server

authenticating the CA during the TLS handshake when the EST server interacts with clients.

EST client certificate

EST client

authenticating to the EST server during certificate enrollment operations.

End entity or leaf certificate

EST server

non-EST uses, such as authenticating devices in different contexts beyond EST operations.

EST server certificate

third-party web CA

providing authentication for the EST server by a CA that is not part of the EST infrastructure but trusted as a third party.

third-party EST client certificate

third-party web CA

authenticating the EST client to the EST server for initial interactions before enrollment.

Trust anchor databases in EST protocol

Effective certificate validation and authentication in the EST protocol involve different types of trust anchor (TA) databases, each serving specific purposes.

A TA database refers to a repository of trusted anchor certificates used to verify the authenticity of a Certification Authority (CA) during the certificate enrollment process. The database acts as a trusted source for validating the CA issuing certificates to clients through the EST protocol.

Table 3. Trust anchor databases and their uses

If the TA database type is...

Then it is used by...

For the purpose of...

EST server

EST server

authenticating certificates issued by the EST CA during enroll and re-enroll operations.

EST server (implicit)

EST server

authenticating certificates issued by third-party TAs; can be disabled if not needed.

EST client

EST client

authenticating EST server certificates issued by the EST CA.

EST client (implicit)

EST client

authenticating an EST server using an externally issued certificate; can be disabled if unnecessary.

Pre-defined message types in EST protocol

The EST protocol includes several pre-defined message types, each serving distinct functions to facilitate secure certificate provisioning:

  • CACerts—This message type is used to request the CA certificates. It ensures the client can validate the CA's authenticity before proceeding with certificate enrollment.

  • SimpleEnroll—Utilized for simple enrollment of a certificate, this message type involves a client sending a certificate signing request (CSR) to the CA. If the request is valid, the CA issues a certificate in response.

  • Reenroll—Designed for requesting certificate renewal or reissuance, this message type allows clients to obtain a new certificate with updated validity or information when an existing certificate is about to expire.

Configure the EST protocol

Use this procedure to configure the EST protocol on your router, enabling secure and automated certificate provisioning.

Before you begin

Before configuring the EST protocol, ensure

  • access to the EST server is established and operational,

  • required certificates and keys are available for configuration,

  • you meet specific encryption requirements if you must use HTTP-based authentication:

    • Type6 encryption is enabled using the command password6 encryption aes for secure password handling, and

    • you create a master key and store it in Trust Anchor Module (TAM) using the command key config-key password-encryption to facilitate encryption.


      Note

      A master key for Type 6 encryption is typically stored securely within the device internal memory, specifically within a protected area known as the TAM.

Procedure

Step 1

Select the authentication method.

You can configure either TLS certificate-based authentication, HTTP-based authentication, or both. Use the table below to determine the appropriate sub-step based on the availability of a bootstrap certificate.
Table 4. Bootstrap certificate availability and authentication method

If...

Then follow...

A bootstrap certificate is not available

HTTP-Based Authentication sub-step.

A bootstrap certificate is available

TLS-Based Authentication sub-step.

  1. For HTTP-based authentication, create client authentication profiles for enrollment and re-enrollment.

    Example:

    Router# configure terminal
Router(config)# client-authentication profile P1_enroll
Router(config-client-authentication-profile)# username estuser password Encrypt6 estpwd_enrol
Router(config-client-authentication-profile)# client-authentication profile P2_re-enroll
Router(config-client-authentication-profile)# username estuser password Encrypt6 estpwd_re_enrol
Router(config-client-authentication-profile)# commit
    Table 5. Re-enrollment profile scenarios for HTTP-based authentication

    If...

    Then...

    separate profiles are configured for enrollment and re-enrollment

    P1_enroll is used for enrollment and P2_re-enroll is used for re-enrollment.

    only the enrollment profile is configured

    P1_enroll is used for both enrollment and re-enrollment.

  2. For TLS-based authentication, configure an SSL profile with the bootstrap certificate.

    Example:

    Router# configure terminal
Router(config)# ssl profile EST_SSL_profile
Router(config-SSL-profile)# certificate EST_BOOTSTRAP_TP
Router(config-SSL-profile)# commit
    For initial enrollment, ensure you add a bootstrap certificate using existing methods like terminal, SCEP, and so on.

Step 2

Configure a PKI trustpoint to specify the enrollment method as EST and attach the authentication profiles.

The code example includes CLI commands to attach both HTTP and TLS-based authentication profiles.

This command initializes the EST method for the specified trustpoint.

Example:

Router#configure terminal
Router(config)#crypto ca trustpoint EST_TP
Router(config)#SSL profile EST_SSL_profile
Router(config-trustp)#method est
Router(config-method-est)#commit 
Router(config-trustp)#enrollment authentication-profile P1_enroll
Router(config-trustp)#re-enrollment authentication-profile P2_re-enroll
Router(config-trustp)#commit

Step 3

Authenticate and enroll the certificates.

Run the CLI commands in EXEC mode.

Router# crypto ca authenticate EST_TP
Router# crypto ca enroll EST_TP

Step 4

Verify the certificate enrollment using EST is successful.

Example:

Router# show crypto ca trustpoint EST_TP:
crypto ca trustpoint est_tp
 ssl-profile example
 method est
 !
 enrollment authentication-profile enroll
 re-enrollment authentication-profile re_enroll
!

Step 5

Verify the certificates are enrolled on the trustpoint.

Example:

Router# show crypto ca certificates EST_TP
 
Trustpoint       : EST_TP
==================================================
CA certificate 
  Serial Number  : 10:01
  Subject:
            CN=SUB_CA_CERT,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Issued By      :
            CN=TWO-LEVEL-CA,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Validity Start : 12:31:40 UTC Sun Jun 14 2020
  Validity End   : 12:31:40 UTC Wed Jun 12 2030
 
  CRL Distribution Point
            http://10.105.236.78/crl.der
  SHA1 Fingerprint:
             D8E0C11ECED96F67FDBC800DB6A126676A76BD62 
Trusted Certificate Chain
  Serial Number  : 0F:A0:06:7A:C9:5E:A9:E7:61:A2:B9:2B:27:D1:D6:8F:3D:51:43:3B
  Subject:
            CN=TWO-LEVEL-CA,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Issued By      :
            CN=TWO-LEVEL-CA,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Validity Start : 13:12:32 UTC Sun Jun 07 2020
  Validity End   : 13:12:32 UTC Sat Jun 02 2040
 
  CRL Distribution Point
            http://10.105.236.78/crl.der
  SHA1 Fingerprint:
             08E71248FB7578614442E713AC87C461D173952F 
Router certificate
  Key usage      : General Purpose 
  Status         : Available 
  Serial Number  : 28:E5
  Subject:
            CN=test
  Issued By      :
            CN=SUB_CA_CERT,OU=SPBU,O=CSCO,L=BGL,ST=KA,C=IN
  Validity Start : 08:49:54 UTC Mon Feb 06 2023
  Validity End   : 08:49:54 UTC Wed Mar 08 2023
  SHA1 Fingerprint:
             6C8644FA67D9CEBC7C5665C35838265F578835AB 
Associated Trustpoint: EST_TP