Rinnovare un certificato VPN senza cambiarne l'identità

Un rinnovo di certificato che cambia l'identità non è un rinnovo, è una migrazione travestita da ticket di manutenzione. Il client verifica un nome, una catena e talvolta una chiave specifica, e tutti e tre possono cambiare senza che cambi la data di scadenza. Prima di richiedere una sostituzione, annota ciò che il client controlla davvero: il nome host o l'identità del peer, lo scopo del certificato, la politica delle chiavi e la catena emittente. Il rinnovo è di routine o coordinato a seconda di quale di questi elementi la sostituzione modifica.

Tre condizioni decidono la forma del rinnovo

Le tre condizioni sono se qualcosa fissa la foglia, se la catena cambia e chi altro convalida il nome. Rispondi dal lato del client anziché dalla comodità della CA, perché è il client che fallisce alle tre del mattino.

Inizia ispezionando il certificato che hai. openssl x509 -in server.crt -noout -subject -issuer -dates -ext subjectAltName stampa il soggetto, l'emittente, la finestra di validità e i nomi per cui il certificato è realmente valido. Quest'ultimo campo è il più importante e il più dato per scontato: una richiesta di rinnovo che omette un SAN su cui il client fa affidamento produce un certificato tecnicamente valido ma funzionalmente sbagliato. Copia l'elenco dei SAN dal vecchio certificato nella richiesta invece di ridigitarlo a memoria.

Condizione uno: qualcosa fissa la foglia

Se i client si fidano di una CA mantenuta e convalidano il nome, un rinnovo della foglia con una nuova chiave è invisibile per loro. Se un client fissa il certificato foglia, la sua impronta o la sua chiave pubblica, la sostituzione è un cambiamento coordinato con un passaggio netto, perché il vecchio pin non può convalidare il nuovo certificato.

Scopri in quale caso ti trovi prima di ordinare qualsiasi cosa. Un pin che nessuno ha documentato resta un pin quando si rompe.

Condizione due: confronta i pin e la catena

Le impronte rendono il pin verificabile: openssl x509 -noout -fingerprint -sha256 -in server.crt sul certificato vecchio e nuovo, e openssl x509 -noout -pubkey per confrontare le chiavi pubbliche. Se la configurazione del client, un profilo mobile o un archivio di fiducia di un appliance contiene uno dei due valori, hai un pin. I profili VPN mobili sono un nascondiglio comune, perché il profilo viene distribuito una volta e mai più ispezionato.

Se la sostituzione proviene dallo stesso intermedio e il client lo possiede già o può recuperarlo, nulla cambia sul lato della fiducia. Un nuovo intermedio, un emittente diverso o una catena consegnata nell'ordine sbagliato trasformano un rinnovo in un cambiamento di fiducia, e il guasto sembra un emittente sconosciuto anziché un certificato scaduto.

Controlla la catena che il server invia realmente con openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts e verificala localmente con openssl verify -CAfile ca.pem -untrusted chain.pem server.crt. Farlo prima del cambiamento ti dà una linea di base con cui confrontare dopo.

Condizione tre: chi altro convalida il nome

Un concentratore VPN, un bilanciatore di carico, una sonda di monitoraggio, un'integrazione RADIUS o SAML e un profilo mobile possono ciascuno conservare la propria copia del nome atteso o dell'ancora di fiducia. Il rinnovo è il momento in cui quelle copie divergono, perché il certificato cambia e le copie no.

Elenca ogni consumatore prima del cambiamento e decidi, per ciascuno, se necessita di un aggiornamento. Quello che dimentichi è quello che ti chiama.

C'è anche una trappola temporale. Ispeziona l'inizio della validità oltre alla scadenza, perché un certificato preparato per un'attivazione successiva viene rifiutato se installato troppo presto, e l'errore sembra un problema di orologio anziché un problema di preparazione. openssl x509 -noout -dates sul nuovo file prima di distribuirlo è un controllo di due secondi. Mantieni anche un percorso di ripristino supportato e la configurazione nota come buona, così un rinnovo che va storto è reversibile ripristinando il certificato e la chiave precedenti.

Distribuisci, verifica con un'autenticazione nuova, poi ritira

Un tunnel consolidato riflette la convalida avvenuta quando è stato costruito, quindi può sembrare sano mentre ogni nuova connessione fallisce. Prova con un'autenticazione nuova usando il nome di servizio reale che i client usano.

Completa il controllo a livello applicativo che interessa all'utente e conferma la consegna della catena dal punto di vista del client anziché da quello del server. Non sopprimere i controlli del nome o del certificato per mantenere tranquilla la transizione; così un problema di compatibilità temporaneo diventa permanente.

Ritira il materiale obsoleto solo dopo che il rollout è verificato, e tratta una chiave compromessa come un caso del tutto diverso: il solo rinnovo non revoca nulla, quindi l'identità interessata ha bisogno del processo di revoca e di gestione delle sessioni del deployment. RFC 5280 definisce le regole di certificato e di convalida del percorso alla base di tutto questo. Tieni un rinnovo foglia di routine separato da una sostituzione della CA, così ai client non viene chiesto di fidarsi di un nuovo emittente senza motivo.