Il problema del BYOD e il ruolo dei certificati
In uno scenario BYOD, l’obiettivo è portare un dispositivo personale non gestito a una autenticazione forte e senza password sulla rete. La risposta d’esame è quasi sempre la stessa: onboarding tramite client provisioning che rilascia all’endpoint un certificato digitale, seguito da autenticazione EAP-TLS al 802.1X. Il certificato sostituisce le credenziali statiche e lega l’accesso all’identità dell’utente e al singolo device.
La internal CA di ISE
Cisco ISE integra una PKI interna (ISE Internal CA), disabilitata di default e attivabile dal PAN primario. È strutturata su più livelli: una Root CA sul PAN, una Node CA subordinata per ogni nodo e una Endpoint CA che firma i certificati dei dispositivi. Questa gerarchia serve esattamente al BYOD e al MDM: emette, rinnova e revoca i certificati degli endpoint senza dipendere da una CA esterna.
Punto chiave da non confondere:
| Elemento | Cosa è | Uso |
|---|---|---|
| Certificato di sistema di ISE | Cert. del nodo (EAP Authentication) | ISE lo presenta come server nel tunnel EAP-TLS/PEAP |
| Certificato del dispositivo | Emesso all’endpoint via SCEP/ISE CA | L’endpoint lo presenta come client in EAP-TLS |
Sono due certificati distinti, con ruoli e EKU opposti (Server Authentication vs Client Authentication).
SCEP: come il certificato arriva all’endpoint
Durante l’onboarding, il supplicant nativo (configurato dal Native Supplicant Provisioning wizard, ad es. NSA per Windows/macOS o il profilo per iOS/Android) esegue questi passi:
- Genera localmente la coppia di chiavi (la private key non lascia mai il dispositivo).
- Costruisce una CSR con Subject e SAN previsti.
- Invia la richiesta tramite SCEP (Simple Certificate Enrollment Protocol) a ISE.
ISE può firmare direttamente con la Internal CA oppure agire da SCEP RA/proxy verso una PKI aziendale esterna (SCEP RA profile). In entrambi i casi il comportamento e i valori del certificato sono governati dal Certificate Template.
Il Certificate Template
Il template definisce Subject/SAN (tipicamente CN = username o MAC), lunghezza chiave, validità, la SCEP RA da usare e soprattutto le Key Usage / Extended Key Usage. Per EAP-TLS l’EKU deve includere Client Authentication (1.3.6.1.5.5.7.3.2). Un template con EKU errata produce un certificato che l’autenticazione rifiuterà.
L’autenticazione EAP-TLS
A onboarding concluso, il device si riconnette (single-SSID o dual-SSID) e negozia EAP-TLS, che è mutuale:
- ISE presenta il certificato di sistema (EAP); l’endpoint deve fidarsi della catena che lo firma.
- L’endpoint presenta il certificato del dispositivo; ISE valida la catena contro il Trusted Certificates store e controlla la revoca via CRL/OCSP.
L’identità viene estratta dal certificato tramite il Certificate Authentication Profile (CAP) (es. Subject – Common Name), poi valutata nella policy di autorizzazione. Nessuna password transita: è il possesso della private key a dimostrare l’identità.
Revoca e My Devices portal
L’utente gestisce i propri dispositivi dal My Devices portal: marcandone uno come Lost/Stolen, ISE lo mette in blacklist e la Internal CA revoca il certificato dell’endpoint. La revoca diventa efficace perché pubblicata in CRL/OCSP: alla successiva EAP-TLS il device viene rifiutato. Un amministratore ottiene lo stesso effetto dalla vista Endpoints/Certificates. Reinstate riabilita il device.
Trappole tipiche d’esame
- Catena di trust incompleta sull’endpoint → EAP-TLS fallisce. Se il device non ha nel proprio trust store la Root/Intermediate che firma il certificato di sistema di ISE, rifiuta il server e l’handshake si interrompe: la fix è distribuire la catena completa (spesso già inclusa nel profilo di provisioning).
- EKU errata nel template → autenticazione negata. Un template che rilascia Server Authentication invece di Client Authentication genera un cert. inutilizzabile per EAP-TLS: correggere l’EKU nel Certificate Template.
- Confondere il certificato di dispositivo con quello di sistema di ISE. Scenario “l’endpoint non è fidato/valido”: si interviene sul cert. dell’endpoint (template, CA emittente, revoca), non sul certificato EAP di ISE, e viceversa.
- SCEP proxy verso PKI esterna mal configurato. Se ISE usa un SCEP RA profile esterno ma la CA emittente non è nel Trusted Certificates store con l’opzione Trust for client authentication, la validazione del client cert fallisce anche con certificato “buono”.
- Revoca non applicata. Marcare Lost nel My Devices portal non basta se ISE non consulta CRL/OCSP per quella CA: senza controllo di revoca abilitato il device revocato continua ad autenticarsi.