Eliminar a frase de paso dunha chave ou conservala? A copia que creas
Un ficheiro de chave sen cifrar garda o mesmo segredo baixo unha protección máis feble. Compare o risco en repouso antes de converter e saiba que non desfai.
Unha chave privada cifrada e unha sen cifrar conteñen o mesmo material de chave. Converter non crea unha identidade nova, non restablece unha conta de VPN nin invalida o ficheiro antigo. Escribe unha segunda copia, e esa copia leva un risco en repouso distinto.
Se o intercambio paga a pena depende de onde vivirá o ficheiro e de quen poida lelo.
Que cambia realmente a conversión
Antes da conversión, a chave está protexida por unha frase de paso que achega o operador. Despois da conversión, está protexida polos permisos do sistema de ficheiros e por calquera control de acceso que rodee o ficheiro. A criptografía non cambiou; o número de cousas entre un atacante e a chave si. Esa é toda a comparación.
Unha táboa fai concreta a diferenza.
| Form | What protects it | How it fails |
|---|---|---|
| Encrypted key | A passphrase plus file access | Weak passphrase, or an offline attack on the file |
| Unencrypted key | File permissions and host security only | Any reader copies it silently |
Ningunha das dúas formas é automaticamente máis segura. Fallan de maneiras distintas, e só unha desas maneiras deixa un rexistro no log.
Cando é mellor conservar a frase de paso
Se un cliente compatible pode pedir a frase de paso ou tomala dun almacén de segredos aprobado, a conversión non aporta nada. Conserva unha copia, un límite de protección e un ficheiro menos que rastrexar. A maioría dos clientes VPN que aceptan chaves PEM poden facelo.
Converter tamén é un movemento equivocado cando un equipo comparte a chave. Un ficheiro sen cifrar nun host compartido convértese nunha credencial que calquera con acceso á shell pode copiar.
Cando está xustificada unha copia sen cifrar
Algúns servizos non poden pedir nada, algúns contedores montan segredos en só lectura e algúns dispositivos len un ficheiro de chave ao arrincar sen unha ruta interactiva. Neses casos, unha chave sen cifrar dentro dun directorio ben restrinxido pode ser o deseño admitido. A xustificación é a contorna, non a comodidade.
Se non pode dicir quen pode ler o ficheiro e por que, a resposta é non.
O comando e as súas arestas
Para unha chave baseada en ficheiro compatible con OpenSSL 3.5, a referencia de pkey documenta a eliminación da frase de paso e un aviso interactivo cando a entrada está cifrada e non se achega ningunha fonte de contrasinal. A forma mínima é curta, e é fácil executala con descoido.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemTres arestas. A E/S do ficheiro de saída non é atómica, así que unha ruta de saída existente pode truncarse a metade da escritura. Non use a ruta de entrada como saída e non experimente coa única copia protexida. Introduza a frase de paso no aviso e non na liña de comandos, onde acaba no historial da shell.
Comprobe o resultado antes de cambiar calquera configuración de VPN: openssl pkey -in new-private-key.pem -pubout debería imprimir a mesma chave pública que tiña antes.
Que non fai a conversión
Non revoga a copia cifrada, que segue existindo ondequera que a deixase. Non cambia o contrasinal da conta de VPN nin o certificado. E non repara unha exposición que xa ocorreu. Se unha chave se filtrou, a solución é a substitución e a retirada no lado do servidor, non un cambio de formato local.
Elimine o ficheiro intermedio a propósito e confirme que a ruta que borra é a que creou.