Aviso de clave de OpenVPN tras OpenSSL 3: revise el proveedor

Nadie tocó el perfil y, sin embargo, el mismo cliente ahora pide una frase de contraseña para la clave privada cada vez que arranca. Cuando ese cambio llega pocos días después de una actualización de la distribución, la actualización es la causa probable: OpenSSL 3 reorganizó su compatibilidad con algoritmos, y una clave que la biblioteca antigua leía sin problema puede volverse ilegible sin que cambie un solo byte. Haga las comprobaciones en orden, porque dos de ellas parecen idénticas si solo mira el aviso.

La primera pregunta es si la clave está cifrada, y la segunda es si esta compilación puede descifrarla. Los cambios de configuración solo tienen sentido cuando se conocen ambas respuestas.

Compruebe si la clave está cifrada

Lea la primera línea del archivo y luego deje que la biblioteca lo analice, porque un nombre de archivo no demuestra nada. Un bloque PEM etiquetado ENCRYPTED PRIVATE KEY es PKCS#8 cifrado, y un bloque RSA PRIVATE KEY más antiguo que lleva Proc-Type: 4,ENCRYPTED es la forma tradicional, y ambos esperan una frase de contraseña. Un bloque PRIVATE KEY sin cifrar no debería pedir ninguna. Ejecute el análisis con la cuenta que posee el archivo, porque un problema de permisos produce un error distinto y mucho menos interesante.

Si la clave no está cifrada y el cliente sigue preguntando, deje de mirar la criptografía y compruebe si el perfil nombra un archivo askpass que el servicio todavía pueda leer.

Compruebe si esta compilación puede descifrarla

OpenSSL 3 dividió su compatibilidad con algoritmos en proveedores, y un conjunto de cifrados antiguos ahora reside en el proveedor legacy en lugar del predeterminado. Una clave cifrada con uno de esos cifrados sigue siendo válida, pero una biblioteca cargada sin el proveedor legacy no puede decodificarla. En algunos clientes eso aparece como un aviso que se repite, en otros como un fallo contundente justo después de la frase de contraseña.

Analice la misma clave dos veces con el mismo binario: primero solo con el proveedor predeterminado, luego con legacy y predeterminado solicitados ambos en la línea de comandos. Si el segundo intento tiene éxito donde falló el primero, el diagnóstico se apoya en pruebas y no en el momento de la actualización. Si ambos fallan igual, la frase de contraseña es incorrecta o el archivo está dañado, y ningún ajuste de proveedor repara ninguna de las dos cosas.

Compruebe la corrección más estrecha disponible

Prefiera un cambio limitado al cliente antes que uno de alcance sistémico. Algunas compilaciones 2.6 aceptan una opción de perfil que carga ambos proveedores para el proceso de ese daemon, así que confirme la directiva en el manual para su versión exacta antes de confiar en ella; editar el openssl.cnf del sistema afecta en cambio a todos los programas OpenSSL del host. El ajuste más estrecho también es mucho más fácil de revertir una vez que la clave se ha vuelto a codificar.

No elimine la frase de contraseña para que el aviso desaparezca. Eso convierte una credencial protegida en un archivo de texto plano y cambia en silencio el riesgo de cada copia de seguridad, copia y paquete de asistencia en los que aparezca. La distinción que importa es entre una clave que necesita su frase de contraseña y una clave que esta biblioteca no puede decodificar.

Compruebe el contexto del servicio y vuelva a codificar

Una vez que la clave se puede desbloquear, vuelva a cifrarla con un algoritmo actual para que la dependencia desaparezca. Escriba el archivo nuevo con un cifrado moderno, verifique que se analiza, actualice el perfil y conserve la copia antigua solo hasta que una conexión tenga éxito. Nunca ponga la frase de contraseña en una línea de comandos, donde cualquier usuario local puede leerla de la lista de procesos. Elimine el archivo antiguo solo después de que el nuevo se haya conectado desde la cuenta de servicio, no solo desde su shell.

Después compruebe la unidad que realmente ejecuta el cliente. Una clave legible en su shell puede ser ilegible para un servicio que se ejecuta con otra cuenta o con un ajuste de directorio personal endurecido.

Anote el ajuste del proveedor junto al perfil y guarde la prueba de dos comandos con él. Cuando una actualización posterior elimine el proveedor legacy, vuelva a ejecutar esa prueba para ver si la clave todavía lo necesita o si el perfil puede retirarse de la solución provisional.

Un aviso es un síntoma con al menos tres causas, y solo una de ellas es una frase de contraseña ausente.