Richiesta della chiave OpenVPN dopo OpenSSL 3: verificate il provider

Nessuno ha toccato il profilo, eppure lo stesso client adesso chiede una passphrase per la chiave privata a ogni avvio. Quando questo cambiamento arriva pochi giorni dopo un aggiornamento della distribuzione, l’aggiornamento è la causa probabile: OpenSSL 3 ha riorganizzato il supporto agli algoritmi, e una chiave che la vecchia libreria leggeva senza problemi può diventare illeggibile senza che cambi un solo byte. Eseguite i controlli in ordine, perché due di essi sembrano identici se guardate solo la richiesta.

La prima domanda è se la chiave è cifrata, la seconda è se questa build può decifrarla. Le modifiche alla configurazione hanno senso solo dopo che entrambe le risposte sono note.

Verificate se la chiave è cifrata

Leggete la prima riga del file e poi lasciate che la libreria la analizzi, perché un nome di file non dimostra nulla. Un blocco PEM etichettato ENCRYPTED PRIVATE KEY è PKCS#8 cifrato, e un blocco RSA PRIVATE KEY più vecchio che porta Proc-Type: 4,ENCRYPTED è la forma tradizionale, ed entrambi si aspettano una passphrase. Un blocco PRIVATE KEY non cifrato non dovrebbe chiederne affatto. Eseguite l’analisi con l’account che possiede il file, perché un problema di permessi produce un errore diverso e molto meno interessante.

Se la chiave non è davvero cifrata e il client chiede comunque, smettete di guardare la crittografia e verificate se il profilo indica un file askpass che il servizio può ancora leggere.

Verificate se questa build può decifrarla

OpenSSL 3 ha diviso il supporto agli algoritmi in provider, e un insieme di cifrari più vecchi ora risiede nel provider legacy invece che in quello predefinito. Una chiave cifrata con uno di quei cifrari resta valida, ma una libreria caricata senza il provider legacy non può decodificarla. Su alcuni client ciò si manifesta come una richiesta che si ripete, su altri come un errore netto subito dopo la passphrase.

Analizzate la stessa chiave due volte con lo stesso binario: prima solo con il provider predefinito, poi con legacy e predefinito entrambi richiesti sulla riga di comando. Se il secondo tentativo riesce dove il primo ha fallito, la diagnosi poggia su prove e non sul momento dell’aggiornamento. Se entrambi falliscono allo stesso modo, la passphrase è sbagliata o il file è danneggiato, e nessuna impostazione del provider ripara né l’una né l’altro.

Verificate la correzione più ristretta disponibile

Preferite una modifica limitata al client a una a livello di sistema. Alcune build 2.6 accettano un’opzione del profilo che carica entrambi i provider per il processo di quel demone, quindi confermate la direttiva nel manuale della vostra versione esatta prima di farvi affidamento; modificare il openssl.cnf di sistema influisce invece su ogni programma OpenSSL dell’host. L’impostazione più ristretta è anche molto più facile da annullare una volta ricodificata la chiave.

Non cancellate la passphrase per far sparire la richiesta. Così una credenziale protetta diventa un file di testo in chiaro e cambia silenziosamente il rischio di ogni backup, copia e pacchetto di assistenza in cui compare. La distinzione che conta è tra una chiave che ha bisogno della sua passphrase e una chiave che questa libreria non può decodificare.

Verificate il contesto del servizio, poi ricodificate

Una volta che la chiave può essere sbloccata, cifratela di nuovo con un algoritmo attuale così che la dipendenza sparisca. Scrivete il nuovo file con un cifrario moderno, verificate che venga analizzato, aggiornate il profilo e conservate la copia vecchia solo finché una connessione non riesce. Non mettete mai la passphrase su una riga di comando, dove qualsiasi utente locale può leggerla dall’elenco dei processi. Rimuovete il file vecchio solo dopo che il nuovo si è connesso dall’account di servizio, non solo dalla vostra shell.

Poi verificate l’unità che esegue davvero il client. Una chiave leggibile nella vostra shell può essere illeggibile per un servizio in esecuzione con un altro account o con un’impostazione indurita della home.

Annotate l’impostazione del provider accanto al profilo e teneteci la prova a due comandi. Quando un aggiornamento successivo rimuoverà il provider legacy, rieseguite quella prova per vedere se la chiave ne ha ancora bisogno o se il profilo può uscire dal workaround.

Una richiesta è un sintomo con almeno tre cause, e solo una di esse è una passphrase mancante.