Certificato VPN rinnovato: alcuni client lo rifiutano ancora

Metà della rete si riconnette dopo il rinnovo e tre dispositivi rifiutano, ciascuno con un avviso sull’identità del gateway. Il rinnovo in sé è routine. Ciò che quei tre dispositivi conservano è un pin al vecchio oggetto, e un pin non è un elenco di CA, un controllo del nome o una voce dell’archivio di fiducia. Confronta i tre meccanismi prima di toccare qualsiasi client.

Un rinnovo, due comportamenti

I client che si riconnettono hanno una decisione di fiducia che passa ancora, mentre quelli che rifiutano hanno un requisito che il nuovo certificato non soddisfa. Questa differenza è informazione, non rumore. Leggi con precisione il messaggio del client che fallisce. Una mancata corrispondenza del nome, un emittente sconosciuto e un’impronta cambiata sono tre verdetti diversi, e solo l’ultimo indica un pin.

Controlla anche quale profilo ha selezionato il client che fallisce. Una copia importata che vive nel proprio archivio non cambia quando l’amministratore modifica il file originale altrove.

Un rinnovo sostituisce l’oggetto, non solo la data

Un’impronta identifica il contenuto codificato del certificato. Il rinnovo produce un nuovo certificato, quindi l’impronta cambia anche quando il nome del soggetto e la chiave pubblica restano identici. È atteso e innocuo per i client che si fidano di una CA e verificano il nome. È fatale per un client configurato per accettare esattamente un certificato, ed è fatale anche per un client il cui archivio di fiducia non ha mai ricevuto il nuovo emittente.

openssl x509 -in server.pem -noout -subject -issuer -dates -fingerprint -sha256
openssl x509 -in server.pem -noout -pubkey | openssl sha256

La seconda riga risponde a un’altra domanda: se la coppia di chiavi è sopravvissuta. Un rinnovo che riutilizza la chiave mantiene quel valore e cambia solo il certificato, ed è esattamente il caso in cui l’amministratore è tentato di presumere che nulla sia cambiato. Ispeziona il certificato distribuito, non quello sull’host di build. Confrontare un file in un repository dimostra ciò che è stato generato, non ciò che un listener sta presentando in questo momento.

Leggi cosa fissa il client

Alcuni client conservano un’impronta nel proprio profilo e la confrontano a ogni connessione. Altri la memorizzano in un archivio di fiducia della piattaforma, e altri ancora si affidano solo a una CA. La riparazione è diversa in ogni caso, quindi identifica prima il meccanismo.

grep -n 'peer-fingerprint' /etc/openvpn/client/*.conf
openssl s_client -connect gw.lab.example.net:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -fingerprint -sha256

Il primo comando mostra un pin in un profilo convenzionale; il secondo mostra l’impronta che l’endpoint serve davvero in questo momento. Quando i due differiscono, hai individuato il guasto senza indovinare. Non incollare il nuovo valore in ogni client che si lamenta. Un client che rifiuta per motivi di emittente continuerà a rifiutare, e ti sarai convinto che l’impronta fosse il problema quando non lo era.

Confronta il certificato servito da ogni backend

Risultati intermittenti di solito significano più di un endpoint, e un rinnovo applicato a un solo nodo lascia gli altri a presentare il vecchio oggetto. Confronta ogni backend per indirizzo anziché per il nome condiviso.

for h in 10.30.0.11 10.30.0.12; do echo "$h"; openssl s_client -connect $h:443 -servername gw.lab.example.net < /dev/null 2>&1 | openssl x509 -noout -subject -dates -fingerprint -sha256; done

Un pool in cui un nodo è indietro spiega un client che si connette al secondo tentativo e fallisce al primo. Spiega anche un controllo di monitoraggio che passa mentre gli utenti si lamentano. Correggi prima il ritardo. Distribuire la configurazione di fiducia prima che ogni nodo serva il nuovo certificato crea una finestra in cui nulla funziona, e distribuirla dopo lascia i client in errore in modo imprevedibile.

Cambia la fiducia tramite il percorso gestito

Conferma la sostituzione tramite un canale amministrativo già affidabile prima di accettarla ovunque. Una data di scadenza plausibile non è prova di proprietà. Aggiorna la configurazione gestita tramite il processo che la possiede, con qualsiasi sovrapposizione pianificata di identità accettabili, e mantieni la verifica del nome richiesta dal deployment. Un pin senza controllo del nome è un progetto più debole della fiducia nella CA che ha sostituito.

Poi verifica per ogni client: connettiti, conferma l’identità che ha accettato e annota la versione del certificato di cui ora si fida. Un avviso ignorato una volta ha il vizio di tornare al rinnovo successivo.