Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Create a new article
950
Views
2
Helpful
0
Comments

Using Let's Encrypt Certificates with Cisco ISE

Tim Glen
Cisco Employee
Cisco Employee

‎05-15-2024 06:55 AM - edited ‎05-15-2024 10:42 AM

Table of Contents

 

 

 

Summary

Cisco ISE uses certificates for various purposes including communication between ISE nodes, communication with external servers and communication between ISE nodes and end user portals like guest, sponsor and BYOD. Some of those purposes work fine with a Self-Signed Certificate, and others work better with a globally recognized certificate.

Financial challenges may arise when administrators need to purchase certificates with multiple Subject Alternative Names or when certificates are required for each PSN in an organization. Some security operations teams frown upon wildcard certificates that are globally recognized as they can be used for any website at all.

ISE administrators can use ACME servers to generate globally recognized certificates that can be used on Cisco ISE. These certificates are as good as or better than those provided by most vendors (globalsign, verisign, etc).

 

ACME

Automated Certificate Management Environment or ACME is a protocol that enables administrators to interact directly with Certificate Authorities and generate certificates. These certificates can be used with Cisco products including Cisco ISE!

Several well-known entities support ACME, including Let’s Encrypt, ZeroSSL, and Google. Examples here will be with Let’s Encrypt. Another benefit of ACME certificates is that they are free!

 

Obtaining the Certificates

Obtain the Certificate from Let's Encrypt

See this document for how to obtain a certificate with Let’s Encrypt and Certbot.

Using Let's Encrypt Certificates with Cisco FirePower, ISE & IOS XE

 
Initially we need to dive in a bit in order to get the CA Certificate for ISE, let's take a look. Certbot clearly shows two files in the basic output.
 
certbot certificates
certbot-certs-WEB.png

 

But we need to dig in a little more, now lets see what is in that directory.
certbot-directory-WEB.png

 We have 5 files

  • cert.pem - this contains the ID cert and the public key for the ISE server
  • chain.pem - this contains the Issuing CA cert , in this case its Lets Encrypt - R3
  • fullchain.pem - this contains two certs, both the ID cert for the ISE server and the CA cert, R3
  • privkey.pem - this contains the private key that was used to sign the certificate in cert.pem
  • README - read if you like, otherwise lets keep going

 

 

Identify the Signing Certificate Authorities

In order for ID Certificates to be trusted, devices need to trust the Certificate Authorities that issued the ID certificate. For Cisco ISE, this logic follows all the way up to the Root CA. 

In this step we are going to use OpenSSL to walk up the certificate chain from the Identity Cert to the Issuing CA and finally to the Root CA.

First, review the file cert.pem,  this is the certificate that has been issued for the ISE node. We just have to look at 2 items, the Subject and the Issuer. Assure the Subject is the FQDN for your ISE node and determine the Issuer, in this case the Issuer is R3.

openssl x509 -noout -text -in cert.pem

openssl-x509-cert-pem-WEB.png

 

Next, review the file chain.pem, this contains the certificate for R3, the Issuer.  Again, look at the Subject and the Issuer.

Here we see that the Subject is R3, and the Issuer is ISRG Root X1.

openssl x509 -noout -text -in chain.pem
openssl-x509-chain-pem-WEB.png

 

We don't have the ISRG Root X1 certificate but we need it, and we will get it in the next step!

 

Obtain the ISRG Root X1 Certificate

We should only have to do this once.

ISRG is just short for the Internet Security Research Group, they are the parent non-profit for Let's Encrypt.

Today, in May 2024, Let's Encrypt is not including the Root CA Certificate in the package it sends back to Certbot, thats ok, we can just download it here.

 
Go to the Let's Encrypt Website
https://letsencrypt.org/certificates/
 
Now download the Self-Signed PEM file for the ISRG Root X1.
lets-encrypt-certificates-WEB.png

 

or just click here to download the same file.
https://letsencrypt.org/certs/isrgrootx1.pem

Now we have the the four files that we need.

 

Uploading the Certificates to ISE

Upload the ISRG Root X1 Certificate

This is the Root CA.

Login to ISE.
ISE -> Administration -> System -> Certificates -> Certificate Management -> Trusted Certificates, Import

Select the file, isrgrootx1.pem that was downloaded directly from the Lets Encrypt website

ise-certs-import-trusted-cert-X1-WEB.png

 

Upload the R3 Certificate

This is the Issuing CA.

This is the Certificate Authority that generated and signed the certificate that will be used to identify the ISE Node.

ISE -> Administration -> System -> Certificates -> Certificate Management -> Trusted Certificates, Import

ise-certs-import-trusted-cert-R3-WEB.png

 

Note: In early 2024 Let's Encrypt had a Singing Ceremony and spun up several new Certificate Authority Signing Servers. These new servers will be issuing ID Certificates in the near future. It's highly likely that you will soon be seeing R11 and R12.

https://letsencrypt.org/certs/2024/r11.pem

https://letsencrypt.org/certs/2024/r12.pem

 

Upload the ID Certificate

This is the certificate that has the Subject FQDN of your ISE Node. This certificate contains the public key.

In addition to cert.pem we will also upload the private key that is associated with the Certificate.

ISE -> Administration -> System -> Certificates, Import

ise-certs-import-system-cert-WEB.png

 

Verify the Certificate is on ISE

ISE -> Administration -> System -> Certificates, Select the new Certificate, View

Observe the ID Certificate Details.

Click on the R3 and observe the Issuing CA Certificate Details

Click on the ISRG Root X1 and observe the Root CA Certificate Details

ise-certs-system-idcert-WEB.png

Now we are ready to go!   Let's assign this certificate to the Admin Service and restart the ISE Services.

 

Assign the Certificate to the ISE Service

I like using Let's Encrypt certificates for both the Admin and Portal services.

 

ise-certs-usage-WEB.png

 

Renewal

Let's Encrypt certificates are valid for 90 days. Let's Encrypt recommends renewing the certificate at 60 days.

ISE warns the Administrator of a pending expiration when a certificate has <= 90 days left. Herein lies a caveat with using ACME certificates, their lifetime is 90 days so ISE will always show an Alarm.

As we are manually generating these certificates, when it comes time to refresh the certificate, just repeat this process: obtain a new certificate and install it on the ISE PAN or PSNs. Configure the Service to use the new Cert.

Configure Certificate Renewals on ISE is a very good document on Renewing.

 

Automation

Soon, Check out my GitHub Repo for some PoV code.  (should be up in next few days after I scrub the code a little more)

https://github.com/timmayg/ps-acme-asa

 

Other Stuff

This is just some reference info...

System Certificates: These are server certificates that identify a Cisco ISE node to client applications. Every Cisco ISE node has its own system certificates that are stored on the node along with the corresponding private keys.

Trusted Certificates: These are CA certificates that are used to establish trust for the public keys that are received from users and devices. The Trusted Certificates store also contains certificates that are distributed by the Simple Certificate Enrollment Protocol (SCEP), which enables the registration of mobile devices into the enterprise network. Trusted certificates are managed on the primary PAN, and are automatically replicated to all the other nodes in a Cisco ISE deployment.

Cisco ISE cannot import more than one certificate with the same private key. If the certificate is renewed and imported without changing the private key, then the existing certificate is replaced with the imported certificate.

To ensure certificate authentication in Cisco ISE is not impacted by minor differences in certificate-driven verification functions, use lowercase hostnames for all Cisco ISE nodes that are deployed in a network.

Choose one or more of the following uses:
• Admin: For internode communication and authenticating the administration portal.
• EAP Authentication: For TLS-based EAP authentication.
• RADIUS DTLS: For RADIUS DTLS server authentication.
• Portal: For communicating with all Cisco ISE end-user portals.
• SAML: For verifying that the SAML responses are being received from the correct identity provider.
• pxGrid: For communicating with the pxGrid controller.

Associate different certificates from each node for communicating with the administration portal (Admin usage), the pxGrid controller (pxGrid usage), and for TLS-based EAP authentication (EAP Authentication usage). However, you can associate only one certificate from each node for each of these purposes.

You must always use a new private key for each certificate that you import into Cisco ISE. When you reuse private keys across certificates, application initialization errors may occur due to a Red Hat NSS database limitation.

When a new certificate is imported into the Red Hat NSS database, any existing certificate that has the same private key is overridden. Cisco ISE application initialization is impacted if an admin certificate's private key is overridden.

 

References

 

 

 

 

 

 

 

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents