Il certificato del gateway va bene: perché l’accesso IKEv2 PEAP fallisce comunque

Il certificato del vostro gateway VPN è valido, la catena viene convalidata, e il client IKEv2 rifiuta comunque l’accesso con un messaggio su un intervallo di validità del certificato. Il primo istinto è riemettere il certificato del gateway o cambiare metodo EAP, ed entrambi di solito sono sbagliati. Il tentativo di accesso porta due identità server distinte: il certificato del gateway usato da IKE, e il certificato presentato da ciò che termina PEAP. Una delle due è a posto, e l’altra è il motivo per cui il client si è fermato.

Due identità, un solo tentativo di accesso

Il certificato nel profilo VPN appartiene allo scambio IKE: dimostra che il gateway è il peer nominato dal profilo, secondo il criterio IKE configurato. Il certificato che fallisce qui appartiene a un’altra conversazione, la sessione TLS che PEAP apre con chi autentica l’utente, spesso un server RADIUS come NPS e non il gateway stesso. Un terzo controllo, le credenziali dell’utente, avviene dentro quella sessione. Una password valida non può riparare un certificato server scaduto, e un certificato del gateway valido non può garantire per l’endpoint PEAP.

Questa stratificazione spiega perché un errore di certificato compare in un punto in cui l’unico certificato configurato era quello del gateway. Spiega anche perché riemettere quel certificato non cambia nulla.

Leggete la riga di log rispetto alla fase

Trovate il messaggio che nomina il motivo e le date. Una lamentela sull’intervallo di validità accanto a un errore di soggetto significa che il server ha rifiutato il certificato che gli è stato dato, non che l’utente ha rifiutato l’accesso. Poi trovate la fase: un log charon di strongSwan mostra IKE_SA .* established prima che inizi lo scambio EAP, quindi un errore di certificato dopo quella riga appartiene all’identità EAP, mentre un errore precedente indica il gateway. Il testo della fase nel pannello di connessione di un client Windows dice la stessa cosa.

Controllate l’orologio del client prima di toccare qualsiasi certificato. Un dispositivo sfasato di ore produce lo stesso errore di validità di un certificato davvero scaduto. Reimpostare l’orologio è una correzione di cinque secondi, e sostituire un certificato che non è mai stato il problema è un’interruzione.

Scoprite quale endpoint termina PEAP

In un progetto gateway più RADIUS, il gateway inoltra EAP e non lo termina. Il plugin eap-radius di strongSwan consegna lo scambio al server RADIUS, che possiede la sessione TLS di PEAP e il suo certificato. Correlate un tentativo fallito in entrambi i log e confermate quale processo ha realmente scelto un certificato per quella sessione.

Per NPS il certificato deve trovarsi nell’archivio del computer locale, portare lo scopo di autenticazione server, corrispondere al nome atteso dai client ed essere leggibile dall’account di servizio. I requisiti dei certificati di Microsoft per NPS elencano queste condizioni. Gli altri server EAP hanno le proprie regole di selezione, quindi non copiate le particolarità di NPS in una distribuzione FreeRADIUS né il contrario. La regola che vale in entrambi i casi è che l’endpoint che termina PEAP possiede il certificato che state per cambiare.

Sostituite il certificato dove termina EAP

Rinnovate o sostituite il certificato sull’endpoint che termina PEAP, tramite la procedura supportata, mantenendo lo scopo di autenticazione server e il nome atteso. Installate la catena completa dove il servizio la cerca e concedete al servizio l’accesso alla chiave privata. Riavviate o riassociate il servizio, perché molti servizi tengono il vecchio certificato in memoria e continuano a presentarlo. Un file copiato sulla macchina non dimostra nulla su quale certificato il servizio presenti davvero.

Confermate la modifica correlando il tentativo successivo con il log proprio del servizio, oppure ispezionando il certificato presentato dalla sessione. Se quel log mostra ancora la vecchia impronta, il riavvio non ha avuto effetto.

Non date per scontato che il file più recente in una cartella sia quello in uso. Una copia con il nome giusto e i permessi sbagliati non cambia nulla. Giudicate la modifica dall’identità presentata, non dalla data di un file.

Cosa non fare

Non disattivate la convalida PEAP e non forzate un metodo interno più debole per superare l’errore. Questo cambia il criterio e rimuove la proprietà di autenticazione server che ha intercettato il certificato scaduto in primo luogo. Scambiereste un controllo funzionante con una connessione funzionante, e il prossimo certificato scaduto arriverebbe senza nulla ad annunciarlo.

Non prendete una connessione riuscita di un altro sistema operativo come prova che il certificato sia accettabile. Quel client può usare un altro metodo EAP, un altro archivio di fiducia o nessuna convalida del server, quindi il suo successo non dice nulla sul controllo fallito qui. Mantenete un test negativo deliberato, come un certificato con il nome sbagliato o una catena non attendibile, che fallisca come previsto. Se quel test ora passa, avete rimosso un controllo invece di riparare un certificato. Annotate quale identità ha fallito, così la persona successiva non ricomincia dal certificato del gateway.