CA service and EST service on ISE

Introduction

This document describes the Certificate Authority (CA) service and the Enrollment over Secure Transport (EST) service that are present in the Cisco Identity Services Engine (ISE).

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• ISE
• Certificates and Public Key Infrastructure (PKI)
• Simple Certificate Enrollment Protocol (SCEP)
• Online Certificate Status Protocol (OCSP)

Components Used

The information in this document is based on these software and hardware versions:

•  Identity Services Engine 3.0

The information in this document was created from the devices in a specific lab environment. All of the devices that are used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Certificate Authority (CA) Service

Certificates can be self-signed or digitally signed by an external Certificate Authority (CA). The Cisco ISE Internal Certificate Authority (ISE CA) issues and manages digital certificates for endpoints from a centralized console in order to allow employees to use their personal devices on the company's network. A CA-signed digital certificate is considered industry standard and more secure. The Primary Policy Administration Node (PAN) is the Root CA. The Policy Service Nodes (PSNs) are subordinate CAs to the Primary PAN.

ISE CA Functionalities

The ISE CA offers these functionalities:

• Certificate Issuance: Validates and signs Certificate Signing Requests (CSRs) for endpoints that connect to the network.

• Key Management: Generates and securely stores keys and certificates on both PAN and PSN nodes.

• Certificate Storage: Stores certificates that are issued to users and devices.

• Online Certificate Status Protocol (OCSP) Support: Provides an OCSP responder to check the validity of certificates.

ISE CA Certificates Provisioned on Administration and Policy Service Nodes

After installation, a Cisco ISE node is provisioned with a Root CA certificate and a Node CA certificate to manage certificates for endpoints.

When a deployment is set up, the node that is designated as the Primary Administration Node (PAN) becomes the Root CA. The PAN has a Root CA certificate and a Node CA certificate that is signed by the Root CA.

When a Secondary Administration Node (SAN) is registered to the PAN, a Node CA certificate is generated and is signed by the Root CA on the Primary Administration Node.

Any Policy Service Node (PSN) that is registered with the PAN is provisioned an Endpoint CA and an OCSP certificate that is signed by the Node CA of the PAN. The Policy Service Nodes (PSNs) are subordinate CAs to the PAN. When the ISE CA is used, the Endpoint CA on the PSN issues the certificates to the endpoints that access the network.

Enrollment over Secure Transport (EST) Service

The concept of public key infrastructure (PKI) has existed for a long time. The PKI authenticates the identity of users and devices by means of signed public key pairs in the form of digital certificates. Enrollment over Secure Transport (EST) is a protocol to provision these certificates. EST service defines how to perform certificate enrollment for clients that use Certificate Management over Cryptographic Message Syntax (CMC) over a secure transport. According to the IETF - “EST describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.”

EST use cases

The EST protocol can be used:

• To enroll Network Devices by means of Secure Unique Device Identity
• For BYOD Solutions

Why EST?

Both EST and SCEP protocols address certificate provisioning. EST is a successor to the Simple Certificate Enrollment Protocol (SCEP). Because of its simplicity, SCEP has been the de facto protocol in certificate provisioning for many years. However, the use of EST over SCEP is recommended for these reasons:

• Use of TLS for secure transport of certificates and messages - In EST, the certificate signing request (CSR) can be tied to a requestor that is already trusted and authenticated with TLS. Clients cannot get a certificate for anyone but themselves. In SCEP, the CSR is authenticated by a shared secret between the client and the CA. This introduces security concerns because someone with access to the shared secret can generate certificates for entities other than themselves.
• Support for enrollment of ECC-signed certificates - EST provides cryptographic agility. It supports elliptic curve cryptography (ECC). SCEP doesn’t support ECC and depends on RSA encryption. ECC offers more security and better performance than other cryptographic algorithms like RSA even while it uses a much smaller key size.
• EST is built to support automatic certificate re-enrollment.

TLS’s proven security and continuous improvement helps ensure that EST transactions will be secure in terms of cryptographic protection. SCEP’s tight integration with RSA to protect data introduces security concerns as technology advances.

EST in ISE

In order to implement this protocol, a client and a server module are needed:

• EST Client - embedded in the regular ISE tomcat.
• EST Server - deployed on an open source web server called NGINX. This runs as a separate process, and it listens on port 8084.

Certificate-based client and server authentication is supported by EST. The endpoint CA issues the certificate for the EST client and the EST server. The EST Client and Server certificates and their respective keys are stored in ISE CA’s NSS DB.

Types of Requests in ISE EST

Whenever the EST server comes up, it gets the latest copy of all of the CA certificates from the CA server and stores it. Then, the EST client can make a CA certificate request to get the whole chain from this EST server. Before it makes a simple enrollment request, the EST client has to issue the CA certificate request first.

CA Certificates Request (based on RFC 7030)

1. The EST client requests a copy of the current CA certificates
2. HTTPS GET message with an operation path value of "/cacerts”
3. This operation is performed before any other EST requests
4. A request is made every 5 minutes to get a copy of the most up-to-date CA certificates
5. The EST server should not require client authentication

The second request is a simple enrollment request and it needs authentication between the EST client and the EST server. This happens each time an endpoint connects to ISE and makes a certificate request.

Simple Enrollment Request (based on RFC 7030)

1. The EST client requests a certificate from the EST server
2. HTTPS POST message with the operation path value of "/simpleenroll”
3. The EST client embeds the PKCS#10 request within this call which is sent to ISE
4. The EST server must authenticate the client

EST and CA service status

CA and EST services can only run on a Policy Service node that has session services enabled on it. In order to enable session services on a node, go to Administration > System > Deployment. Select the server hostname on which session services need to be enabled and click Edit. Select the “Enable Session Services” check box under Policy Service persona.

Status shown on GUI

EST service status is tied to the ISE CA service status on ISE. If CA service is up, then EST service is up and if CA service is down, EST service is also down.

Status shown on CLI

Alarms on dashboard

Alarm will be shown on the ISE dashboard if EST and CA services are down.

Impact if CA and EST services are not running

• EST Client “/cacerts” call failure can happen when EST Server is down. The “/cacerts” call failure can also happen if the EST certificate’s CA chain is incomplete.
  

• ECC based endpoint certificate enrollment requests will fail.

• BYOD flow will break if either of the previous two failures occur.
• Queue Link Error alarms may be generated.

Troubleshoot

If the BYOD flow with EST protocol does not work properly, check these conditions:

• Certificate Services Endpoint Sub CA certificate chain is complete. In order to check whether the certificate chain is complete:

  1. Choose Administration > System > Certificates > Certificate Authority > Certificate Authority Certificates.

  2. Select the check box next to the certificate and click View in order to check a particular certificate.

• Ensure that the CA and EST services are up and running. If the services are not running, go to Administration > System > Certificates > Certificate Authority > Internal CA Settings in order to enable the CA service.

• If an upgrade has been performed, replace the ISE Root CA certificate chain after the upgrade. In order to do this:

  1. Choose Administration > System > Certificates > Certificate Management > Certificate Signing Requests.

  2. Click Generate Certificate Signing Requests (CSR).

  3. Choose "ISE Root CA" in the Certificate(s) will be used for drop-down list

  4. Click Replace ISE Root CA Certificate Chain.

• Useful debugs that can be enabled to check the logs include est, provisioning, ca-service, ca-service-cert. Refer to ise-psc.log, catalina.out, caservice.log and error.log files.