Anyone operating a PKI or an application whose functionality requires one, can attest to the ever-increasing amount of time spent keeping certificates up-to-date and compliant with the contemporary cryptography standards. When certificates expire, things break. When cryptography standards evolve, things break. For these reasons, the typical network/systems operator may find it easy to take a disdainful approach when it comes to operating a PKI and managing certificate lifecycle.
<steps onto soapbox>
While it is burdensome (and frankly a pain in the butt), we should take time to appreciate PKI/cryptography, as it has changed all our lives for the better by enabling a secure communication that would otherwise be fraught with surveillance, a lack of trust, and an always-potential invasion of privacy.
Author Steven Levy says it best in his book titled “Crypto: How the Code Rebels Beat the Government – Saving Privacy in the Digital Age” when he writes:
“The telegraph, telephone, radio, and especially the computer have put everyone on the globe within earshot – at the price of our privacy. It may feel like we are performing an intimate act when, sequestered in our rooms and cubicles, we casually use our cell phones and computers to transmit our thoughts, confidences, business plans, and even our money. But clever eavesdroppers, and sometimes not-so-clever ones, can hear it all. We think we’re whispering, but we’re really broadcasting.”
The book goes on to describe cryptography (and PKI) as the “antidote”, how that antidote was born, the people who fought for its liberation, and how it has evolved. It is a great read, highly recommended!
We take it for granted, but we are truly standing on the shoulders of giants every time we use secure communications.
<steps off the soapbox>
How Does ISE Use Certificates?
Many, many ways. The following table summarizes the different ways in which ISE uses its identity certificates, meaning the certificates issued to the ISE nodes themselves.
Note! This blog entry is not meant to cover client-side certificate interactions with ISE (ISE BYOD client certificate issuance, EAP-TLS client certificates, etc.)!
How Does (or perhaps How Should) ISE Obtain These Certificates?
It depends. Case by case considerations will always exist. Some of these are listed below.
How many nodes will the deployment scale to (should wildcards be considered)?
Are the ISE nodes deployed on a dedicated sub-domain (making wildcards more viable)?
Does the customer have an internal PKI (some usages do not have a public CA requirement)?
Is the DNS domain of the ISE node FQDN on an internal domain name (I hope not, but it happens)?
Are all the endpoints managed (do we control the CA trust store on them)?
In the absence of deployment specific information that could optimize our certificate design, the below table lays out a certificate design that would work for most deployments.
Some justification for the above certificate design
Admin certificate does not need to be publicly trusted as only managed endpoints/systems will “see” it, so it is assumed you have control over those endpoints/systems certificate trust store. It is set to one year validity due to major browsers rigid requirements on certificate validity period for gTLD domain names (which most ISE deployments use). RADIUS DTLS was added as a usage here as it should be FQDN matched per ISE node, so attaching it onto the admin certificate since we otherwise have the same requirements. EAP certificate does not need to be publicly signed either and we could have attached this usage to the admin certificate as well, but I lean towards issuing these for longer durations and sharing a single certificate across multiple PSN’s as to limit 802.1x supplicant provisioning issues that can occur at EAP certificate renewal time. Portal certificates most popular use case is for Central Web Authentication (CWA), so it will be presented to unmanaged endpoints and should be signed by a public CA. pxGrid certificates can be issued by the ISE internal CA for ease of use. ISE internal CA will issue this with a default lifetime of 5 years. SAML certificate is generally OK to be self-signed, but I try to avoid that when it is easy enough to do so by having your internal CA issue the certificate. ISE Messaging Service is one that must be issued by the ISE internal CA chain, so that’s easy enough as there isn’t another option!
What are the effects of renewing the various certificates?
Depending upon the usage assigned to the certificate, replacing/renewing it will have different implications. The table below gives you a breakdown of the implications.
What happens if I fail to renew a certificate?
It happens. ISE has some great built-in alarms to notify you in advance (up to 90 days in advance). If you do happen to miss these notifications, don’t worry because your users will let you know that they cannot access the network! ;)
Let me know in the comments if there is any topic of particular interest to you, and we’ll see about making that happen in the next installment! Thanks for reading!
As always if you have any questions on getting Cisco's ISE set up for you and your business and would like to schedule a free consultation with us, please reach out to us at firstname.lastname@example.org and we’ll be happy to help!
Want the answers to the most asked questions about ISE? Check out our video below!
Dominic Zeni, LookingPoint Consulting Services SME - CCIE #26686