Una chiave privata cifrata e una non cifrata contengono lo stesso materiale di chiave. La conversione non crea una nuova identità, non reimposta un account VPN e non invalida il vecchio file. Scrive una seconda copia, e quella copia comporta un rischio a riposo diverso.

Se lo scambio valga la pena dipende da dove vivrà il file e da chi può leggerlo.

Cosa cambia davvero la conversione

Prima della conversione, la chiave è protetta da una passphrase fornita dall'operatore. Dopo la conversione, è protetta dai permessi del file system e da qualsiasi controllo di accesso che circondi il file. La crittografia non è cambiata; è cambiato il numero di cose tra un attaccante e la chiave. Questo è tutto il confronto.

Una tabella rende concreta la differenza.

FormWhat protects itHow it fails
Encrypted keyA passphrase plus file accessWeak passphrase, or an offline attack on the file
Unencrypted keyFile permissions and host security onlyAny reader copies it silently

Nessuna delle due forme è automaticamente più sicura. Falliscono in modi diversi, e solo uno di questi modi lascia una voce nel log.

Quando è meglio conservare la passphrase

Se un client supportato può chiedere la passphrase o recuperarla da un archivio di segreti approvato, la conversione non compra nulla. Mantenete una copia, un confine di protezione e un file in meno da seguire. La maggior parte dei client VPN che accettano chiavi PEM può farlo.

La conversione è anche la mossa sbagliata quando un team condivide la chiave. Un file non cifrato su un host condiviso diventa una credenziale che chiunque abbia accesso alla shell può copiare.

Quando è giustificata una copia non cifrata

Alcuni servizi non possono chiedere, alcuni container montano i segreti in sola lettura e alcuni apparati leggono un file di chiave all'avvio senza un percorso interattivo. In questi casi, una chiave non cifrata dentro una directory ben limitata può essere il progetto supportato. La giustificazione è l'ambiente, non la comodità.

Se non potete dire chi può leggere il file e perché, la risposta è no.

Il comando e i suoi bordi taglienti

Per una chiave basata su file supportata da OpenSSL 3.5, la guida di pkey documenta la rimozione della passphrase e un prompt interattivo quando l'input è cifrato e non viene fornita alcuna origine della password. La forma minima è breve, ed è facile eseguirla con noncuranza.

umask 077
openssl pkey -in protected-key.pem -out new-private-key.pem

Tre bordi taglienti. L'I/O del file di output non è atomico, quindi un percorso di output esistente può essere troncato a metà scrittura. Non usate il percorso di input come output e non sperimentate sull'unica copia protetta. Inserite la passphrase al prompt invece che sulla riga di comando, dove finisce nella cronologia della shell.

Controllate il risultato prima di modificare qualsiasi configurazione VPN: openssl pkey -in new-private-key.pem -pubout dovrebbe stampare la stessa chiave pubblica che avevate prima.

Cosa non fa la conversione

Non revoca la copia cifrata, che esiste ancora ovunque l'abbiate lasciata. Non cambia la password dell'account VPN né il certificato. E non ripara un'esposizione già avvenuta. Se una chiave è trapelata, la soluzione è la sostituzione e la revoca lato server, non un cambio di formato locale.

Eliminate deliberatamente il file intermedio, e confermate che il percorso che cancellate è quello che avete creato.

Articoli correlati