What are WildCard Certificates? And how do I use them with Cisco’s ISE

HTTPS communication using the ISE certificate:

Every web portal with ISE version 1.1.0 and newer is secured using HTTPS (TLS encrypted HTTP communication).  Figure 2 describes the TLS encrypted process when communicating to the Admin portal.

• Administrative Portal
• Centralized Web Authentication (CWA) Portal
• Sponsor Portal
• Client Provisioning Portal (CPP) & Native Supplicant Provisioning (NSP)
• MyDevices Portal

 

EAP Communication:

Certificates are used with nearly every possible EAP method.  The main examples include:

• EAP-TLS
• PEAP
• EAP-FAST

With tunneled EAP methods such as PEAP and FAST, Transport Layer Security (TLS) is used to secure the credential exchange.  Much like going to an HTTPS web site, the client establishes the connection to the server, which presents its certificate to the client.  If the client trusts the certificate, the TLS tunnel is formed.  The client’s credentials are not sent to the server until after this tunnel is established, thereby ensuring a secure exchange.  In a Secure Access deployment, the client is a supplicant, and the server is an ISE Policy Services node.  Figure 3 describes an example using PEAP.

Why use Wildcard Certificates?

There are a number of reasons to implement wildcard certificates with an ISE deployment.  Ultimately, those who choose to use them, do so to ensure the end-user experience is as seamless as possible, especially given the vast difference and variety of endpoints.

Benefits of Wildcard Certificates

Some examples of benefits of wildcard certificate usage are:

1)     Cost savings.  Certificates signed by a 3^rd-part Certificate Authority can be costly, especially as the number of servers increase.  Wildcard certificates may be used on all nodes of the ISE Deployment (also referred to as the “ISE Cube”).

2)     Operational efficiency.  Wildcard certificates allow all Policy Service Node (PSN) EAP and web services to share the same certificate.  In addition to significant cost savings, certificate administration is also simplified through “create once, apply to many”.

3)     Reduced authentication errors.  Wildcard certificates address issues as seen with Apple iOS devices where client stores trusted certificates within the profile, and does not follow the iOS Keychain where the signing root is trusted.  When an iOS client first communicates to a PSN it will not explicitly trust the PSN certificate, even though a trusted Certificate Authority has signed the certificate.

Using a wildcard certificate, the certificate will be the same across all PSNs, so user will only need to accept certificate once and successive authentications to different PSNs should proceed without error or prompting.

4)     Simplified supplicant configuration.  For example, Microsoft Windows supplicant with PEAP-MSCHAPv2 and server cert trust enabled often requires specification of each server certificate to trust, or user may be prompted to trust each PSN certificate when client connects using a different PSN.  With wildcard certificates, a single server certificate can be trusted rather than individual certificates from each PSN.

Ultimately, wildcard certificates result in an improved user experience.  Less prompting and more seamless connectivity will translate into happier users and increased productivity.

Drawbacks to Wildcard Certificates

There can be a number of benefits using wildcard certificates, but there are also a number of security considerations related to wildcard certificates including:

1)     Loss of auditability and non-repudiation

2)     Increased exposure of the private key

3)     Not as common or as well understood by admins

Although considered less secure than assigning a unique server certificate per ISE node, cost and other operational factors often outweigh the security risk and necessitate the need to offer this as an option to our customers in their ISE deployments. Note, that other security devices like the ASA also support wildcard certificates.

You must always be careful when deploying wildcard certificates. For example if you create a certificate with *.company.local and an attacker is able to recover the private key, that attacker can spoof any server in the company.local domain. Therefore it is considered a best practice to partition the domain space to avoid this type of compromise.

To address this possible issue and to limit the scope of use, wildcard certificates may also be used to secure a specific subdomain of your organization. Just add an asterisk (*) in the subdomain area of the common name where you want to specify the wildcard. For example, if you configure a wildcard certificate for *.ise.company.local, that same certificate may be used to secure any host who’s dns name ends in “.ise.company.local”, such as:

• psn.ise.company.local
• mydevices.ise.company.local
• sponsor.ise.company.local

Wildcard Certificate Compatibility

Wildcard certificates are most commonly constructed with the wildcard listed as the canonical name (CN) of the subject field of the certificate itself, such as the example in Figure 1.  ISE version 1.2 and newer support this manner of construction, however not all endpoint supplicants will support the wildcard in the subject of the certificate.

All Microsoft native supplicants tested (including Windows Mobile) do not support wildcards in the subject of the certificate.  The use of another supplicant, such as Cisco’s AnyConnect Network Access Manager (NAM), will allow the use of wildcard characters in the subject field.  Another option is to use special wildcard certificates like DigiCert’s Wildcard Plus that is designed to work on incompatible devices by including specific sub-domains in the Subject Alternative Name of the certificate.

For more information on Microsoft’s support of wildcard certificates, see here: http://technet.microsoft.com/en-US/cc730460

Making Wildcards Work with all Devices

Although the limitation with Microsoft supplicants may appear to be a deterrent to using wildcard certificates, there are alternative ways to construct the certificate that allow it to work with all devices tested with Secure Access, including the Microsoft native supplicants.

Instead of constructing the subject to include the wildcard values, you may put those wildcard values into the Subject Alternative Name (SAN) field instead.  The SAN field maintains an extension designed for the checking of the domain name, dNSName.  See RFCs 6125 and 2128 for more detail, and a small excerpt from RFC 6125 is displayed in figure 4.

ISE Support for Wildcard Certificates

ISE added support for wildcard certificates in version 1.2.  Prior to version 1.2, ISE will perform verification of any certificates enabled for HTTPS to ensure the CN field matches the host Fully Qualified Domain Name (FQDN) exactly.  If the fields did not match, the certificate could not be used for HTTPS.

This restriction exists because prior to version 1.2, ISE would use that CN value to replace the variable in the url-redirect AV pair string.  For all Centralized Web Authentication (CWA), on-boarding, posture redirection and more, the CN value would be used.

Beginning in ISE version 1.2, the behavior has been modified to use the hostname as it is defined in the underlying operating system configuration of ISE, instead of relying on the CN field.

Constructing the Wildcard Certificate

Since we know we must insert the wildcard value into the Subject Alternative Name (SAN) field of the certificate as a workaround for Microsoft native supplicants, we are left with two main ways to construct the certificate:

Option 1: Leave the canonical name (CN) field of the subject blank and insert the wildcard into the SAN field.

While this appears to work perfectly well with most private Certificate Authorities, such as the Microsoft Active Directory CA, the majority of Public authorities will not allow the creation of a certificate without the CN value.

Figure 5 shows and example of a valid wildcard certificate without the CN field.

Option 2 (Cisco Preferred Best Practice): Use a generic hostname for the CN field of the subject, and insert both the same generic hostname and the wildcard value into the SAN Field.

This method has been successful with the majority of tested public Certificate Authorities, such as Comodo.com and SSL.com.  With these public CA’s the type of certificate to request is the “Unified Communications Certificate” (UCC).

Note:  With both option 1 and 2, the resulting wildcard certificate only needs to be imported into the ISE nodes running Policy Services, it is not required to import the wildcard certificate into the Policy Administration Nodes (PAN) or Monitoring and Troubleshooting (MnT) nodes.

How to Implement Wildcard Certificates

Now that we have reviewed wildcard certificates and their usage with ISE, we will walk through the creation of a wildcard certificate following the best practice of using a generic hostname for the CN field of the subject, and insert both the same generic hostname and the wildcard value into the SAN Field.

There are a few ways to import a wildcard certificate into ISE version 1.2.  This procedure will follow what we expect to be the most common approach, which is to create the Certificate Signing Request (CSR) within the ISE administrative interface and submit that CSR to the signing Certificate Authority (CA).  The resulting signed public key will be bound to the CSR on ISE.

The final private and public key-pair will be exported from the first ISE node, and imported on the other nodes in the deployment.

Let’s Create the Certificate Signing Request (CSR)

From the first ISE node, navigate to the certificates section of the administrative GUI.  For dedicated Policy Services Nodes, the path will be “Administration à Server Certificates”.  If the node is also an administrative node, the path will be “Administration à Certificates à Local Certificates”.

Step 1 Click Add > Generate Certificate Signing Request
Step 2 In the Certificate Subject enter the generic FQDN for the ISE PSNs.
Step 3 Select at least two DNS Names under the Subject Alternative Name (SAN) section

• One of the DNS Names must match the CN= value from Step 2.
• The other DNS Name should be the wildcard value.

Step 4 Ensure the “Allow Wildcard Certificates” check box is selected.
Step 5 Click Submit.   Figure 7 displays a sample CSR.

Export the CSR and Submit it to the Certificate Authority

Now that the CSR has been generated, we need to export it.

Step 1 Navigate to the Certificate Signing Requests screen
Step 2 Highlight the CSR, and click Export
Step 3 Save the CSR to your local machine.  Figure 8 illustrates the exporting of the CSR

Step 4 Open the CSR in your favorite text editor and copy all text from “—–BEGIN CERTIFICATE REQUEST—–“ through “—–END CERTIFICATE REQUEST—–“

Step 5 Paste the contents of the CSR into the certificate request on the chosen CA, such as seen in the following figures.

Step 6 Download the resulting signed certificate

In the case of figure 12, the certificate is just downloaded.  Some CA’s may email you after the certificate is issued, and you will need to download the certificate.  In many cases, the result will be a zip file containing not only your newly issued certificate, but also the public signing certificates of the CA to be added to the ISE trusted certificate store (as seen in figure 13).

Import the Root Certificates to the Certificate Store

Before we bind the newly signed certificate to the CSR on ISE, we want to ensure the signing root certificates exist in the trusted certificate store.

Note:  By performing the actions in this order, we are ensuring that all other nodes in the deployment will trust the new certificate before we bind it.

Reuse the Wildcard Certificate on other ISE nodes

At this point, we have generated a certificate signing request using one of our ISE nodes.  This will use the private key from that ISE node and a new Public Key that has been created with a CN of “psn.ise.local” and SAN dNSName values of “psn.ise.local” and “*.ise.local” (the wildcard).

By binding the new signed certificate to the certificate signing request, we have a brand-new Public & Private key pair on this ISE node.

Our next procedures will be to export that key-pair and import both the private and public keys on all the other Policy Service Nodes, ensuring we have the exact same certificate on all PSNs.

Export the Key Pair

From the first ISE node, navigate to the certificates section of the administrative GUI.  For dedicated Policy Services Nodes, the path will be “Administration à Server Certificates”.  If the node is also an administrative node, the path will be “Administration à Certificates à Local Certificates”.

Step 1 Select the wildcard certificate
Step 2 Click Export
Step 3 Select Export Certificate and Private Key
Step 4 Provide a password that will be used later when importing the certificate key-pair
Step 5 Click Export
Step 6 The key-pair is exported as a zip file, save that zip file to a location that be accessed quickly

Import the Key-Pair on other ISE Nodes

On your local machine, you will need to extract the zip file from procedure 1, so the two certificate files may be accessed.

Then, on one of the remaining ISE nodes, navigate to the certificates section of the administrative GUI.  For dedicated Policy Services Nodes, the path will be “Administration à Server Certificates”.  If the node is also an administrative node, the path will be “Administration à Certificates à Local Certificates”.

Step 1 Click Add à Import Server Certificate
Step 2 Click Browse for the Certificate File, and locate the certificate file from the zip file with the .pem extension (for example “CNisaaaSANhasWildcard.pem”)
Step 3 Click Browse for the Private Key File, and locate the private key file from the zip file with the .pvk extension (for example “CNisaaaSANhasWildcard.pvk”)
Step 4 Provide the password you created in Procedure 1, Step 4
Step 5 Ensure the “Allow Wildcard Certificates” check box is enabled
Step 6 Choose the protocol for this certificate to be bound to: EAP, HTTPS or both
Step 7 Click Submit
Step 8 Repeat steps 2 through 7 for all remaining ISE Nodes

Testing Results:

This section is providing a sampling of the clients that have been tested and are proven to work with the wildcard certificates.  Both Option 1 and Option 2 from the section of this document labeled “Constructing the Wildcard Certificate” were tested.   This is a sampling only, as many more devices have been tested and proven to work.

Device	PEAP	Onboarding	EAP-TLS	Device Details
Cisco Cius	Y	NA	NA	Android 2.2.2 / Kernel 2.6.31.6-mrst
Galaxy Player	Y	Y	Y	Android 2.3.5 / Kernel 2.6.35.7
Galaxy Tab 10.1	Y	Y	Y	Android 4.0.4 / Kernel 3.1.10
Galaxy Tab 2 – 7”	Y	Y	Y	Android 4.1.1 / Kernel 3.0.31
Acer A110 Tab	Y	Y	Y	Android 4.1.2 / Kernel 3.1.10
Google Nexus 7	Y	Y	Y	Android 4.2.2 / Kernel 3.1.10-g05b777c
Galaxy Note 8.0	Y	Y	Y	Android 4.1.2 / Kernel 3.0.31
iPod Touch 1st Gen	Y	NA	NA	iOS 3.1.3 (7E18)
iPad1	Y	Y	Y	iOS 5.1.1 (9B206)
iPad2	Y	Y	Y	iOS 6.0.1 (10A523)
iPad Mini	Y	Y	Y	iOS 6.1.2 (10B146)
iPhone 4	Y	Y	Y	iOS 6.0 (10A403)
iPhone 5	Y	Y	Y	iOS 6.1.3 (10B329)
Nook HD	Y	Y	Y	Nook 2.1.0
MacBook Pro	Y	Y	Y	OSX 10.7.5
MacBook Air	Y	Y	Y	OSX 10.8.2 (12C30006)
Kindle Fire HD	Y	NA	NA	Version 7.3.0_user_3013320
Microsoft Surface	Y	Y	Y	WindowsRT
Windows7 Native	Y	Y	Y	Windows7 Ultimate ServicePack1
WindowsXP Native	Y	Y	Y	WindowsXP SP3
Windows8 Native	Y	Y	Y	Windows 8 Native Supplicant