Installation, Renewal and Troubleshooting of SSL Digital Certificates on Cisco ISE
PDF(27.2 KB) View with Adobe Reader on a variety of devices
ePub(97.2 KB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(82.7 KB) View on Kindle device or Kindle app on multiple devices
Updated:August 3, 2020
This document contains the necessary steps for SSL certificate installation, renewal, and solutions to most common certificate issues observed on an Identity Services Engine. This document provides the recommended steps and checklist of common issues to be verified and addressed before you begin to troubleshoot and call Cisco Technical Support.
These solutions come directly from service requests that the Cisco Technical Support has solved. If your network is live, make sure that you understand the potential impact of the steps you take to address the issues.
Cisco recommends that you have knowledge of these topics:
Identity Service Engine GUI
The information in this document is based on the following software version:
Cisco Identity Service Engine 2.7
The information in this document was created from the devices in a specific lab environment. All of the devices 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.
A certificate is an electronic document that identifies an individual, a server, a company, or other entity and associates that entity with a public key. A self-signed certificate is signed by its own creator. Certificates can be self-signed or digitally signed by an external Certificate Authority (CA). A CA-signed digital certificate is considered an industry standard and more secure.
Certificates are used in a network to provide secure access. Cisco ISE uses certificates for inter-node communication, and for communicating with external servers such as the Syslog server, feed server, and all the end-user portals (guest, sponsor, and personal devices portals). Certificates identify a Cisco ISE node to an endpoint and secure the communication between that endpoint and the Cisco ISE node. Certificates are used for all HTTPS communication and the Extensible Authentication Protocol (EAP) communication.
The following guides explain how to import and replace certificates:
Scenario 1: Unable to replace an expiring Portal Certificate on an ISE node
While binding the new Portal Certificate with the CSR, certificate bind process fails with the error shown below:
Internal error. Ask your ISE administrator to check the logs for more details
Most common reasons for this error are:
- The new certificate has the same subject name as the existing certificate
- Import a renewed certificate which is using the same private key of an existing certificate
Temporarily assign the portal usage to another certificate on the same node
Delete the expiring Portal Certificate
Install the new Portal Certificate and then assign the portal usage
For example, if you wish to temporarily assign the portal usage to an existing certificate with EAP Authentication usage, follow the below steps:
Step 1. Select and Edit the certificate with EAP Authentication usage, add Portal role under Usage and Save
Step 2. Delete the expiring portal certificate
Step 3. Upload the new Portal Certificate without selecting any role (under Usage) and Submit
Step 4. Select and Edit the new Portal Certificate, assign Portal role under Usage and Save
Scenario 2: Cannot generate two CSR for the same ISE node with Multi-Use usage
New CSR creation for the same node with Multi-Use usage fails with the error: Another certificate with the same friendly name already exists. Friendly names must be unique.
CSR Friendly Names are hardcoded for each ISE node so it does not allow creating 2 CSRs for the same node with Multi-Use usage. The use case is on a specific node, there is one CA-signed certificate that is used for Admin and EAP authentication usage and another CA-signed certificate that is used for SAML and Portal usage and both the certificates are going to expire.
In this scenario:
Step 1. Generate first CSR with Multi-Use usage
Step 2. Bind the CA-signed certificate with first CSR and assign the Admin and EAP authentication role
Step 3. Generate second CSR with Multi-Use usage
Step 4. Bind the CA-signed certificate with second CSR and assign SAML and Portal role
Scenario 3: Not able to bind the CA-signed certificate for portal usage or not being able to assign the portal tag to the certificate and getting an error
Binding CA-signed certificate for portal usage throws the error:
There is one or more trusted certificate(s) which is part of the portal system certificate chain or selected with cert based admin auth role with the same subject name but having a different serial number. Import/Update was aborted. For successful import/update, you need to either disable the cart based admin auth role from a duplicate trusted certificate or change the portal role from the system certificate which contains the duplicate trusted certificate in its chain.
Step 1. Check the certificate chain of the CA-signed certificate (for portal usage) and in the Trusted Certificates store, verify if you have any duplicate certificates from the certificate chain. Step 2. Remove the duplicate certificate or uncheck the checkbox Trust for certificate-based admin authentication from the duplicate certificate.
For example, the CA-signed portal certificate has the below certificate chain:
Verify if you have any duplicate certificate for any of the 3 CA certificates in the certificate chain (could be an expired certificate) and remove the duplicate certificate from the Trusted Certificates store.
Scenario 4: Unable to delete the expired default self-signed certificate from the Trusted Certificate Store
Deleting the expired default self-signed certificate from the Trusted Certificate store results in the error: Disable or Delete or Trust Certificate is not allowed since it is being referenced by either in System Certificates AND/OR Secure Syslog Target under Remote Logging Targets.
Verify that the expired default self-signed certificate is not associated with any existing Remote Logging Target. This can be verified under Administration > System > Logging > Remote Logging Targets > Select and Edit SecureSyslogCollector(s)
Verify that the expired default self-signed certificate is not associated with any specific role (usage). this can be verified under Administration > System > Certificates > System Certificates.
If the issue still persists, contact TAC.
Scenario 5: Unable to bind CA signed pxGrid Certificate with the CSR on an ISE node
While binding the new pxGrid Certificate with the CSR, certificate bind process fails with error:
Certificate for pxGrid must contain both client and server authentication in the Extended Key Usage (EKU) extension.
Ensure that the CA-signed pxGrid certificate must have both TLS Web Server Authentication (18.104.22.168.22.214.171.124.1) and TLS Web Client Authentication (126.96.36.199.188.8.131.52.2) extended key usage because it is used for both client and server authentication (to secure communication between the pxGrid client and server)