EAP-TLS eliminates the password attack surface from 802.1X entirely. There is no credential to phish, brute-force, or replay. The authentication proof is possession of a private key corresponding to a certificate issued and signed by a trusted CA. For a regulated environment — healthcare, finance, government — EAP-TLS is the appropriate authentication method for wired 802.1X. For environments without an established PKI, PEAP-MSCHAPv2 is the more practical starting point; see [Article 10: Configuring PEAP Authentication with Cisco ISE and IOS XE].
This article assumes [Article 8: Basic 802.1X Port Configuration on Cisco IOS XE Switches] and [Article 9: Configuring Cisco ISE as a RADIUS Server for 802.1X] are complete. The focus here is the certificate infrastructure and ISE policy specific to EAP-TLS.
PKI Prerequisites
EAP-TLS requires:
- A CA hierarchy — at minimum, a root CA and an issuing CA. The root CA certificate must be trusted by both ISE and all supplicants. The issuing CA signs both the ISE server certificate and the client certificates.
- ISE server certificate — an SSL/TLS certificate issued by your internal CA, bound to the EAP Authentication role on ISE. The same certificate used for PEAP works for EAP-TLS.
- Client certificates — one certificate per endpoint, with the correct Extended Key Usage (EKU) extensions. Enrolled via Active Directory Certificate Services (ADCS) autoenrollment, SCEP, or a manual process.
Certificate Requirements for Client Certificates
For ISE to accept a client certificate for EAP-TLS authentication:
Key Usage: Digital Signature
Extended Key Usage: Client Authentication (OID 1.3.6.1.5.5.7.3.2)
Subject: CN=LAPTOP01.corp.local (or the username)
Subject Alternative Name (SAN):
DNS: LAPTOP01.corp.local
UPN: LAPTOP01$@corp.local (for machine certificates)
The SAN User Principal Name (UPN) is critical for ISE's AD lookup. ISE uses the UPN from the client certificate to look up the computer or user account in Active Directory when the Authorization Policy references AD attributes. Without the UPN SAN, ISE cannot resolve the certificate to an AD identity.
Step 1: Import the Internal CA Certificate into ISE
ISE must trust the CA that issued the client certificates. Import the root and intermediate CA certificates:
Navigation: Administration > Certificates > Trusted Certificates > Import
For Root CA:
CA Certificate: [root-ca.pem]
Trust for: Trust for authentication within ISE
Trust for client authentication and Syslog
Trust for certificate based admin authentication
For Issuing CA:
CA Certificate: [issuing-ca.pem]
Trust for: Trust for authentication within ISE
Trust for client authentication and Syslog
Both the root CA and issuing CA must be imported if you are using a two-tier PKI. ISE validates the full certificate chain from the client certificate up to the trusted root. A missing intermediate CA causes a chain validation failure even if the root is trusted.
After import, verify under Administration > Certificates > Trusted Certificates that both CAs appear with Trust for Client Authentication checked. This is the flag that enables ISE to use these CAs when validating EAP-TLS client certificates.
Step 2: ISE Server Certificate for EAP-TLS
The same ISE server certificate used for PEAP serves EAP-TLS. If you have not already configured this, follow the steps in [Article 10: Configuring PEAP Authentication with Cisco ISE and IOS XE] — Step 1.
For EAP-TLS, the server certificate has an additional role: the supplicant validates the ISE certificate during the TLS handshake. In EAP-TLS, both sides validate each other's certificates. The client certificate is sent by the supplicant and validated by ISE; the server certificate is sent by ISE and validated by the supplicant.
Verify the ISE EAP certificate is correctly bound:
Navigation: Administration > Certificates > System Certificates
Certificate: ise-psn01.corp.local
Issued By: corp-issuing-ca.corp.local
Valid To: 2028-03-19
Used by: EAP Authentication, RADIUS DTLS
Step 3: Create a Certificate Authentication Profile
The Certificate Authentication Profile (CAP) tells ISE how to extract the authenticating identity from the client certificate and optionally how to look it up in AD.
Navigation: Administration > Identity Management > External Identity Sources > Certificate Authentication Profile > Add
Name: EAP-TLS_Machine_Auth
Description: Machine certificate authentication for EAP-TLS
Certificate Attribute used as Principal Username:
Selected: Subject Alternative Name - Other Name (UPN)
Alternate: Subject - Common Name
Match Client Certificate Against Certificate Authentication Profile:
No Certificate Revocation Check: Unchecked
OCSP: Checked (if OCSP responder available)
CRL: Checked (if CRL is published and accessible)
If Identity Cannot be Determined: Reject
Binary Certificate Comparison Against:
[Leave unchecked unless mapping certs to AD accounts by binary comparison]
Subject Alternative Name - Other Name (UPN) — ISE extracts the UPN from the certificate's SAN field and uses it as the username for AD lookup. For machine certificates, the UPN is LAPTOP01$@corp.local. ISE can look this up in AD to retrieve group memberships for authorization policy evaluation.
OCSP / CRL revocation check — production deployments should enable certificate revocation checking. If a device is lost or compromised and its certificate is revoked, EAP-TLS authentication fails at the revocation check stage and the device cannot access the network. This is the key security advantage of EAP-TLS over PEAP — revocation enforcement.
To configure OCSP, the OCSP responder URL must be reachable from ISE. Configure it under Administration > System > Certificates > OCSP Client Profile. If OCSP is not available, configure CRL: ISE downloads and caches the CRL from the CDP (CRL Distribution Point) URL in the client certificate.
Step 4: Allowed Protocols — Enable EAP-TLS
Navigation: Policy > Policy Elements > Results > Authentication > Allowed Protocols > PEAP_EAP-TLS_Allowed
Allow EAP-TLS: Yes
Accept client certificates: Yes
Enable EAP-TLS session resumption: Yes
EAP-TLS session timeout: 7200 (2 hours)
Enable EAP-TLS session resumption — allows ISE to cache the TLS session state after a successful EAP-TLS authentication. On reauthentication (or failover to a standby PSN), the supplicant and ISE resume the session using the cached state, skipping the full certificate exchange and TLS handshake. This reduces reauthentication overhead significantly in large deployments.
Step 5: ISE Authentication Policy for EAP-TLS
Navigation: Policy > Policy Sets > Default > Authentication Policy
Rule Name: Wired_EAP-TLS_Machine
Priority: 1
Conditions:
- Wired_802.1X
- AND: Network_Access:EapAuthentication EQUALS EAP_TLS
Use (Allowed Protocols): PEAP_EAP-TLS_Allowed
Use (Identity Source): EAP-TLS_Machine_Auth (Certificate Authentication Profile from Step 3)
Options:
If user not found: Reject
If process failed: Drop
Using the Certificate Authentication Profile as the identity source — not Active Directory directly — is the correct configuration. The CAP extracts the identity from the certificate, ISE uses that identity to look up the account in AD (if configured in the CAP), and then the authorization policy can reference AD attributes like group membership.
The Network_Access:EapAuthentication EQUALS EAP_TLS condition pins this authentication rule to EAP-TLS sessions only. Without this condition, a PEAP session would also match the Wired_802.1X condition and might inadvertently use the CAP as its identity source.
Step 6: ISE Authorization Policy for EAP-TLS
Navigation: Policy > Policy Sets > Default > Authorization Policy
Rule Name: EAP-TLS_Domain_Computer
Priority: 1
Conditions:
- Network_Access:EapAuthentication EQUALS EAP_TLS
- AND: Certificate:Subject-Alternative-Name-UPN CONTAINS corp.local
- AND: AD:ExternalGroups EQUALS corp.local/Groups/Domain Computers
Authorization Profile: VLAN10_Corp_Data
Rule Name: EAP-TLS_IT_Staff
Priority: 2
Conditions:
- Network_Access:EapAuthentication EQUALS EAP_TLS
- AND: AD:ExternalGroups EQUALS corp.local/Groups/IT-Staff
Authorization Profile: VLAN10_Corp_Data
Rule Name: EAP-TLS_Unknown
Priority: Last before Default
Conditions:
- Network_Access:EapAuthentication EQUALS EAP_TLS
Authorization Profile: DenyAccess
The condition Certificate:Subject-Alternative-Name-UPN CONTAINS corp.local filters out certificates from external or unknown CAs whose UPN may not belong to your domain. Even if ISE trusts a CA whose certificates have UPNs from a different domain, this condition prevents those certificates from matching your production authorization rules.
The AD:ExternalGroups EQUALS corp.local/Groups/Domain Computers condition ensures only managed endpoints — those with accounts in Active Directory's Domain Computers group — receive data VLAN access. Endpoints with valid certificates but no corresponding AD computer account fall to the EAP-TLS_Unknown rule and are denied.
Step 7: Client Certificate Enrollment
ADCS Autoenrollment (Recommended for Domain Computers)
Active Directory Certificate Services (ADCS) with autoenrollment is the standard method for deploying client certificates to domain-joined Windows computers.
On the ADCS server — create a Computer Certificate Template:
- Open Certification Authority console
- Right-click Certificate Templates > Manage
- Duplicate the Computer template
Configure the duplicate template:
Template Name: Corp-Computer-8021X
Display Name: Corp Computer 802.1X Authentication
Validity Period: 1 year
Renewal Period: 6 weeks
Subject Name tab:
Build from Active Directory information: Yes
Subject name format: Common Name
Include e-mail name: No
Include DNS name: Yes
Include UPN: Yes (critical for ISE AD lookup)
Extensions tab:
Application Policies (EKU):
Client Authentication: Yes (required)
Server Authentication: No (remove if present on base template)
Security tab:
Domain Computers: Allow Autoenroll
Domain Computers: Allow Read
Domain Computers: Allow Enroll
Publish the template and configure autoenrollment via Group Policy:
Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment
Configuration Model: Enabled
Renew expired certificates: Checked
Update certificates that use templates: Checked
Remove revoked certificates: Checked
After Group Policy applies and the computer runs gpupdate /force, the Windows certificate autoenrollment process requests a certificate from ADCS and stores it in the Local Computer > Personal certificate store.
Verifying Client Certificate Enrollment
On the Windows endpoint:
Open certlm.msc (Local Computer certificate store)
Navigate to Personal > Certificates
The computer certificate should appear with:
- Issued To: LAPTOP01.corp.local
- Issued By: corp-issuing-ca.corp.local
- Intended Purposes: Client Authentication
- Subject Alternative Name: DNS=LAPTOP01.corp.local, UPN=LAPTOP01$@corp.local
Step 8: Windows Supplicant Configuration for EAP-TLS
Via Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Wired Network (IEEE 802.3) Policies
Authentication Method: Microsoft: Smart Card or other certificate
Authentication Mode: Computer authentication
Certificate settings:
Use a certificate on this computer: Yes
Use simple certificate selection: Yes
Validate server certificate: Yes
Trusted Root CAs: [Internal Root CA]
Connect to servers: ise-psn01.corp.local
Use different user name for connection: No (use certificate's Subject or SAN)
Use a certificate on this computer — directs the supplicant to use a certificate from the machine's certificate store rather than the user's store. For machine authentication (which is the norm for 802.1X port access), this is correct. The supplicant selects the most recently issued certificate with Client Authentication EKU in the Local Computer > Personal store.
Validate server certificate — required in production. The supplicant verifies ISE's certificate against the trusted CA list before proceeding with the TLS handshake. This prevents RADIUS impersonation attacks.
Verifying EAP-TLS Authentication
On the Switch
C9300# show authentication sessions interface GigabitEthernet1/0/1 details
Interface: GigabitEthernet1/0/1
IIF-ID: 0x2F6C8D4E
MAC Address: a4b1.e9f0.3c22
IPv4 Address: 10.0.10.105
User-Name: LAPTOP01.corp.local
Status: Authorized
Domain: DATA
Oper host mode: multi-auth
Session timeout: 36000s (server), Remaining: 35604s
Common Session ID: 0A006301000001B5E3E45F20
Server Policies:
Vlan Group: Vlan: 10
ACS ACL: xACSACLx-IP-PERMIT_CORP_ACCESS-5f3a2b1c
Method status list:
Method State
dot1x Authc Success
User-Name: LAPTOP01.corp.local — ISE extracted this from the certificate's CN or SAN and returned it in the RADIUS Access-Accept as the User-Name attribute. The switch displays it here.
On ISE — Live Logs
Navigation: Operations > RADIUS > Live Logs
Status: Authentication Succeeded
Username: LAPTOP01.corp.local
MAC Address: A4:B1:E9:F0:3C:22
NAS-IP: 10.0.99.1
Auth Policy: Wired_EAP-TLS_Machine
Authz Policy: EAP-TLS_Domain_Computer
Authz Profile: VLAN10_Corp_Data
EAP Authentication: EAP-TLS
Certificate Subject: CN=LAPTOP01.corp.local
Certificate Issuer: CN=corp-issuing-ca.corp.local
AD Groups: corp.local/Groups/Domain Computers
EAP Authentication: EAP-TLS — confirms EAP-TLS is in use (not PEAP). The Certificate Subject and Certificate Issuer fields confirm which certificate the client presented. The AD Groups field confirms ISE resolved the UPN from the certificate to the correct AD account and retrieved group memberships.
EAP-TLS Session Resumption Behavior
With session resumption enabled, the second authentication (and all reauthentications within the session timeout window) skip the certificate exchange:
C9300# debug dot1x events
*Mar 19 14:55:22.441: DOT1X-EV:GigabitEthernet1/0/1:Sending EAP-Request Identity
*Mar 19 14:55:22.509: DOT1X-EV:GigabitEthernet1/0/1:Received EAP-Response Identity
*Mar 19 14:55:22.511: DOT1X-EV:RADIUS Sending Access-Request for LAPTOP01.corp.local
*Mar 19 14:55:22.598: DOT1X-EV:RADIUS Received Access-Accept (session resumed)
*Mar 19 14:55:22.599: DOT1X-EV:GigabitEthernet1/0/1:Sending EAP-Success
The entire reauthentication completes in under 200ms when session resumption is active, versus 1-3 seconds for a full EAP-TLS handshake. This is the operational benefit of the eap-tls session timeout setting in Allowed Protocols.
Troubleshooting
Symptom: ISE Live Logs show "12514 EAP-TLS failed SSL/TLS handshake because of an unknown CA in the client certificates chain."
Cause: ISE does not trust the CA that issued the client certificate. The issuing CA or root CA certificate is not imported into ISE's Trusted Certificates store with "Trust for client authentication" enabled.
Fix: Navigate to Administration > Certificates > Trusted Certificates and verify both the root CA and issuing CA are listed and have the Trust for client authentication flag enabled. If the certificate was issued by an intermediate CA, that intermediate CA certificate must also be imported — ISE does not automatically fetch intermediate CAs from the client's certificate chain (unlike browsers). Import the full CA chain.
Symptom: Certificate authentication succeeds (EAP-TLS completes) but Authorization Policy matches Default_Deny — AD group condition fails.
Cause: ISE cannot resolve the certificate identity to an AD account. The UPN in the certificate SAN does not match any account in AD, or the Certificate Authentication Profile is not configured to use UPN from SAN.
Fix: In the Certificate Authentication Profile (Administration > Identity Management > External Identity Sources > Certificate Authentication Profile), verify the Principal Username field is set to Subject Alternative Name - Other Name (UPN). Then in ISE Live Logs, expand the failed authentication and check the Certificate:Subject-Alternative-Name-UPN attribute value. Compare it to the actual UPN format in AD. A mismatch — for example, LAPTOP01@corp.local in the cert vs. LAPTOP01$@corp.local expected by AD — causes the lookup to fail. Regenerate the certificate template to include the correct UPN format.
Symptom: Domain computers enrolled successfully with certificates but Windows NIC shows "Authentication failed" and ISE shows no entry in Live Logs for the authentication attempt.
Cause: The Wired AutoConfig service (dot3svc) is not running on the endpoint, or the Group Policy WLAN/802.3 policy is not applied.
Fix: On the endpoint, run services.msc and confirm the Wired AutoConfig service is running and set to Automatic. Run gpresult /r to verify the 802.3 Group Policy is applied. If the GPO is applied but the service is not starting, check the Windows Event Log under Applications and Services Logs > Microsoft > Windows > Wired-AutoConfig > Operational for error events indicating why authentication is not initiating.
What's Next: [Article 12: MAC Authentication Bypass (MAB) Configuration on Cisco IOS XE and ISE] — configuring MAB for devices that cannot run an 802.1X supplicant, including printers, IP cameras, IoT devices, and legacy endpoints, with ISE endpoint identity group policy and profiling integration.
