Diferencias entre .pfx, .p12, .cer y .crt explicadas al detalle

Si has llegado hasta aquí buscando las diferencias entre .pfx, .p12, .cer y .crt, seguramente te hayas pegado ya con más de un fichero raro al instalar un certificado digital o un SSL en un servidor. No eres la única persona: entre siglas, extensiones y formatos, es fácil liarse y no saber qué hace cada archivo ni cuál necesitas en cada caso.

Lo bueno es que, aunque los nombres impongan respeto, todo esto se puede explicar de manera bastante sencilla si entendemos que todos estos ficheros no son más que contenedores de certificados y claves en distintos formatos (texto o binario) y pensados para diferentes sistemas (Windows, Linux, Java, navegadores, etc.). Vamos a verlos uno a uno, con calma, y a relacionarlos entre sí para que sepas exactamente qué es cada cosa, para qué sirve y cómo usarlos o convertirlos cuando haga falta.

Qué es un certificado digital y cómo encajan .pfx, .p12, .cer y .crt

Un certificado digital no es otra cosa que un documento electrónico firmado por una Autoridad de Certificación (CA o, según el reglamento eIDAS, un Prestador de Servicios Cualificado) que vincula una identidad con una clave pública. Esa identidad puede ser una persona, una empresa, un servidor web, un dominio, etc.

Para conseguir esa vinculación se usa kriptografía de clave pública o asimétrica: existe un par de claves, una pública (que cualquiera puede conocer) y una privada (que solo debe tener el titular). Lo que se cifra con la clave pública solo se descifra con la privada, y viceversa, permitiendo autenticación, cifrado y firma electrónica.

Detrás de todos estos certificados hay una infraestructura de clave pública o PKI, que incluye la autoridad de certificación, autoridades de registro, repositorios de certificados, listas de revocación (CRL) y, en muchos entornos, una autoridad de sellado de tiempo (TSA) para dejar constancia de cuándo se firmó algo.

La estructura interna de la inmensa mayoría de certificados de uso general sigue el estándar X.509, definido por la UIT y descrito en detalle en el RFC 5280. Este estándar define campos como la versión, el número de serie, el algoritmo de firma, emisor, periodo de validez, sujeto, clave pública del titular y posibles extensiones adicionales.

En cuanto a los algoritmos, los certificados suelen usar criptografía asimétrica con RSA, DSA o ECDSA. RSA y ECDSA sirven tanto para firma como para cifrado, mientras que DSA se centra en la firma y verificación de firma digital.

Formatos internos y extensiones: PEM, DER, CER, CRT y compañía

Cuando hablamos de extensiones como .cer, .crt, .pem, .der, .pfx, .p12 o .p7b, en realidad estamos mezclando dos conceptos: el formato de codificación del certificado (texto Base64 o binario) y la función que tiene ese archivo (solo certificado, certificado + clave privada, cadena de certificados, etc.).

A nivel de formato interno, los certificados X.509 se representan con ASN.1 y se codifican normalmente con DER (binario) o su variante textual PEM (DER pasado a Base64 y envuelto con cabeceras tipo BEGIN/END). A partir de ahí, distintos sistemas y estándares han definido contenedores específicos como PKCS#7 (.p7b) o PKCS#12 (.pfx, .p12).

La clave para no confundirse es recordar que la extensión del archivo muchas veces es solo una convención de nombre: un .cer o un .crt pueden contener exactamente lo mismo, solo que uno se usa más en Windows y otro en entornos Unix/Linux, por poner un ejemplo.

Dentro de este grupo general, hay algunos formatos clave que conviene tener muy claros, porque son los que te vas a encontrar todo el rato cuando trabajes con SSL/TLS o certificados personales.

Formato PEM: el “texto legible” de los certificados

El formato PEM es, con diferencia, el más habitual para certificados SSL/TLS en servidores tipo Apache o Nginx y en gran parte de las herramientas de seguridad. Un archivo PEM es simplemente un DER recodificado en Base64 y rodeado de cabeceras de texto, lo que permite abrirlo y copiarlo con cualquier editor (Bloc de notas, nano, vim, etc.).

Un PEM se reconoce porque su contenido está delimitado por líneas como —–BEGIN CERTIFICATE—– y —–END CERTIFICATE—– cuando contiene un certificado, o —–BEGIN PRIVATE KEY—– y —–END PRIVATE KEY—– cuando alberga una clave privada. Todo lo que hay en medio es una cadena Base64 que representa los datos binarios originales.

En un mismo archivo PEM puedes tener solo el certificado, el certificado más la cadena de CA intermedias, la clave privada por separado, o incluso todo el pack (clave privada, certificado del servidor, intermedios y raíz). También se suministran en PEM las solicitudes de firma de certificado CSR, que no son más que estructuras PKCS#10 recodificadas a texto.

Este formato se definió originalmente en los RFC 1421-1424 como parte del proyecto Privacy-enhanced Electronic Mail, que no cuajó para correo, pero dejó como legado un formato de texto excelente para transportar datos criptográficos de forma cómoda, legible y fácil de copiar/pegar.

En la práctica, los archivos con extensiones .pem, .crt, .cer o .key en sistemas Unix/Linux suelen ser PEM. Lo habitual es que .key contenga la clave privada, .crt o .cer el certificado del servidor y, a veces, otro archivo PEM adicional incluya la cadena de CA intermedias.

Formato DER: el binario puro y duro

DER (Distinguished Encoding Rules) es el formato binario de codificación de las estructuras ASN.1 que describen un certificado X.509. No es texto, por lo que si lo abres con un editor verás caracteres extraños en lugar de la típica cadena Base64.

Un archivo DER puede contener cualquier tipo de certificado o clave privada, y se identifica normalmente por las extensiones .der o .cer, sobre todo en entornos Windows o en plataformas Java. En Windows, un .der se reconoce directamente como un archivo de certificado y se abre con el visor nativo al hacer doble clic.

La diferencia práctica con PEM es que, mientras el PEM se puede copiar y enviar fácilmente por correo o pegar en formularios web, el DER es un blob binario cerrado pensado para consumo directo por aplicaciones. Internamente, eso sí, la información es la misma: un PEM no es más que un DER re-codificado a texto Base64.

Herramientas como OpenSSL permiten pasar de DER a PEM y viceversa con un solo comando, sin alterar en absoluto el contenido lógico del certificado, únicamente su forma de representación.

Extensiones .cer y .crt: mismo perro con distinto collar

Las extensiones .cer y .crt se utilizan para designar archivos que contienen certificados públicos, normalmente en formato PEM o DER, dependiendo del sistema en el que se generen o instalen.

En muchos casos, un .crt en un servidor Apache será un certificado en PEM rodeado de las cabeceras BEGIN/END CERTIFICATE y listo para pegarse en un bloque de configuración. En Windows, un .cer puede ser tanto PEM como DER, aunque típicamente se reparte entre ambos según la herramienta que lo haya generado.

Lo importante es entender que la extensión no define de forma estricta el formato interno: un .cer puede ser texto PEM o binario DER, y un visor o una utilidad como OpenSSL serán quienes determinen cómo leerlo. En navegadores y sistemas Windows, al hacer doble clic, se abrirá el visor de certificados, donde podrás ver el emisor, sujeto, fechas de validez, uso de clave, etc.

Cuando se exporta un certificado sin clave privada desde un navegador o desde el almacén de certificados de Windows, lo normal es que obtengas precisamente un archivo .cer, que sirve para validar firmas, cadenas de confianza o cifrar información, pero nunca para firmar en nombre del titular (para eso hace falta la clave privada, que va aparte o dentro de un contenedor protegido).

CSR, KEY, CA e intermedios: los otros ficheros que acompañan al certificado

Cuando tramitas un certificado SSL o un certificado personal, no solo vas a ver .pfx, .p12 o .cer. En todo el proceso entran también archivos como .csr, .key o los certificados de la CA (raíz e intermedios), que son igual de importantes para que todo funcione.

La solicitud de firma o CSR (.csr) es un archivo que generas normalmente en el servidor donde se instalará el SSL. Contiene la clave pública, el nombre de dominio, la organización, el país y demás datos que la autoridad de certificación usará para emitir el certificado. Sigue el estándar PKCS#10 y suele codificarse en PEM para que puedas copiarlo y pegarlo en el formulario del proveedor.

La clave privada o KEY (.key) es el archivo donde se guarda la clave secreta asociada al certificado. Suele estar en formato PEM, delimitada por BEGIN PRIVATE KEY y END PRIVATE KEY. Es un fichero extremadamente sensible, que no se debe compartir ni subir a repositorios públicos, y que en muchos casos se protege adicionalmente con contraseña.

El archivo de CA o certificado de la autoridad contiene la clave pública de la entidad que emite o intermedia el certificado. Los navegadores y sistemas operativos llevan de serie una lista de CA de confianza, pero a veces necesitas instalar certificados intermedios para que la cadena de confianza quede completa y los clientes puedan validar el certificado de tu servidor sin errores.

Estos certificados intermedios se pueden suministrar como archivos PEM (.pem, .crt, .cer) o dentro de un contenedor como .p7b. En configuraciones de hosting, es muy común que se te pidan los ficheros CRT (certificado del dominio), KEY (clave privada) y CA o certificado intermedio para dejar el SSL correctamente instalado.

PKCS#7 / P7B: cadena de certificados sin clave privada

PKCS#7, representado normalmente con extensiones .p7b o .p7c, es un formato diseñado para agrupar uno o varios certificados en un contenedor estructurado, sin incluir la clave privada. Suele usarse para distribuir cadenas de certificados (certificado de servidor más intermedios) en entornos Windows o Java (Tomcat, keystore, etc.).

Un archivo .p7b suele ir codificado en Base64 ASCII, similar a un PEM, y está definido originalmente en el RFC 2315 como parte de los estándares de criptografía de clave pública. Hoy en día, su sucesor es CMS (Cryptographic Message Syntax), pero el nombre PKCS#7 se sigue utilizando de forma generalizada en el mundo de los certificados SSL.

Este formato es muy útil cuando necesitas instalar toda la cadena de confianza en un servidor o en un sistema que gestiona certificados a través de un almacén (por ejemplo, el keystore de Java). Lo típico es que un proveedor de SSL te entregue el certificado del servidor por un lado y un .p7b con toda la cadena de CA por otro, o bien un solo .p7b con todo.

Si quieres convertir un .p7b a PEM, herramientas como OpenSSL permiten extraer los certificados con un comando y guardarlos en uno o varios archivos de texto. Después, puedes separar los bloques BEGIN/END CERTIFICATE si necesitas cargarlos por separado en tu servidor.

Es importante remarcar que un archivo PKCS#7 nunca contiene la clave privada, de modo que por sí solo no sirve para firmar o descifrar: solo aporta la parte pública de la cadena de certificados para validar confianza.

PKCS#12: qué son exactamente .pfx y .p12

El estándar PKCS#12 define un contenedor binario protegido por contraseña que puede incluir certificados públicos, cadenas completas de CA y la clave privada asociada. Las extensiones más habituales para este formato son .pfx y .p12, que a efectos prácticos son equivalentes.

Históricamente, PKCS#12 empezó como un formato muy ligado a Microsoft, pero con el tiempo se estandarizó en el RFC 7292 y hoy en día se usa en todo tipo de sistemas, precisamente porque permite transportar de forma segura el par certificado + clave privada de un equipo a otro.

En el mundo Windows, cuando exportas un certificado “con clave privada” desde el almacén de certificados del usuario o de la máquina, el asistente genera un archivo .pfx (o .p12) que incluye todo lo que necesitas para importarlo en otro sistema: clave privada, certificado del titular y, normalmente, la cadena intermedia.

Durante la creación o exportación de un PKCS#12, el sistema te pedirá que indiques una contraseña de protección. Esa contraseña será necesaria después para importar el archivo en otro navegador, en IIS, en un cliente de correo o incluso en otro sistema operativo. De este modo, si alguien roba el archivo .pfx, no podrá usarlo sin conocer esa contraseña.

Herramientas como OpenSSL permiten convertir un .pfx o .p12 a PEM, de forma que obtienes un archivo de texto donde podrás localizar fácilmente el bloque de la clave privada, el certificado del servidor y los certificados intermedios, y copiarlos donde corresponda (por ejemplo, en un panel de hosting que solo acepte CRT, KEY y CA por separado).

Renovación, exportación e importación de certificados .pfx y .p12

En el ámbito de certificados personales (por ejemplo, los emitidos por la FNMT u otras autoridades para identificarse ante la administración), la forma de hacer copias de seguridad y de renovar está muy ligada al uso de archivos .pfx o .p12, que viajan en tarjetas criptográficas, tokens USB o directamente como ficheros protegidos en el ordenador.

Si tu certificado personal todavía no ha caducado, muchas autoridades permiten renovarlo en línea: se habilita la renovación desde el punto de registro (colegio profesional, empresa, prestador de servicios de certificación, etc.) y recibes un enlace por correo para completar el proceso desde tu propio equipo.

En cambio, si el certificado ya ha caducado, normalmente tendrás que acudir presencialmente a ese mismo punto de registro con tu tarjeta criptográfica o dispositivo donde está alojado el certificado expirado, identificarte y solicitar una nueva emisión, que de nuevo podrás exportar en formato .pfx o .p12 para importar donde lo necesites.

En navegadores como Edge o Chrome, el proceso de importación pasa por el almacén de certificados de Windows. Desde la configuración de privacidad y seguridad puedes abrir el gestor de certificados, seleccionar la pestaña Personal e importar un archivo .pfx o .p12. El asistente te pedirá la contraseña del contenedor y te ofrecerá marcar la clave como exportable para futuras copias de seguridad.

Si en lugar de un .pfx tienes un archivo .cer sin clave privada (icono de certificado sin llave), ese archivo solo sirve para instalar el certificado público (aparece en “Otras personas”), pero no para firmar ni autenticarse. En ese caso, no tendrás forma de recuperar la clave privada desde ahí y, si no conservas otra copia válida, la única opción será solicitar un nuevo certificado.

Cómo se usan estos formatos en certificados SSL de servidor

En el día a día con servidores web, VPN, proxies o aplicaciones Java, los distintos formatos de certificados se usan en función del sistema y del tipo de instalación. No es lo mismo montar un Apache en Linux que un IIS en Windows o un Tomcat en Java.

En entornos Unix/Linux (Apache, Nginx, HAProxy, etc.) lo normal es trabajar con ficheros PEM separados: uno para la clave privada (.key), otro para el certificado del servidor (.crt o .cer) y, en ocasiones, otro más con la cadena de CA intermedia. Todo ello se referencia desde la configuración del servidor para levantar el TLS.

En plataformas Windows (IIS, servicios de escritorio remoto, etc.) es muy frecuente que te pidan un .pfx o .p12 que contenga tanto el certificado como la clave privada y la cadena. El asistente de importación se encarga de colocar cada pieza en su almacén correspondiente, sin que tengas que preocuparte de los detalles internos.

En entornos Java (Tomcat, aplicaciones con keystore propio) se utilizan almacenes tipo JKS o PKCS#12. En muchos casos se importa directamente un .pfx, o bien se trabaja con certificados en .p7b para configurar la cadena de confianza dentro de un keystore, según la herramienta y la versión de Java.

Cuando contratas un SSL con un proveedor externo, puedes recibir diferentes combinaciones de archivos: CRT + CA en PEM, un .p7b con la cadena, o incluso un .pfx ya preparado. Lo fundamental es identificar dónde está la clave privada (si es que viene contigo y no la genera el servidor) y qué archivo contiene el certificado de servidor y la cadena intermedia.

En paneles de hosting, lo más habitual es que se te pidan campos para pegar el CRT, la KEY y, opcionalmente, el certificado CA o intermedio. Si solo tienes un .pfx, puedes convertirlo a PEM con OpenSSL y extraer desde ahí cada bloque, copiando cuidadosamente desde BEGIN hasta END de cada tipo.

Conversión entre formatos de certificados con OpenSSL

Una vez que tienes claro qué es cada archivo, el siguiente paso lógico es saber cómo convertirlos cuando el servidor o la aplicación te piden un formato distinto del que te ha facilitado tu proveedor o tu CA. La herramienta estándar para esto es OpenSSL, disponible en la mayoría de distribuciones Linux y también instalable en Windows.

Por ejemplo, si tienes un certificado en DER (.der, .cer) y necesitas pasarlo a PEM, bastaría con un comando que tome ese binario y lo recodifique a Base64 con las cabeceras apropiadas. Del mismo modo, puedes transformar un PEM a DER si tu sistema solo acepta binario.

Con un archivo PKCS#7 (.p7b), puedes usar OpenSSL para extraer los certificados en formato PEM con un simple comando que imprima los certificados contenidos y los guarde en un archivo de texto. A partir de ahí, separas los distintos bloques BEGIN/END CERTIFICATE si necesitas archivos individuales.

En el caso de PKCS#12 (.pfx, .p12), OpenSSL permite convertir el contenedor a un archivo PEM que contenga la clave privada y todos los certificados. Durante el proceso se te pedirá la contraseña del contenedor y podrás elegir si quieres dejar la clave privada cifrada o en claro dentro del PEM, según el uso que vayas a darle después.

Este tipo de conversiones son las que hacen posible escenarios como subir un .pfx a un servidor Linux, convertirlo a PEM y luego separar CRT y KEY para rellenar un formulario de instalación de SSL que no admite directamente contenedores PKCS#12.

Además de conversiones directas DER↔PEM, PEM↔PKCS#7, PKCS#7↔PKCS#12 y PKCS#12↔PEM, la misma utilidad sirve para generar CSR, gestionar claves, inspeccionar certificados y comprobar fechas de caducidad, lo que la convierte en una pieza básica en cualquier entorno que trabaje con certificados.

Tipos de certificados digitales y ámbitos de uso

Más allá del formato de archivo, también es útil tener clara la tipología de certificados según su uso o el tipo de entidad a la que representan, ya que eso influye en cómo se gestionan sus copias, renovaciones e instalaciones.

A nivel normativo europeo (Reglamento eIDAS), se distingue entre certificados electrónicos “simples” y certificados cualificados. Los primeros cumplen unos requisitos básicos de identificación y emisión, mientras que los cualificados exigen procesos más estrictos de verificación de identidad y unas condiciones técnicas y organizativas más rigurosas por parte del prestador. Un ejemplo claro en España sería el DNI electrónico.

Si miramos quién es el titular, podemos tener certificados de persona física, persona jurídica o entidad sin personalidad jurídica. Cada uno sirve para firmar o autenticarse en ámbitos distintos: trámites personales, gestiones en nombre de una empresa u obligaciones tributarias, respectivamente.

En el mundo de los servidores web, la familia de certificados más conocida es la de certificados SSL/TLS, que se instalan en los servidores para cifrar el canal de comunicación con los usuarios. Dentro de ellos, hay variantes como los certificados de dominio único, wildcard o multidominio (SAN), que difieren en el número de nombres que cubren y en el nivel de validación.

Independientemente del tipo, todos estos certificados pueden acabar guardados y distribuidos en los mismos formatos: archivos .cer, .crt, .pem, .p7b o contenedores .pfx/.p12, según el sistema donde se vayan a usar y el método elegido para transportarlos o hacer copias de seguridad.

La utilidad de los certificados digitales es enorme: aseguran la confidencialidad y autenticidad de las comunicaciones, permiten firmas electrónicas con validez legal, simplifican trámites administrativos y comerciales y hacen posible que múltiples servicios en red funcionen de forma segura sin que el usuario tenga que preocuparse de los detalles criptográficos.

A estas alturas ya se puede ver que extensiones como .pfx, .p12, .cer o .crt no son más que distintas formas de empaquetar esa misma realidad: un certificado X.509, una clave privada y, en su caso, una cadena de confianza, que según el entorno se representan como texto Base64, binario DER o contenedores PKCS para facilitar la instalación y el transporte entre sistemas.