Antes de convertirlo: clave SSH frente a certificado OpenVPN

La importación falla con un error de certificado, así que el movimiento obvio parece una conversión. Ese instinto lleva a la gente por un camino en el que la extensión del archivo cambia y el rechazo sigue exactamente igual. Una línea ssh-ed25519 en authorized_keys y un certificado de cliente OpenVPN son objetos de credenciales distintos, con emisores distintos, codificaciones distintas y rutas de revocación distintas. Recorrer estas comprobaciones en orden le dice en un minuto si la conversión puede ayudar siquiera.

¿Qué objeto tiene en realidad?

Hay cinco cosas que la gente llama clave, y solo una de ellas es lo que quiere un perfil TLS. Una clave pública SSH es una sola línea de texto con un prefijo de tipo y una carga base64. Un certificado OpenSSH es esa clave más una firma, principals y opciones, producidos por ssh-keygen actuando como su propia CA pequeña. Un certificado X.509 es una estructura completamente distinta, que lleva un sujeto, una ventana de validez, extensiones y una firma de una autoridad de certificación. Una clave privada es la mitad secreta, y un paquete emitido suele ser un certificado más su cadena más la clave privada en un solo archivo.

La primera prueba cuesta un comando. Apunte openssl al archivo y pídale que analice la estructura del certificado:

openssl x509 -in client.crt -noout -subject -issuer

Si eso falla con un error de no se puede cargar o de PEM, el archivo no es un certificado X.509 diga lo que diga el nombre que le puso. Cambiar el nombre no reescribe el ASN.1 interno, y envolver una línea de clave pública en texto de cabecera PEM tampoco lo hace.

¿Pide el perfil un certificado siquiera?

Los certificados de cliente son un método de autenticación entre varios, y muchos perfiles TLS que funcionan nunca piden uno. Un servidor puede autenticar usuarios mediante un complemento, un nombre de usuario y contraseña, o un backend de tokens, mientras sigue exigiendo al cliente que verifique la identidad del servidor. Si el perfil no lleva una directiva de certificado de cliente, nunca se pedirá un certificado, y ninguna conversión hará que la pasarela pida uno.

Las configuraciones antiguas de clave estática son un tercer caso. Son anteriores al apretón de manos TLS y esperan un archivo de secreto compartido de antemano, y por eso pegar una clave pública en ese campo tampoco puede funcionar. Lea qué pide realmente el perfil antes de decidir que la credencial es incorrecta.

Qué puede y qué no puede hacer la recodificación

Las claves privadas sí tienen contenedores alternativos legítimos. La misma clave RSA o EC puede escribirse como PEM tradicional, como PKCS#8 o dentro de un paquete PKCS#12, y las herramientas convertirán entre ellos con gusto. Las claves públicas tienen una historia parecida: ssh-keygen puede emitir la forma RFC 4716 de una clave SSH, y OpenSSH también entiende su propio formato de certificado. Todo eso es representación, y la representación no es confianza.

Lo que la conversión no puede hacer es crear una firma de una autoridad de certificación que nunca ha visto su clave. Un certificado es una afirmación de un emisor de que una clave pública concreta pertenece a un sujeto concreto para un propósito concreto. La recodificación conserva los bytes de la clave y deja ausente la afirmación, así que la pasarela no tiene nada que validar contra su almacén de confianza.

Este es el paso donde la mayoría de los intentos fallan en silencio: el archivo ahora termina en .crt, el cliente lo lee sin quejarse, y el apretón de manos sigue abortando porque el par no puede construir una cadena hasta un emisor de confianza.

Dónde entra en escena la autoridad de certificación

El alta real empieza con un par de claves que usted controla y una solicitud de firma de certificado que lleva el sujeto que el operador espera. El operador verifica el derecho, firma la solicitud con la clave de la CA y devuelve el certificado emitido junto con cualquier cadena intermedia que el cliente deba presentar. Después el cliente necesita el certificado de la CA que lo firmó, porque es lo que le permite confirmar que el servidor con el que habla pertenece al mismo despliegue.

Ese último archivo es fácil de olvidar e imposible de sustituir. La clave de firma de la CA nunca pertenece a la configuración del cliente, y ninguna cantidad de conversión local produce la cadena que debía haber recibido.

Qué le cuesta reutilizar la clave SSH

Suponga que una conversión sí produjo algo aceptable. Reutilizar un par de claves para el acceso SSH y la autenticación VPN sigue acoplando dos decisiones de seguridad independientes. Quitar una entrada de authorized_keys detiene los inicios de sesión SSH y no hace nada a un certificado que la CA de la VPN ya emitió para la misma clave pública. El lado VPN se revoca mediante su propio mecanismo, es decir, la lista de revocación de certificados o el registro de alta del operador.

Así que la lista de comprobación termina con una condición de parada en lugar de un truco. Si openssl no analiza el archivo como certificado, deje de convertir y describa lo que tiene: clave SSH, certificado SSH, certificado X.509, clave privada o paquete. Si el perfil no pide un certificado de cliente, pare y pregunte qué método de autenticación espera el servidor. Solo cuando ambas respuestas apuntan a X.509 se convierte el alta en el siguiente paso, y esa conversación va mucho más rápido con el sustantivo correcto en la primera frase.