Nome del certificato non corrispondente o scadenza: distinguerli

Due guasti VPN sembrano identici dalla sedia dell’utente e richiedono correzioni opposte. Una mancata corrispondenza del nome dice che il certificato è valido ma emesso per qualcos’altro. Un errore di scadenza dice che il certificato non è valido in questo momento. Nessuno dei due è un problema di password, e reimpostare le credenziali è l’ora più sprecata in entrambi i casi. Leggi lo stadio che fallisce prima di toccare qualsiasi cosa.

Il testo dell’errore è la diagnosi

Il client ti dice quale controllo è fallito, anche quando il messaggio è stringato. Una mancata corrispondenza nomina il nome host atteso e quello trovato. Un errore di scadenza menziona date di validità o un orario. Quelle due frasi indicano parti diverse del certificato.

Leggile allo stadio in cui compaiono. Un fallimento durante l’handshake è un problema di certificato; un fallimento dopo che il tunnel è attivo è un problema di routing o di credenziali. Mantenere lo stadio è ciò che impedisce all’indagine di scivolare su impostazioni non correlate.

Se il fallimento varia tra un tentativo e l’altro, hai una terza possibilità: più di un nodo dietro lo stesso nome.

Controlli sul nome: cosa confronta il client

Il client confronta l’identità che è configurato ad attendersi con i nomi nel certificato, che risiedono nell’estensione subjectAltName. Un IP grezzo nel profilo, un alias che il certificato non elenca, o un nome che semplicemente risolve allo stesso server falliscono tutti questo controllo. Raggiungere la macchina giusta non è la stessa cosa che presentare l’identità giusta.

Ispeziona il certificato che il server presenta davvero invece di un file di un tentativo precedente. Il comando qui sotto chiede il nome che hai configurato, così la risposta include il certificato che vedrebbe un client reale.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

Un certificato di un emittente fidato può comunque essere per un altro servizio. Mantieni attivi i controlli sul nome del client, perché fidarsi di una CA non autorizza ogni nome che quella CA abbia mai firmato. Disattivare il controllo trasforma un errore di configurazione in un’esposizione.

Scadenza: quale orologio viene letto

La validità è una coppia di marche temporali, e il verificatore le confronta con il proprio orologio. Un dispositivo con l’orologio sbagliato segnala un certificato valido come scaduto o come non ancora valido, e la correzione riguarda l’orologio, non il certificato. Una differenza di visualizzazione del fuso orario non è la stessa cosa di un orario sottostante errato.

Confronta le date del certificato con UTC sul client prima di concludere qualsiasi cosa:

openssl x509 -in cert.pem -noout -dates
date -u

Se le date sono davvero passate, rinnova tramite l’emittente. Se esiste una sostituzione ma non è ancora valida, segui il passaggio supportato invece di spostare l’orologio per adattarlo. Retrodatare un dispositivo per soddisfare un certificato è una decisione con conseguenze ben oltre il tunnel.

Perché correggerne uno rivela l’altro

La validazione esegue una sequenza di controlli, e il primo fallimento ferma il rapporto. Correggi il nome e il client può allora dirti che la catena è incompleta o che il certificato è scaduto. Ciò non significa che il primo controllo fosse inutile. Significa che la catena aveva più di un problema, quindi aspettati il secondo errore invece di leggerlo come prova che la prima correzione fosse sbagliata.

Più nodi peggiorano la cosa. Un servizio bilanciato può presentare certificati diversi da membri diversi, quindi un test che passa due volte e fallisce una volta ti sta parlando della flotta, non del tuo client. Conserva l’indirizzo del peer e l’ora del tentativo nella diagnosi.

È quel dettaglio a trasformare un ticket intermittente in un ticket riproducibile.

Dimostralo con una connessione nuova

Dopo la riparazione, apri una nuova connessione invece di riprenderne una vecchia, e conferma che lo stadio che falliva ora passa. Poi conferma che il tunnel trasporti davvero traffico, perché un handshake riuscito non è una rotta funzionante.

Conserva lo stadio esatto dell’errore e i dettagli del certificato con il ticket.

Quel registro è ciò che impedisce alla persona successiva di reimpostare le password dell’account per un problema di certificato. Identità e validità sono domande separate, e la RFC 5280 è il riferimento per come viene valutata la seconda.