PKCS12, PEM o DER: qué necesita realmente un cliente VPN

En los debates sobre certificados circulan dos afirmaciones. La primera es que un .p12 es la opción fuerte y un .pem la floja; la segunda, que un archivo de texto debe ser seguro de enviar porque puede leerlo. Ninguna resiste un minuto de inspección.

PKCS12, PEM y DER describen cómo se empaquetan y codifican los objetos de certificado. No deciden quién es el par, si el emisor es de confianza ni si el archivo necesita contraseña.

Lo que acepta el cliente es una cuestión de compatibilidad. Lo que contiene el archivo es una cuestión de identidad. Sepárelas y la mayoría de los errores de importación dejarán de ser misteriosos.

Tres contenedores, un modelo de objeto

Empiece por lo que realmente tiene. Un certificado es una declaración firmada sobre una clave pública. La clave privada es material separado que demuestra que usted controla esa clave. Una cadena es el conjunto de emisores que enlazan su certificado con una raíz en la que confía el cliente. Los tres existen independientemente del empaquetado.

Un archivo PKCS12, normalmente .p12 o .pfx, es un contenedor definido en RFC 7292 que puede llevar una clave privada, uno o varios certificados y la cadena en un solo bloque protegido con contraseña, con un alias que nombra la identidad. Un archivo PEM es un marco de texto definido en RFC 7468: un cuerpo base64 entre líneas BEGIN y END, y un archivo puede contener varios bloques en secuencia. DER es la codificación binaria de las mismas estructuras ASN.1, y el cuerpo PEM es literalmente DER envuelto en base64.

Esa última frase merece recordarse. Convertir PEM a DER reescribe el envoltorio, no el contenido, y convertir de vuelta devuelve los bytes originales.

Codificar no es cifrar

Base64 es un alfabeto de transporte. No oculta nada y cualquiera puede decodificar un bloque PEM en una shell. Un archivo DER es binario e igual de público. Ninguna de las dos propiedades es protección y ninguna implica que exista una contraseña.

La protección real vive en el material de la clave. Un paquete PKCS12 puede cifrar su contenido con una clave derivada de una contraseña. Una clave privada PEM puede cifrarse con un bloque de cabecera antiguo o guardarse en PKCS#8 EncryptedPrivateKeyInfo. Un certificado por sí solo no guarda nada secreto, por eso una exportación que solo produjo un certificado deja al cliente incapaz de autenticarse, sea cual sea el formato con que lo envuelva.

La extensión es una pista, no un contrato. Los archivos terminados en .cer y .crt aparecen en ambas codificaciones, y los equipos exportan certificados DER con nombres .pem con la suficiente frecuencia como para que adivinar por el sufijo cueste una tarde. Lea los primeros bytes en su lugar: un archivo PEM empieza con una línea BEGIN, mientras que DER empieza con 0x30 porque la estructura exterior es una SEQUENCE.

Por qué falla realmente la importación

Los mensajes de error del cliente comprimen varios problemas distintos en una frase sobre un certificado no válido, así que sepárelos por causa. El más común es un desajuste de codificación: un cliente que analiza PEM devuelve un error de análisis con un archivo DER, y la solución es una conversión, no un certificado nuevo. El segundo es una clave ausente, donde el certificado está bien y la identidad no puede probarse. El tercero es la cadena, donde un paquete sin su intermedio parece correcto en el diálogo de importación y falla durante el handshake.

Los parámetros de cifrado causan un cuarto, y parece exactamente una contraseña incorrecta. Los equipos antiguos exportaban archivos PKCS12 con RC2-40 y 3DES, que OpenSSL 3 rechaza salvo que se cargue el proveedor legacy. Reexportar desde el equipo con AES-256-CBC y PBKDF2 es la solución duradera. Dejar cifrados antiguos habilitados de forma permanente en una máquina cliente para acomodar un archivo es un mal negocio.

El quinto es la ambigüedad. Un contenedor con dos claves y dos certificados, o un archivo PEM con tres bloques CERTIFICATE, obliga al cliente a elegir, y su elección suele ser simplemente el primer elemento. Cuando un túnel se levanta con la identidad equivocada, normalmente es esa la razón.

Inspeccione antes de convertir

Lea la estructura sin imprimir secretos. openssl pkcs12 -in bundle.p12 -info -noout informa de los algoritmos de cifrado y los alias mientras suprime la salida de clave y certificado, y el manual de openssl-pkcs12 documenta los indicadores. Quitar -noout y añadir -nodes sirve para producir archivos que piensa guardar, no para un vistazo rápido, porque escribe la clave privada en claro.

Para un certificado, openssl x509 -in cert.pem -noout -subject -issuer -dates responde lo que un diálogo de importación no responderá, y añadir -ext subjectAltName muestra los nombres para los que el certificado es realmente válido. Si el archivo es DER, añada -inform DER; ese único indicador resuelve la mayoría de los errores unable-to-load.

Emparejar una clave con un certificado es mecánico, y merece hacerse antes de cualquier importación:

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

Digeridos idénticos significan que la pareja va junta. Digeridos distintos significan que tiene la clave equivocada, y ninguna conversión de formato lo cambiará.

Lo que el formato nunca cambia

Las decisiones de confianza ocurren por encima del contenedor. El cliente recorre la cadena hasta una raíz de su almacén, comprueba la ventana de validez, comprueba el uso extendido de la clave para la autenticación del cliente y, en el lado del servidor, comprueba que el nombre al que marcó aparece en el certificado. Ninguno de esos pasos lee una extensión de archivo.

Por eso renombrar un archivo hasta que un error desaparece es una forma tan fiable de perder tiempo. La importación tiene éxito, la identidad sigue siendo incorrecta y el fallo reaparece durante el handshake, donde el mensaje es menos útil. También por eso un paquete exportado hace dos años se importa limpiamente y aun así se rechaza: la fecha de caducidad viajaba dentro del certificado, no en el nombre del archivo.

Un orden que evita rehacer trabajo

Pregunte a la documentación del cliente qué codificaciones acepta y qué contenedor espera para una identidad de cliente, y luego mire lo que le han entregado. Si el cliente quiere una única identidad importable y usted tiene archivos PEM sueltos, construya el paquete una vez con una contraseña que controle y guarde las fuentes. Si quiere PEM, extraiga la clave y la cadena, y después elimine los archivos intermedios mediante el proceso de gestión de credenciales que su equipo ya utiliza.

Después de importar, verifique la identidad en lugar del diálogo: sujeto, emisor, caducidad y el nombre que presentará el cliente. Un nombre amable en una lista es una etiqueta, no una identidad verificada. Si luego falla el túnel, está depurando autenticación o enrutamiento en lugar de empaquetado, que es una conversación mucho más corta.