I just got back from a few weeks traveling around Europe, presenting at Cisco Live Europe, and meeting with customers & 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 are numerous occasions where you will want to reach ISE with a DNS name that is not the exact-same as it’s hostname. If you’ve ever tried to reach an https:// web site by ip address, you most likely have experienced the web browser arguing that the certificate name is mis-matched, the browser requires you to accept the warning in order to proceed. 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 & create guest accounts. Obviously telling an employee to connect to this URL will be very tedious, and a more friendly name is needed.
- MyDevices Portal: https://ISE:8443/mydevices/ – This portal is for Employees of your company to login & manage their personal devices which they have/can register to provide network access to those devices. Obviously telling an employee to connect to this URL will be very tedious, and a more friendly name is 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: http://blog.woland.com/images/Blog3/02-FriendlyNames.png
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 is 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 it’s 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 & 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, however it did not work for us. We did have success with using OpenSSL on Windows & Linux. I am going to focus on using the Windows implementation of OpenSSL for this blog entry. You can download OpenSSL from here:http://gnuwin32.sourceforge.net/packages/openssl.htm
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 be using 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 & Private Certificate from ISE. The default format is a zip file that contains both the public & private key. In this case: “atwcpise01iselocalatwcpis.zip”.
Step 3: Extract the zip file & copy the .pem & .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: http://www.phildev.net/ssl/opensslconf.html
The contents of my openssl.cnf file:
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 -> 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.