Antes de converter: chave SSH ou certificado OpenVPN

A importação falha com um erro de certificado, então o passo óbvio parece uma conversão. Esse instinto leva as pessoas por um caminho em que a extensão do arquivo muda e a rejeição continua exatamente igual. Uma linha ssh-ed25519 em authorized_keys e um certificado de cliente OpenVPN são objetos de credencial separados, com emissores diferentes, codificações diferentes e caminhos de revogação diferentes. Percorrer estas verificações em ordem diz em um minuto se a conversão pode ajudar.

Qual objeto você realmente tem?

Há cinco coisas que as pessoas chamam de chave, e só uma delas é o que um perfil TLS quer. Uma chave pública SSH é uma única linha de texto com um prefixo de tipo e uma carga base64. Um certificado OpenSSH é essa chave mais uma assinatura, principals e opções, produzidos pelo ssh-keygen atuando como sua própria CA pequena. Um certificado X.509 é uma estrutura completamente diferente, que carrega um sujeito, uma janela de validade, extensões e uma assinatura de uma autoridade certificadora. Uma chave privada é a metade secreta, e um pacote emitido costuma ser um certificado mais a sua cadeia mais a chave privada em um único arquivo.

O primeiro teste custa um comando. Aponte o openssl para o arquivo e peça que ele analise a estrutura do certificado:

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

Se isso falhar com um erro de não foi possível carregar ou PEM, o arquivo não é um certificado X.509 qualquer que seja o nome que você deu. Renomear não reescreve o ASN.1 interno, e envolver uma linha de chave pública em texto de cabeçalho PEM também não.

O perfil pede um certificado sequer?

Certificados de cliente são um método de autenticação entre vários, e muitos perfis TLS que funcionam nunca pedem um. Um servidor pode autenticar usuários por meio de um plugin, de um nome de usuário e senha, ou de um backend de tokens, enquanto ainda exige que o cliente verifique a identidade do servidor. Se o perfil não traz uma diretiva de certificado de cliente, nenhum certificado será pedido, e nenhuma conversão fará o gateway pedir um.

As configurações antigas de chave estática são um terceiro caso. Elas antecedem o handshake TLS e esperam um arquivo de segredo pré-compartilhado, e é por isso que colar uma chave pública nesse campo também não pode funcionar. Leia o que o perfil realmente pede antes de decidir que a credencial está errada.

O que a recodificação pode e não pode fazer

Chaves privadas têm contêineres alternativos legítimos. A mesma chave RSA ou EC pode ser escrita como PEM tradicional, como PKCS#8 ou dentro de um pacote PKCS#12, e as ferramentas convertem entre eles sem hesitar. Chaves públicas têm uma história parecida: o ssh-keygen pode emitir a forma RFC 4716 de uma chave SSH, e o OpenSSH também entende o seu próprio formato de certificado. Tudo isso é representação, e representação não é confiança.

O que a conversão não pode é criar uma assinatura de uma autoridade certificadora que nunca viu a sua chave. Um certificado é uma afirmação de um emissor de que uma determinada chave pública pertence a um determinado sujeito para uma determinada finalidade. A recodificação preserva os bytes da chave e deixa a afirmação ausente, então o gateway não tem o que validar contra o seu repositório de confiança.

Este é o passo em que a maioria das tentativas falha em silêncio: o arquivo agora termina em .crt, o cliente o lê sem reclamar, e o handshake ainda aborta porque o par não consegue construir uma cadeia até um emissor confiável.

Onde entra a autoridade certificadora

O registro real começa com um par de chaves que você controla e uma solicitação de assinatura de certificado que carrega o sujeito esperado pelo operador. O operador verifica o direito, assina a solicitação com a chave da CA e devolve o certificado emitido junto com qualquer cadeia intermediária que o cliente precise apresentar. Depois o cliente precisa do certificado da CA que o assinou, porque é ele que permite confirmar que o servidor com quem fala pertence à mesma implantação.

Esse último arquivo é fácil de esquecer e impossível de substituir. A chave de assinatura da CA nunca pertence à configuração do cliente, e nenhuma quantidade de conversão local produz a cadeia que você deveria ter recebido.

O que custa reutilizar a chave SSH

Suponha que uma conversão tenha mesmo produzido algo aceitável. Reutilizar um par de chaves para o acesso SSH e para a autenticação VPN ainda acopla duas decisões de segurança independentes. Remover uma entrada de authorized_keys interrompe os logins SSH, e não faz nada a um certificado que a CA da VPN já emitiu para a mesma chave pública. O lado VPN é revogado pelo seu próprio mecanismo, ou seja, pela lista de revogação de certificados ou pelo registro de inscrição do operador.

Por isso a lista de verificação termina com uma condição de parada em vez de um truque. Se o openssl não analisar o arquivo como certificado, pare de converter e descreva o que você tem: chave SSH, certificado SSH, certificado X.509, chave privada ou pacote. Se o perfil não pedir certificado de cliente, pare e pergunte qual método de autenticação o servidor espera. Só quando as duas respostas apontam para X.509 o registro passa a ser o próximo passo, e essa conversa anda muito mais rápido com o substantivo certo na primeira frase.