Validating Certificate Extensions… Why does it matter? And how can this simple step significantly increase the overall security of your Cisco ISE deployment?
When we talk about securing Cisco ISE, most people immediately think about policies, authentication protocols, Active Directory integrations, or network access controls. But there’s a highly critical—and often overlooked—piece of the puzzle: Certificate Extensions. Many administrators validate only the certificate’s CN/FQDN or its expiration date. But the real security controls live inside the extensions.
What Are Certificate Extensions?
Extensions define how a certificate is allowed to be used—and what it must never be used for. Examples include:
Extended Key Usage (EKU) determines the purpose of the certificate:
- Client Authentication
- Server Authentication
- OCSP Signing
- Email Protection
- …and more
Key Usage defines which cryptographic operations are permitted:
- Digital Signature
- Key Encipherment
- Certificate Signing
- …etc.
Basic Constraints indicates whether the certificate is a CA or an end-entity certificate.
Keep in mind that, these fields are not decorative—they are a security boundary.
Why Is This So Important in Cisco ISE?
Because certificates are at the core of almost everything ISE does:
- EAP-based Authentication with tunnel-based setup (PEAP, EAP-TLS, TEAP)
- RADIUS over TLS
- ISE Admin GUI access
- Node-to-node communication inside the ISE cluster
- pxGrid
- Any TLS-based integration (MDM, SAML, etc.)
If a certificate contains incorrect or missing extensions, best-case scenario is “client authentications fail” and the worst case will be “a certificate can be misused for the wrong purpose; creating a serious security flaw”. For example:
- A certificate without Server Authentication EKU cannot be used for PxGrid or a certificate missing Client Authentication EKU will fail EAP-TLS authentication.
- A certificate that incorrectly has Certificate Signing ability can unintentionally act like a CA certificate—a major security risk. In other words, a certificate that incorrectly includes the “Certificate Signing” ability can behave like a CA certificate, even though it was never meant to.
Fortunately, Cisco ISE can be configured to validate any certificates you import into the Trusted Certificate store to have CA flag. Using this flag, ISE ensures that the certificate is issued by a CA and can be used to validate other certificates.
As you can see below, in Microsoft AD CS, CA certs has this flag by default:
In nutshell, by validating extensions, you:
- Prevent certificates from being used outside their intended purpose
- Ensure EAP and TLS behave correctly and securely
- Protect against misconfiguration that can expose your ISE deployment
- Maintain compliance with industry standards
It definitely good to always tick that box when importing the cert.
There is another check you can perform for the ISE server certificates - however, be careful when disabling this checkbox (RFC 5280 strict compliance) , because it can prevent some vendor devices from authenticating, because they interpret the standards (e.g. IEEE 802.1AR) and this flies in the face of the RFC. That's my interpretation and hard learned experience anyway.
