Perché OpenConnect rifiuta il gateway dopo un cambio di certificato?

I gateway sostituiscono certificati, e un client che ieri si connetteva inizia a fermarsi al primo scambio TLS. Il messaggio nomina un motivo di verifica anziché un guasto di rete, e la macchina stessa non è cambiata, che è l’indizio utile. Ciò che si è rotto è il rapporto tra il certificato ora presentato e le radici che il client è disposto a considerare. Ripararlo è una decisione di fiducia, quindi prendetela prima di digitare un’opzione.

Leggete l’errore prima di cambiare qualsiasi impostazione di fiducia

Un errore del tipo firmatario mancante significa che la catena termina su qualcosa che il client non accetta. Può essere un certificato rinnovato da un’autorità interna, una sostituzione da una pubblica, o un dispositivo nel mezzo che presenta il proprio certificato. Solo la formulazione non può distinguere questi casi, quindi guardate l’emittente prima di decidere.

Eseguite la connessione una volta in primo piano e lasciatela fallire, perché l’output interattivo porta il nome del server, la catena degli emittenti e l’impronta calcolata dal client. Confrontate quell’emittente con un’autorità che la vostra organizzazione gestisce davvero. Se l’impronta è cambiata mentre l’emittente no, trattatela come sospetta finché un rinnovo non è confermato da un canale di cui vi fidate già. Indovinare a questo punto è come una persona finisce per fissare la chiave di un intercettatore.

Annotate la versione del client nello stesso appunto. Buona parte dei guasti che sembrano problemi di fiducia viene da un client più vecchio che incontra uno scambio del gateway più recente.

Scegliere tra fidarsi dell’emittente e fissare una chiave

Entrambe le opzioni fanno riuscire la connessione. Si rompono dopo in modi opposti, quindi la scelta appartiene al guasto che potete tollerare.

Ricorrete al file AC quando il certificato proviene da un’autorità che potete verificare in modo indipendente, perché i rinnovi continuano a funzionare senza toccare gli argomenti del client. Abbinatelo all’interruttore che disabilita le radici di sistema, altrimenti un’autorità pubblica può soddisfare il controllo al posto vostro. Fissate invece quando il gateway non ha un’AC che potete ottenere o quando l’eccezione più stretta possibile è l’obiettivo. Nessuna via è più sicura in astratto: l’AC scala nei rinnovi, il pinning è più facile da riesaminare.

Qualunque scegliate, il valore fidato deve arrivare attraverso un canale che era fidato prima che avvenisse il cambiamento. Un amministratore, una sessione console sul gateway o una copia presa in anticipo vanno tutti bene. Copiare l’impronta mostrata dal prompt è comodo ed è esattamente ciò che un intercettatore spera.

Mettete il valore nel comando che lanciate davvero

Il pinning viaggia in un’opzione di certificato server, e il suo prefisso decide la codifica: digest esadecimali di chiave pubblica sotto sha1 o sha256, e il pinning della chiave in base64 sotto pin-sha256. Fornirlo disabilita anche la fiducia di sistema per quella esecuzione, quindi la chiave fissata diventa l’intera decisione.

sudo openconnect --protocol=gp vpn.example.com --user alice \
  --servercert pin-sha256:AbCdEf...   # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trust

Il client confronta un digest troncato, accettando appena quattro caratteri dopo il prefisso, il che è una trappola e non una comodità. Un valore abbreviato passa localmente e ancora non identifica il gateway che intendevate. Copiate la stringa completa stampata dal client al primo tentativo invece di ridigitarla da un messaggio. Poi spostate l’opzione finita nello script wrapper, nel file unit o nel profilo che avvia la connessione, così la decisione di fiducia è riesaminabile e le modifiche successive sono deliberate.

Gli avviatori desktop e il plugin NetworkManager conservano una propria copia degli argomenti di connessione. Uno script modificato su disco non raggiunge un profilo importato prima, quindi il valore memorizzato continua a vincere.

Gestite un rollover senza chiudervi fuori

L’opzione può essere data più di una volta, quindi un cambiamento pianificato può accettare insieme la chiave uscente e quella entrante. Aggiungete il nuovo pin prima che il gateway cambi, tenete entrambi elencati mentre le sessioni migrano, e togliete quello ritirato quando la vecchia chiave è sparita. Quella finestra ha bisogno di un responsabile, poiché un doppio pin dimenticato lascia una chiave fidata senza nessuno che la sorvegli. Una ricostruzione che produce una nuova coppia di chiavi rompe un pin puro, e il ripristino è la stessa procedura nella direzione opposta.

Scrivete la data del cambiamento accanto al pin. Un pin senza data di revisione è un’interruzione futura che porta un messaggio di errore confuso.

Escludete la versione del client prima di modificare la fiducia

Un client datato può fallire mentre analizza una risposta di autenticazione che il gateway ha modificato da allora, e il messaggio superficiale parla ancora della connessione anziché del parser. Confrontate la versione installata con ciò che il gateway documenta, e provate un pacchetto attuale in un profilo usa e getta prima di cambiare qualsiasi impostazione di fiducia.

openconnect --version

Dopo la riparazione, verificate due cose anziché una: il portale si carica attraverso il tunnel e un indirizzo interno ordinario risponde. Una stretta di mano completata dimostra solo che la decisione di fiducia è stata accettata.