Introduction
Digital certificates play a big part in most advanced security systems and Cisco ISE is no exception. Even the most basic features will make you deal with certificates. The goal of this post is to highlight some tips and tricks when it comes to picking certificates for your ISE deployment.
Certificates can be obtained mainly from these three sources: self-signing, internal CA/PKI (usually Active Directory CA), or from a trusted third-party CA (such as GeoTrust, DigiCert, GlobalSign, and so on). Always avoid self-signed certificates and instead use, at a minimum, certificates from your internal CA or better yet, buy them from a trusted third-party certificate authority.
There are many different types of certificates and most of them can be used with ISE one way or the other. Based on the size of your deployment and the features you are planning to use, there are economic benefits to picking one type of certificate over the other if you are going to buy certificates from a trusted third-party CA. Commonly, it is cheaper overall to buy an expensive certificate that can be used for many services on many ISE nodes compared to buying cheaper individual certificates for every node.
I am no expert at certificates, but I like to divide certificates used for ISE into the following three types:
Regular SSL certificate (for single ISE node usage, one certificate for all services)
Wildcard SSL certificate (for distributed ISE deployments, some services)
UCC/SAN certificate (for distributed ISE deployments, one certificate for all services)
Regular SSL Certificates
Regular SSL certificates are pretty straightforward. Regardless of if you're using an internal CA or a trusted third-party CA, this kind of certificate is simply made to be used for a specific website (or ISE node). It could for example be "www.google.com" or "ise01.domain.com". In the world of ISE, this certificate would be bound to a single ISE node, making it a bit more bothersome to work with once your ISE deployment starts to grow. You can use this type of certificate for all use-cases on ISE (admin portal/node trust, guest/device/BYOD portals, EAP authentication) but as soon as you deploy the next node you will need to issue another similar certificate but in the name of "ise02.domain.com" instead, for example. The "upside" of this kind of certificate is that it is considered the most secure because, in the event of a certificate breach (like the private key being leaked), only one of your certificates would be considered insecure and not suitable for use anymore.
Two important fields of a "Regular SSL" certificate.
Wildcard Certificates
Wildcard certificates have a pretty inconvenient spot in an ISE deployment because they work great for some features and not so good for others. A lot of organizations already have a Wildcard certificate (issued by a trusted third-party CA) available because it's common to use for different websites owned by the organization. They will ask you to use it instead of buying a new one. This is why you shouldn't use it:
Windows OS does not allow Wildcard Certificates to be used for EAP authentication. If a Windows PC tries to connect to a wireless network where the authenticating server (like ISE) is presenting itself using a Wildcard certificate, in which the CommonName is for example *.domain.com, Windows will simply close the network connection.
Wildcard certificates can however be used for all types of portals and trust between all ISE nodes in a deployment. Depending on your deployment this could be good enough for you. If you are only enabling 802.1X on corporate assets that are joined to your AD domain, you could simply issue regular SSL certificates or a UCC/SAN certificate (see below) to be used for the EAP authentication. This way all your guest portals etc. will still look great for those guests because certificates issued from the trusted third-party CA would be shown to them, which is trusted by most operating systems by default.
Two important fields of a "Wildcard" certificate.
UCC/SAN Certificates
UCC/SAN certificates are where it gets interesting though. This type of certificate can be used to secure multiple nodes by including a greater amount of node names (or domain names) using the Subject Alternative Name (SAN) fields in the certificate. The CommonName could be set to anything within the domain it's a part of, like "ise.domain.com". For use with ISE, do not put the Wildcard in the CommonName. In the SAN fields we could fill in all of our nodes directly by their (ise01.domain.com, ise02.domain.com) or we could go an even better route by putting in the Wildcard (*.domain.com) into the SAN. In this case, we would also need to put in the CommonName as one of the SAN fields. A certificate structured this way can be used for ALL nodes in an ISE deployment and for ALL services that exist. It is in short the ultimate certificate for ISE.
Two important fields of a "UCC/SAN" certificate.
Final Notes
So to sum up, why are we using UCC/SAN certificates?
- Windows OS does not allow Wildcard Certificates to be used for EAP authentication. If a Windows PC tries to connect to a wireless network where the authenticating server (like ISE) is presenting itself using a Wildcard certificate, for example, *.domain.com, Windows will simply close the network connection. Using wildcard in the SAN field is okay though!
- Improved user experience. This is mostly related to ISE deployments using certificate-based Bring-Your-Own-Device (BYOD). On some devices (like Apple devices) when you are connecting for the first time you are asked to trust the ISE node you are connected to during the on-boarding process, sometimes even if the ISE node has a certificate issued by a trust third-party CA. You will have to choose to trust the certificate during the process but it starts getting interesting if your BYOD device happens to talk to some other ISE Policy Node when it's connecting to the actual network. If you are not using UCC/SAN certificates, the Apple device might show a warning to the user because it has not imported that particular ISE nodes certificate into its trusted store. With UCC/SAN you wouldn't have this problem since the same certificate is used for all nodes. While most devices should trust the new certificate since it is already trusting the root and intermediate certificate, there have been some weird cases particularly on iOS devices where it wants to import the actual ISE node's certificate into its trusted certificate store.
- Ease of management: you can issue the certificate once and use it for all your ISE nodes, for all use-cases! Be it guest portals, EAP authentication, or distributed deployment authentication, you will only have to manage one certificate.
All in all, even if you are using your own Certificate Authority it is very convenient to use the UCC/SAN style for your certificate.