L’accesso PIV non riesce in Windows con EAP-TLS? Verificate il percorso di firma

Mostrate il certificato di una smart card PIV in ogni finestra di Windows e l’accesso VPN può comunque fallire, perché visibilità e usabilità sono proprietà diverse. Il certificato è un oggetto pubblico; l’accesso richiede un’operazione con chiave privata eseguita dalla carta secondo le proprie regole di accesso. Tra questi due fatti stanno quattro fasi che falliscono in quattro modi diversi: selezione del profilo, selezione del certificato, firma locale e convalida lato server. Percorrerle in ordine trasforma un errore generico di handshake in una domanda precisa per chi possiede il pezzo successivo.

Iniziate dal profilo e dal metodo EAP

Aprite le proprietà della connessione e leggete quale metodo EAP usa davvero il profilo, poi leggete quale certificato il metodo è configurato per selezionare. Molte installazioni hanno sia un metodo esterno basato su certificato sia un metodo interno, e un certificato configurato a livello di connessione non è automaticamente quello presentato dentro EAP-TLS. Se il profilo sceglie un certificato per emittente o per filtro di soggetto, quel filtro sceglie tra ciò che Windows vede nell’archivio pertinente, non tra ciò che la carta contiene per caso. Un filtro che non corrisponde a nulla torna a una richiesta o a un fallimento silenzioso secondo la configurazione del profilo, perciò vale la pena annotare l’impronta selezionata prima di qualsiasi modifica.

Stabilite anche se la connessione viene eseguita come utente connesso o come macchina. Questo unico fatto decide quali archivi di certificati sono in ambito e quale contesto di sicurezza esegue la firma.

Confermate quale certificato è stato selezionato

Confrontate l’impronta scelta da Windows con il requisito: uso per l’autenticazione del client, una catena che termina in una radice attendibile, un’identità che i criteri del server di autenticazione mappano e un periodo di validità che copre il momento effettivo del tentativo. Sono controlli separati e l’ultimo intercetta più sorprese di quanto ci si aspetti, soprattutto con certificati emessi in modo continuativo e profili in cache che puntano ancora alla selezione di ieri.

Il contesto utente e quello macchina sono l’altra metà del controllo. Un certificato nell’archivio personale dell’utente è invisibile a un servizio che viene eseguito come macchina, e un certificato macchina non viene presentato da uno scambio EAP in modalità utente se il profilo non lo prevede. Reimportare un certificato nell’archivio sbagliato produce un certificato visibile e una credenziale di accesso invisibile. Leggete il percorso dell’archivio nel profilo, non quello nella finestra che si è aperta per caso.

Provate l’operazione con la chiave senza indovinare il PIN

Una volta stabilita la selezione, la domanda è se la carta eseguirà la firma. Windows ha bisogno di un provider di carta supportato o di un minidriver per raggiungere la chiave privata, e il dispositivo applica le proprie regole di PIN e di presenza all’operazione. Una carta configurata per richiedere un tocco a ogni firma si comporta diversamente da una che mette in cache una verifica per una sessione, ed entrambe sono configurazioni legittime che cambiano quando appare una richiesta. Questa differenza spiega un accesso che riesce a un inserimento nuovo e fallisce dopo una ripresa, senza che nessun certificato sia errato.

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

Il primo comando inventaria la carta e riporta lo stato del lettore e del provider, documentato nella guida Microsoft per il debug delle smart card. Il secondo elenca ciò che il contesto utente riesce davvero a vedere. Nessuno dei due dimostra un’autenticazione riuscita; entrambi restringono il punto in cui si è fermato.

Non indovinate il PIN. Le carte applicano limiti di tentativi, e qualche tentativo ottimista trasforma un problema di autorizzazioni in una credenziale bloccata che richiede un recupero amministrativo. Se una firma locale fallisce, registrate lo stato del provider e lo stato della carta invece di provare varianti. Ripetete il tentativo una volta con lo stesso profilo, lo stesso certificato e un percorso di lettore noto come buono, poi confrontate i due registri; cambiare più variabili insieme produce un racconto e non un risultato.

Leggete entrambi i lati dell’handshake

Una firma completata non è ancora ammissione. Il server di autenticazione deve accettare la catena, controllare la revoca, mappare l’identità secondo le sue regole attuali e autorizzare la richiesta; il client deve a sua volta convalidare il certificato del server come richiede il profilo. Un avviso TLS generato dal server appare nel registro del client come uno generato localmente, perciò il lato che lo emette conta più del testo dell’avviso.

Raccogliete gli eventi di Windows e quelli lato server con marche temporali allineate, poi identificate quale lato ha prodotto il primo errore. RFC 5216 descrive il passo di prova del possesso in EAP-TLS, e un avviso di handshake generico non nomina da solo una causa locale legata alla chiave. È il confronto delle marche temporali che trasforma due registri in una sequenza.

Tenete i confini chiari nel rapporto

Scrivete il rapporto come quattro fasi con un verdetto ciascuna: quale profilo e contesto sono stati eseguiti, quale certificato ha selezionato Windows, se la carta ha firmato e cosa ha deciso il server. Questa struttura rende ovvio il passo successivo e impedisce la riparazione abituale di disattivare la convalida per superare una fase che nessuno ha identificato.

Un certificato software come confronto temporaneo è un test legittimo dell’amministratore, ma cambia il modello di credenziale e di garanzia, quindi appartiene a una modifica approvata e non a una soluzione silenziosa in produzione. La stessa disciplina vale per i tentativi di PIN e per la riemissione delle credenziali prima che la fase che fallisce sia nota. Una carta sostitutiva che fallisce allo stesso modo è una prova costosa che il problema non è mai stato sulla carta.