How to hack the certificate for a Cisco Identity Services Engine node

I just got back from a few weeks traveling around Europe, presenting at Cisco Live Europe, and meeting with customers and partners. It is obvious that this blog is very much needed for a lot of the deployments that we discussed, so as promised in the Load Balancing Blog, I am following up with a blog on how to "hack" the certificate for a Cisco Identity Services Engine (ISE) node, so that we may include entries in the Subject Alternative Name (SAN) field.

Why do we need to do this? 

There will be plenty of occasions in which you’ll want to reach ISE with a DNS name that is not the exact same as its hostname. If you’ve ever tried to reach an https:// website by IP address, you most likely have experienced the web browser arguing that the certificate name is mismatched and that the browser requires you to accept the warning in order to proceed. An example is shown below.

Cisco ISE has a few different portals that you may connect to:

• Sponsor Portal: https://ISE:8443/sponsorportal/. This portal is for employees of your company to login and create guest accounts. Obviously, telling an employee to connect to this URL will be very tedious, and a friendlier name will be needed.
• MyDevices Portal: https://ISE:8443/mydevices/. This portal is for employees of your company to login and manage the personal devices they are allowed to register for network access. Obviously, telling an employee to connect to this URL will be very tedious, so again, a friendlier name will be needed.

So, ISE can use HTTP host-headers to use friendly names, and redirect traffic destined to that friendly name to the correct URL/port. This is set under Administration/Web Portal Management/Settings/General/Ports.

If you were to use "hotspot.CompanyX.com," it would not match what was in ISE’s certificate for the web portals. The certificate will only match the actual hostname (such as: atw-cp-ise04.cisco.com). This results in a certificate mismatch error, and the user experience will be less than desirable.

How do I fix this?

Standard X.509 certificates provide fields to allow a certificate to match more than one URL. This is known as the Subject Alternative Name field. This certificate field may be populated with other DNS names, other IP Addresses, and more.

Using the Subject Alternative Name field will prevent the certificate errors. However, Cisco ISE does not provide the ability to populate these fields when generating a Certificate Signing Request (CSR) to be sent to the Certificate Authority for signing.

What is the “Hack”?

While the ISE user interface may not provide the ability to populate the SAN field with its own Certificate Signing Request (CSR), it is still just an X.509 certificate, which is a standard. Why don’t we just export the public and private certificate from ISE and use OpenSSL to generate the CSR instead?

(Note: We have tried this with MAC-OS, since OpenSSL is built into it, but it did not work for us. We did have success with using OpenSSL on Windows and Linux. I am going to focus on using the Windows implementation of OpenSSL for this blog entry. You can download OpenSSL from here)

Let’s Begin!

Step 1: To begin, you should generate a new self-signed certificate for the ISE node. Set the key length to be your desired key length (2048 for example). 

Afterwards, you can reconnect to ISE and it will use the new certificate. Here I am viewing the new certificate, just to show you some fields. There is no Subject Alternative Name field, and you can see below that the subject is CN=atw-cp-ise01.ise.local (the fqdn of the ISE node). 

Step 2: Export the Public and Private Certificate from ISE. The default format is a .zip file that contains both the public and private keys. In this case: “atwcpise01iselocalatwcpis.zip”

Step 3: Extract the zip file and copy the .pem and .pvk files to the OpenSSL binary directory (C:\Program Files (x86)\GnuWin32\bin). 

Step 4: Create a customized configuration file for OpenSSL Certificate Signing Requests named openssl.cnf. A really nice walk through of the openssl.cnf file can be found here.

Step 5: Now that your openssl.cnf file is ready with your certificate customizations, you will use OpenSSL to create a custom CSR file using the following command:

openssl req -key [PVK_file] -new -out [CSR_filename] –config [your_openssl.cnf_file]

Step 6: Request a new Certificate from the CA. I used a Microsoft CA in this example.

Step 7: Choose an Advanced certificate Request

Step 8: Paste in the contents of the certificate request file generated in Step 5. Ensure the Certificate Template type is "Web Server."

Step 9: Download the certificate in Base 64 (PEM) format. For best results, do not use DER format, and do not use the certificate chain.

Step 10: Under Local Certificates, select Add and then Import Local Server Certificate

Step 11: Import the Original Private key and new CA signed public key into ISE.

• For Certificate File, choose the new CA signed certificate that you just downloaded from the CA. 
• For the Private Key File, select the original private key that you exported.

Step 12: Your ISE node will now be using the new CA signed certificate, with the Subject Alternative Names in it.