PKCS12, PEM ou DER: o que um cliente VPN realmente precisa

Nas discussões sobre certificados circulam duas afirmações. A primeira é que um .p12 é a opção forte e um .pem a frouxa; a segunda, que um arquivo de texto deve ser seguro de enviar porque você pode lê-lo. Nenhuma resiste a um minuto de inspeção.

PKCS12, PEM e DER descrevem como os objetos de certificado são empacotados e codificados. Não decidem quem é o par, se o emissor é confiável nem se o arquivo exige senha.

O que o cliente aceita é uma questão de compatibilidade. O que o arquivo contém é uma questão de identidade. Separe as duas e a maioria dos erros de importação deixa de ser misteriosa.

Três contêineres, um modelo de objeto

Comece pelo que você realmente tem. Um certificado é uma declaração assinada sobre uma chave pública. A chave privada é material separado que prova que você controla essa chave. Uma cadeia é o conjunto de emissores que ligam seu certificado a uma raiz em que o cliente confia. Os três existem independentemente do empacotamento.

Um arquivo PKCS12, geralmente .p12 ou .pfx, é um contêiner definido na RFC 7292 que pode carregar uma chave privada, um ou mais certificados e a cadeia em um único bloco protegido por senha, com um alias que nomeia a identidade. Um arquivo PEM é um enquadramento de texto definido na RFC 7468: um corpo base64 entre linhas BEGIN e END, e um arquivo pode conter vários blocos em sequência. DER é a codificação binária das mesmas estruturas ASN.1, e o corpo PEM é literalmente DER envolto em base64.

Essa última frase vale a pena guardar. Converter PEM em DER reescreve o invólucro, não o conteúdo, e a conversão de volta devolve os bytes originais.

Codificar não é criptografar

Base64 é um alfabeto de transporte. Não esconde nada, e qualquer pessoa pode decodificar um bloco PEM num shell. Um arquivo DER é binário e igualmente público. Nenhuma das duas propriedades é proteção, e nenhuma implica que exista uma senha.

A proteção real está no material da chave. Um pacote PKCS12 pode criptografar seu conteúdo com uma chave derivada de uma senha. Uma chave privada PEM pode ser criptografada com um bloco de cabeçalho antigo ou guardada em PKCS#8 EncryptedPrivateKeyInfo. Um certificado sozinho não guarda nada secreto, por isso uma exportação que só produziu um certificado deixa o cliente incapaz de autenticar, seja qual for o formato em que você o embrulhe.

A extensão é uma pista, não um contrato. Arquivos terminados em .cer e .crt aparecem nas duas codificações, e os equipamentos exportam certificados DER com nomes .pem com frequência suficiente para que adivinhar pelo sufixo custe uma tarde. Leia os primeiros bytes: um arquivo PEM começa com uma linha BEGIN, enquanto DER começa com 0x30 porque a estrutura externa é uma SEQUENCE.

Por que a importação realmente falha

As mensagens de erro do cliente comprimem vários problemas diferentes numa frase sobre um certificado inválido, então separe-os por causa. O mais comum é um descompasso de codificação: um cliente que analisa PEM devolve um erro de análise num arquivo DER, e a correção é uma conversão, não um certificado novo. O segundo é uma chave ausente, quando o certificado está correto e a identidade não pode ser provada. O terceiro é a cadeia, quando um pacote sem o intermediário parece certo na caixa de importação e falha durante o handshake.

Os parâmetros de criptografia causam um quarto, e ele parece exatamente uma senha errada. Equipamentos antigos exportavam arquivos PKCS12 com RC2-40 e 3DES, que o OpenSSL 3 recusa a menos que o provedor legacy esteja carregado. Reexportar do equipamento com AES-256-CBC e PBKDF2 é a correção durável. Deixar cifras antigas ativas permanentemente numa máquina cliente para acomodar um arquivo é um mau negócio.

O quinto é a ambiguidade. Um contêiner com duas chaves e dois certificados, ou um arquivo PEM com três blocos CERTIFICATE, força o cliente a escolher, e sua escolha costuma ser simplesmente o primeiro item. Quando um túnel sobe com a identidade errada, normalmente é essa a razão.

Inspecione antes de converter

Leia a estrutura sem imprimir segredos. openssl pkcs12 -in bundle.p12 -info -noout informa os algoritmos de criptografia e os aliases enquanto suprime a saída de chave e certificado, e o manual do openssl-pkcs12 documenta as opções. Remover -noout e adicionar -nodes serve para produzir arquivos que você pretende guardar, não para uma olhada rápida, porque grava a chave privada em texto claro.

Para um certificado, openssl x509 -in cert.pem -noout -subject -issuer -dates responde o que uma caixa de importação não responderá, e adicionar -ext subjectAltName mostra os nomes para os quais o certificado é realmente válido. Se o arquivo for DER, adicione -inform DER; esse único sinalizador resolve a maioria dos erros unable-to-load.

Casar uma chave com um certificado é mecânico, e vale a pena antes de qualquer importação:

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in key.pem -pubout | openssl sha256

Digeridos idênticos significam que o par combina. Digeridos diferentes significam que você tem a chave errada, e nenhuma conversão de formato mudará isso.

O que o formato nunca muda

As decisões de confiança acontecem acima do contêiner. O cliente percorre a cadeia até uma raiz do seu armazenamento, verifica a janela de validade, verifica o uso estendido da chave para autenticação do cliente e, no lado do servidor, verifica se o nome para o qual discou aparece no certificado. Nenhum desses passos lê uma extensão de arquivo.

Por isso renomear um arquivo até que um erro desapareça é uma forma tão confiável de perder tempo. A importação tem sucesso, a identidade continua errada e a falha reaparece durante o handshake, onde a mensagem é menos útil. Também por isso um pacote exportado há dois anos é importado sem problemas e ainda assim rejeitado: a data de expiração viajava dentro do certificado, não no nome do arquivo.

Uma ordem que evita retrabalho

Pergunte à documentação do cliente quais codificações ele aceita e qual contêiner espera para uma identidade de cliente, e então veja o que lhe foi entregue. Se o cliente quer uma única identidade importável e você tem arquivos PEM soltos, monte o pacote uma vez com uma senha que você controla e guarde as fontes. Se quer PEM, extraia a chave e a cadeia, e depois remova os arquivos intermediários pelo processo de tratamento de credenciais que seu time já usa.

Depois da importação, verifique a identidade em vez da caixa de diálogo: sujeito, emissor, expiração e o nome que o cliente apresentará. Um nome amigável numa lista é um rótulo, não uma identidade verificada. Se o túnel falhar depois, você está depurando autenticação ou roteamento em vez de empacotamento, o que é uma conversa bem mais curta.