PKCS12, PEM ou DER: que necesita realmente un cliente VPN

Nos debates sobre certificados circulan dúas afirmacións. A primeira é que un .p12 é a opción forte e un .pem a feble; a segunda, que un ficheiro de texto debe ser seguro de enviar porque pode lelo. Ningunha resiste un minuto de inspección.

PKCS12, PEM e DER describen como se empaquetan e codifican os obxectos de certificado. Non deciden quen é o par, se o emisor é de confianza nin se o ficheiro necesita contrasinal.

O que acepta o cliente é unha cuestión de compatibilidade. O que contén o ficheiro é unha cuestión de identidade. Sepáreas e a maioría dos erros de importación deixarán de ser misteriosos.

Tres contedores, un modelo de obxecto

Comece polo que realmente ten. Un certificado é unha declaración asinada sobre unha clave pública. A clave privada é material separado que demostra que controla esa clave. Unha cadea é o conxunto de emisores que ligan o seu certificado cunha raíz na que confía o cliente. Os tres existen independentemente do empaquetado.

Un ficheiro PKCS12, normalmente .p12 ou .pfx, é un contedor definido en RFC 7292 que pode levar unha clave privada, un ou varios certificados e a cadea nun só bloque protexido por contrasinal, cun alias que nomea a identidade. Un ficheiro PEM é un marco de texto definido en RFC 7468: un corpo base64 entre liñas BEGIN e END, e un ficheiro pode conter varios bloques en secuencia. DER é a codificación binaria das mesmas estruturas ASN.1, e o corpo PEM é literalmente DER envolto en base64.

Esa última frase merece recordarse. Converter PEM en DER reescribe o envoltorio, non o contido, e converter de volta devolve os bytes orixinais.

Codificar non é cifrar

Base64 é un alfabeto de transporte. Non oculta nada e calquera pode decodificar un bloque PEM nun shell. Un ficheiro DER é binario e igual de público. Ningunha das dúas propiedades é protección e ningunha implica que exista un contrasinal.

A protección real vive no material da clave. Un paquete PKCS12 pode cifrar o seu contido cunha clave derivada dun contrasinal. Unha clave privada PEM pode cifrarse cun bloque de cabeceira antigo ou gardarse en PKCS#8 EncryptedPrivateKeyInfo. Un certificado por si só non garda nada secreto, por iso unha exportación que só produciu un certificado deixa o cliente incapaz de autenticarse, sexa cal sexa o formato co que o envolva.

A extensión é unha pista, non un contrato. Os ficheiros rematados en .cer e .crt aparecen nas dúas codificacións, e os equipos exportan certificados DER con nomes .pem con suficiente frecuencia como para que adiviñar polo sufixo custe unha tarde. Lea os primeiros bytes no seu lugar: un ficheiro PEM comeza cunha liña BEGIN, mentres que DER comeza con 0x30 porque a estrutura exterior é unha SEQUENCE.

Por que falla realmente a importación

As mensaxes de erro do cliente comprimen varios problemas distintos nunha frase sobre un certificado non válido, así que sepáreos por causa. O máis común é un desaxuste de codificación: un cliente que analiza PEM devolve un erro de análise cun ficheiro DER, e a solución é unha conversión, non un certificado novo. O segundo é unha clave ausente, onde o certificado está ben e a identidade non se pode probar. O terceiro é a cadea, onde un paquete sen o seu intermedio parece correcto no diálogo de importación e falla durante o handshake.

Os parámetros de cifrado causan un cuarto, e parece exactamente un contrasinal incorrecto. Os equipos antigos exportaban ficheiros PKCS12 con RC2-40 e 3DES, que OpenSSL 3 rexeita salvo que se cargue o provedor legacy. Reexportar desde o equipo con AES-256-CBC e PBKDF2 é a solución duradeira. Deixar cifrados antigos activados de forma permanente nunha máquina cliente para acomodar un ficheiro é un mal negocio.

O quinto é a ambigüidade. Un contedor con dúas claves e dous certificados, ou un ficheiro PEM con tres bloques CERTIFICATE, obriga o cliente a elixir, e a súa elección adoita ser simplemente o primeiro elemento. Cando un túnel se levanta coa identidade equivocada, normalmente é esa a razón.

Inspeccione antes de converter

Lea a estrutura sen imprimir segredos. openssl pkcs12 -in bundle.p12 -info -noout informa dos algoritmos de cifrado e dos alias mentres suprime a saída de clave e certificado, e o manual de openssl-pkcs12 documenta os indicadores. Quitar -noout e engadir -nodes serve para producir ficheiros que pensa gardar, non para unha ollada rápida, porque escribe a clave privada en claro.

Para un certificado, openssl x509 -in cert.pem -noout -subject -issuer -dates responde o que un diálogo de importación non responderá, e engadir -ext subjectAltName mostra os nomes para os que o certificado é realmente válido. Se o ficheiro é DER, engada -inform DER; ese único indicador resolve a maioría dos erros unable-to-load.

Emparellar unha clave cun certificado é mecánico, e paga a pena facelo antes de calquera importación:

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

Dixestos idénticos significan que a parella vai xunta. Dixestos distintos significan que ten a clave equivocada, e ningunha conversión de formato o cambiará.

O que o formato nunca cambia

As decisións de confianza ocorren por riba do contedor. O cliente percorre a cadea ata unha raíz do seu almacén, comproba a xanela de validez, comproba o uso estendido da clave para a autenticación do cliente e, no lado do servidor, comproba que o nome ao que marcou aparece no certificado. Ningún deses pasos le unha extensión de ficheiro.

Por iso renomear un ficheiro ata que un erro desaparece é unha forma tan fiable de perder tempo. A importación ten éxito, a identidade segue sendo incorrecta e o fallo reaparece durante o handshake, onde a mensaxe é menos útil. Tamén por iso un paquete exportado hai dous anos se importa limpiamente e aínda así se rexeita: a data de caducidade viaxaba dentro do certificado, non no nome do ficheiro.

Unha orde que evita refacer traballo

Pregunte á documentación do cliente que codificacións acepta e que contedor espera para unha identidade de cliente, e despois mire o que lle entregaron. Se o cliente quere unha única identidade importable e vostede ten ficheiros PEM soltos, constrúa o paquete unha vez cun contrasinal que controle e garde as fontes. Se quere PEM, extraia a clave e a cadea, e despois elimine os ficheiros intermedios mediante o proceso de xestión de credenciais que o seu equipo xa usa.

Despois de importar, verifique a identidade en lugar do diálogo: suxeito, emisor, caducidade e o nome que presentará o cliente. Un nome amable nunha lista é unha etiqueta, non unha identidade verificada. Se logo falla o túnel, está depurando autenticación ou encamiñamento en lugar de empaquetado, que é unha conversación moito máis curta.