A wildcard certificate is one that uses a wildcard notation (an asterisk and period before the domain name) and allows the certificate to be shared across multiple hosts in an organization. An example CN value for a wildcard certificate’s Subject Name would look like the following: *.company.local
If you configure a Wildcard Certificate to use *.company.local, that same certificate may be used to secure any host whose dns name ends in “.company.local”, such as:
Figure 1 shows an example of using a wildcard certificate to secure a web site (specifically, the web interface of an ISE node). Notice in figure 1 that the URL entered into the browser address bar is “atw-lab-ise01.woland.com”, but the certificate’s common name is “*.woland.com”.
Wildcard certificates secure communications in the same manner as a regular certificate, and requests are processed using the same validation methods.
Where are Certificates Used with ISE?
Certificates are employed often in a network implementing Secure Access. The certificates are used to identify the Identity Services Engine (ISE) to an endpoint as well as to secure the communication between that endpoint and the ISE node. The certificate is used for all HTTPS communication as well as the Extensible Authentication Protocol (EAP) communication.
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
Certificates are used with nearly every possible EAP method. The main examples include:
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 3rd-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:
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.
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.
This article is published as part of the IDG Contributor Network. Want to Join?