Antes de convertelo: clave SSH fronte a certificado OpenVPN

A importación falla cun erro de certificado, así que o movemento obvio parece unha conversión. Ese instinto leva a xente por un camiño no que a extensión do ficheiro cambia e o rexeitamento segue exactamente igual. Unha liña ssh-ed25519 en authorized_keys e un certificado de cliente OpenVPN son obxectos de credenciais distintos, con emisores distintos, codificacións distintas e rutas de revocación distintas. Percorrer estas comprobacións en orde dille nun minuto se a conversión pode axudar sequera.

Que obxecto ten en realidade?

Hai cinco cousas que a xente chama clave, e só unha delas é o que quere un perfil TLS. Unha clave pública SSH é unha soa liña de texto cun prefixo de tipo e unha carga base64. Un certificado OpenSSH é esa clave máis unha sinatura, principals e opcións, producidos por ssh-keygen actuando como a súa propia CA pequena. Un certificado X.509 é unha estrutura completamente distinta, que leva un suxeito, unha xanela de validez, extensións e unha sinatura dunha autoridade de certificación. Unha clave privada é a metade secreta, e un paquete emitido adoita ser un certificado máis a súa cadea máis a clave privada nun só ficheiro.

A primeira proba custa un comando. Apunte openssl ao ficheiro e pídalle que analice a estrutura do certificado:

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

Se iso falla cun erro de non se pode cargar ou PEM, o ficheiro non é un certificado X.509 diga o que diga o nome que lle puxo. Cambiar o nome non reescribe o ASN.1 interno, e envolver unha liña de clave pública en texto de cabeceira PEM tampouco o fai.

Pide o perfil un certificado sequera?

Os certificados de cliente son un método de autenticación entre varios, e moitos perfís TLS que funcionan nunca piden un. Un servidor pode autenticar usuarios mediante un complemento, un nome de usuario e contrasinal, ou un backend de tokens, mentres segue esixindo ao cliente que verifique a identidade do servidor. Se o perfil non leva unha directiva de certificado de cliente, nunca se pedirá un certificado, e ningunha conversión fará que a pasarela pida un.

As configuracións antigas de clave estática son un terceiro caso. Son anteriores ao apretón de mans TLS e esperan un ficheiro de segredo compartido de antemán, e por iso pegar unha clave pública nese campo tampouco pode funcionar. Lea que pide realmente o perfil antes de decidir que a credencial é incorrecta.

Que pode e que non pode facer a recodificación

As claves privadas si teñen contedores alternativos lexítimos. A mesma clave RSA ou EC pode escribirse como PEM tradicional, como PKCS#8 ou dentro dun paquete PKCS#12, e as ferramentas converterán entre eles con gusto. As claves públicas teñen unha historia parecida: ssh-keygen pode emitir a forma RFC 4716 dunha clave SSH, e OpenSSH tamén entende o seu propio formato de certificado. Todo iso é representación, e a representación non é confianza.

O que a conversión non pode facer é crear unha sinatura dunha autoridade de certificación que nunca viu a súa clave. Un certificado é unha afirmación dun emisor de que unha clave pública concreta pertence a un suxeito concreto para un propósito concreto. A recodificación conserva os bytes da clave e deixa ausente a afirmación, así que a pasarela non ten nada que validar contra o seu almacén de confianza.

Este é o paso onde a maioría dos intentos fallan en silencio: o ficheiro agora remata en .crt, o cliente léoo sen queixarse, e o apretón de mans segue abortando porque o par non pode construír unha cadea ata un emisor de confianza.

Onde entra en escena a autoridade de certificación

A alta real comeza cun par de claves que vostede controla e unha solicitude de sinatura de certificado que leva o suxeito que o operador espera. O operador verifica o dereito, asina a solicitude coa clave da CA e devolve o certificado emitido xunto con calquera cadea intermedia que o cliente deba presentar. Despois o cliente necesita o certificado da CA que o asinou, porque é o que lle permite confirmar que o servidor co que fala pertence á mesma despregadura.

Ese último ficheiro é fácil de esquecer e imposible de substituír. A clave de sinatura da CA nunca pertence á configuración do cliente, e ningunha cantidade de conversión local produce a cadea que debía ter recibido.

Que lle custa reutilizar a clave SSH

Supoña que unha conversión si produciu algo aceptable. Reutilizar un par de claves para o acceso SSH e a autenticación VPN segue acoplando dúas decisións de seguridade independentes. Quitar unha entrada de authorized_keys detén os inicios de sesión SSH e non fai nada a un certificado que a CA da VPN xa emitiu para a mesma clave pública. O lado VPN revógase mediante o seu propio mecanismo, é dicir, a lista de revocación de certificados ou o rexistro de alta do operador.

Así que a lista de comprobación remata cunha condición de parada en lugar dun truco. Se openssl non analiza o ficheiro como certificado, deixe de converter e describa o que ten: clave SSH, certificado SSH, certificado X.509, clave privada ou paquete. Se o perfil non pide un certificado de cliente, pare e pregunte que método de autenticación espera o servidor. Só cando ambas respostas apuntan a X.509 se converte a alta no seguinte paso, e esa conversa vai moito máis rápido co substantivo correcto na primeira frase.