Una clave privada cifrada y una sin cifrar contienen el mismo material de clave. Convertir no crea una identidad nueva, no restablece una cuenta de VPN ni invalida el archivo antiguo. Escribe una segunda copia, y esa copia conlleva un riesgo en reposo distinto.

Si el intercambio merece la pena depende de dónde vivirá el archivo y de quién pueda leerlo.

Qué cambia realmente la conversión

Antes de la conversión, la clave está protegida por una frase de paso que aporta el operador. Después de la conversión, está protegida por los permisos del sistema de archivos y por cualquier control de acceso que rodee el archivo. La criptografía no ha cambiado; el número de cosas entre un atacante y la clave sí. Esa es toda la comparación.

Una tabla hace concreta la diferencia.

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

Ninguna de las dos formas es automáticamente más segura. Fallan de maneras distintas, y solo una de esas maneras deja un registro en el log.

Cuándo es mejor conservar la frase de paso

Si un cliente compatible puede pedir la frase de paso o tomarla de un almacén de secretos aprobado, la conversión no aporta nada. Conserva una copia, un límite de protección y un archivo menos que rastrear. La mayoría de los clientes VPN que aceptan claves PEM pueden hacerlo.

Convertir también es un movimiento equivocado cuando un equipo comparte la clave. Un archivo sin cifrar en un host compartido se convierte en una credencial que cualquiera con acceso a la shell puede copiar.

Cuándo está justificada una copia sin cifrar

Algunos servicios no pueden pedir nada, algunos contenedores montan secretos en solo lectura y algunos dispositivos leen un archivo de clave al arrancar sin una ruta interactiva. En esos casos, una clave sin cifrar dentro de un directorio bien restringido puede ser el diseño admitido. La justificación es el entorno, no la comodidad.

Si no puede decir quién puede leer el archivo y por qué, la respuesta es no.

El comando y sus aristas

Para una clave basada en archivo compatible con OpenSSL 3.5, la referencia de pkey documenta la eliminación de la frase de paso y un aviso interactivo cuando la entrada está cifrada y no se aporta ninguna fuente de contraseña. La forma mínima es corta, y es fácil ejecutarla con descuido.

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

Tres aristas. La E/S del archivo de salida no es atómica, así que una ruta de salida existente puede truncarse a mitad de escritura. No use la ruta de entrada como salida y no experimente con la única copia protegida. Introduzca la frase de paso en el aviso y no en la línea de comandos, donde acaba en el historial de la shell.

Compruebe el resultado antes de cambiar cualquier configuración de VPN: openssl pkey -in new-private-key.pem -pubout debería imprimir la misma clave pública que tenía antes.

Qué no hace la conversión

No revoca la copia cifrada, que sigue existiendo dondequiera que la dejara. No cambia la contraseña de la cuenta de VPN ni el certificado. Y no repara una exposición que ya ocurrió. Si una clave se filtró, la solución es la sustitución y la retirada en el lado del servidor, no un cambio de formato local.

Elimine el archivo intermedio a propósito y confirme que la ruta que borra es la que creó.

Artículos relacionados