¿Cómo cambiar sin problemas el formato de los certificados digitales?

Puntos Clave

• PEM, DER, PFX/PKCS#12 y P7B/PKCS#7 son los cuatro formatos de certificado entre los que realizará conversiones con mayor frecuencia, y cada uno se corresponde con plataformas de servidor específicas.
• OpenSSL gestiona todas las rutas de conversión comunes con un solo comando; el cambio de nombre de la extensión de un archivo solo funciona dentro de la familia PEM (.pem, .crt, .cer, .key).
• Realice una copia de seguridad de los archivos originales y registre una suma de verificación antes de convertir cualquier elemento que incluya una clave privada.
• Valide cada certificado convertido con OpenSSL antes de implementarlo y tenga lista la ruta de reversión.
• La conversión manual no resulta escalable más allá de un puñado de certificados; CertSecure Manager automatiza la conversión de formato y la exportación como parte del ciclo de vida del certificado.

Publicado: julio de 2021. Actualizado: agosto de 2026. Revisado por el equipo de Operaciones PKI de Encryption Consulting.

¿Qué formatos de certificados digitales existen y qué significa cada uno?

Un certificado digital mantiene la misma estructura de datos X.509 subyacente, independientemente de cómo se almacene; el formato solo cambia la forma en que se codifican esos datos en el disco y con qué se incluyen. Todos los operadores de PKI empresariales se encuentran regularmente con cuatro formatos:

• PEM (Correo electrónico con privacidad mejorada): Un archivo PEM es un formato de texto codificado en Base64 ASCII delimitado por las líneas “—–BEGIN CERTIFICATE—–” y “—–END CERTIFICATE—–”. Puede contener un certificado, una clave privada o una cadena completa, uno tras otro. Extensiones comunes: .pem, .crt, .cer, .key, .ca-bundle. Utilizado por Apache, Nginx y la mayoría de las aplicaciones basadas en OpenSSL.
• DER (Reglas de codificación distinguidas): Codificación binaria de los mismos datos X.509, sin líneas de encabezado BEGIN/END. Debido a su naturaleza binaria, no se puede editar ni concatenar un archivo DER de forma segura en un editor de texto. Extensiones comunes: .der, .cer. Utilizado por los almacenes de claves de Java y algunos flujos de importación binaria de Windows.
• PFX/PKCS#12: Archivo binario protegido con contraseña (PFX es el nombre que Windows le da a un archivo PKCS#12) que incluye el certificado del servidor, la cadena intermedia y la clave privada en un solo archivo. Extensiones comunes: .pfx, .p12. Utilizado por Windows, IIS y Exchange para importar y exportar datos.
• P7B/PKCS#7: Formato de cadena de certificados codificado en Base64, delimitado por las líneas “—–BEGIN PKCS7—–” y “—–END PKCS7—–”. No puede almacenar una clave privada, solo certificados y una Lista de Revocación de Certificados (CRL). Extensiones comunes: .p7b, .p7c. Utilizado por Java Tomcat y los flujos de trabajo de importación de cadenas de Windows.

Ningún formato es más seguro ni más correcto que otro; el contenido criptográfico del certificado es idéntico en todos ellos. El formato necesario viene determinado exclusivamente por las expectativas de la plataforma de destino, por lo que la conversión de formato es una tarea operativa rutinaria y no una decisión de seguridad.

¿Qué necesitas antes de convertir el formato de un certificado?

Confirme estos cinco puntos antes de ejecutar cualquier comando de conversión en un certificado que esté activo en un sistema de producción.

• OpenSSL está instalado y su versión ha sido confirmada. Ejecutar openssl version Primero. OpenSSL 3.x movió el cifrado PKCS#12 antiguo (RC2, 3DES) a un proveedor heredado, por lo que un PFX exportado hace años puede necesitar el -legacy Se ha añadido una bandera al comando.
• Acceso a la clave privada al convertir a o desde PFX/PKCS#12, y confirmación de quién está autorizado para manejarlo.
• Una copia de seguridad verificada del certificado original y los archivos de clave., copiado a una ubicación separada antes de que se ejecute cualquier comando, además de una suma de verificación registrada (consulte la sección de registro a continuación).
• El formato exacto requerido por el sistema de destino, confirmado con la tabla de decisiones que aparece más abajo en esta página, en lugar de asumirse.
• Un entorno de preparación o ventana de mantenimiento para probar el archivo convertido antes de que reemplace el certificado en un servicio de producción.

¿Cómo se convierten los formatos de certificado utilizando OpenSSL?

Cada conversión que se muestra a continuación corresponde a un único comando de OpenSSL. Ejecute cada comando sobre su copia de seguridad, no sobre el archivo que está utilizando actualmente un servicio en producción.

Paso a paso: Conversión de PEM a DER

1. Copiar certificate.pem a un directorio de trabajo y confirme que se abre como texto Base64 legible.
2. Ejecutar: openssl x509 -outform der -in certificate.pem -out certificate.der
3. Confirmar certificate.der Fue creado y es binario (no se abrirá correctamente como texto).

Paso a paso: Convierta DER a PEM

1. Confirme que el archivo fuente sea realmente un binario codificado en DER antes de ejecutar el comando; una extensión .cer puede ser PEM o DER.
2. Ejecutar: openssl x509 -inform der -in certificate.der -out certificate.pem
3. Abra certificate.pem en un editor de texto y confirme que ahora muestra “—–BEGIN CERTIFICATE—–“.

Paso a paso: Convertir PEM a PFX (PKCS#12)

1. Confirma que tienes el certificado (certificate.crt), su clave privada correspondiente (privateKey.key), y, si está disponible, el archivo de cadena de CA (CAcert.crt).
2. Ejecutar: openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CAcert.crt
3. Introduzca una contraseña de exportación segura cuando se le solicite. -certfile CAcert.crt Este indicador es opcional; úselo para agrupar la cadena intermedia en el archivo PFX, de modo que el sistema de destino no la necesite por separado.

Paso a paso: Convertir PFX a PEM

1. Confirma que tienes el archivo PFX y su contraseña de exportación.
2. Ejecutar: openssl pkcs12 -in certificate.pfx -out certificate.pem -nodes
3. OpenSSL solicitará la contraseña PFX y, a continuación, escribirá el certificado, la cadena y la clave privada sin cifrar en un único archivo PEM. Ábralo con un editor de texto y divídalo en archivos separados para el certificado y la clave si la plataforma de destino lo requiere, manteniendo intactos todos los bloques “—–BEGIN—–“/”—–END—–”.
4. Necesario -nodes Si desea que la clave privada extraída permanezca cifrada con una frase de contraseña dentro de la salida PEM.

Para el formato de cadena P7B/PKCS#7: convierta PEM a P7B con openssl crl2pkcs7 -nocrl -certfile certificate.cer -certfile CAcert.cer -out certificate.p7b (el segundo -certfile es opcional, se utiliza para agrupar un certificado de cadena adicional), y extraer certificados de un P7B de vuelta a PEM con openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer. Debido a que P7B no puede contener una clave privada, la conversión de P7B a PFX es un proceso de dos pasos: extraiga los certificados con el comando anterior y luego ejecute openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CAcert.cer utilizando la clave privada que ya tienes a mano.

Un atajo seguro es el siguiente: cambiar el nombre de un archivo entre .pem, .crt, .cer y .key no modifica la codificación Base64 subyacente, por lo que un simple cambio de nombre funciona dentro de esa familia. No funciona entre familias. Cambiar el nombre de un archivo PEM a .der no lo convierte en DER binario, y cambiar el nombre de un archivo de certificado a .pfx no incluye la clave privada. Si es necesario cambiar la codificación o el contenido del archivo, ejecute el comando OpenSSL correspondiente mencionado anteriormente.

¿Cómo se valida un certificado convertido?

Valida el resultado antes de que llegue a un servicio de producción. Ejecuta estas comprobaciones en el archivo convertido:

• Confirme que el certificado se analiza correctamente y verifique sus detalles: openssl x509 -in certificate.pem -text -noout (utilizar -inform der (para un archivo DER). Revise el sujeto, el emisor, las fechas de validez y los nombres alternativos del sujeto con respecto a lo que espera.
• Verificar la cadena de confianza: openssl verify -CAfile ca-bundle.pem certificate.pem debería regresar certificate.pem: OK.
• Confirme que el certificado y la clave privada coinciden. comparando sus módulos: openssl x509 -noout -modulus -in certificate.pem | openssl md5 y openssl rsa -noout -modulus -in privateKey.key | openssl md5 debe producir una salida idéntica.
• Inspeccione un paquete PFX sin exportar su contenido: openssl pkcs12 -info -in certificate.pfx -nooutLuego, confirme que el certificado, la cadena y la clave estén presentes.

Solo después de que se superen todas las comprobaciones anteriores se deberá implementar el archivo convertido, e incluso entonces, deberá implementarse en una ventana de mantenimiento con la posibilidad de revertir los cambios de inmediato.

¿Cuál es el procedimiento de reversión si una conversión causa algún problema?

Mantenga los archivos originales del certificado y la clave intactos en una ubicación de copia de seguridad separada y con control de acceso durante todo el período de cambio, y no los sobrescriba ni los elimine hasta que el archivo convertido haya estado activo y verificado en producción durante un período de observación definido (generalmente de 24 a 72 horas). Si un servicio no se inicia, presenta un error de cadena o un cliente rechaza el nuevo certificado, revierta la conversión restaurando el archivo original a su ruta original, revirtiendo cualquier cambio de configuración que apuntara al nuevo formato y reiniciando el servicio afectado. Luego, vuelva a ejecutar las comprobaciones de validación anteriores con el archivo original restaurado antes de cerrar el incidente. Nunca intente una segunda conversión en vivo para "corregir" una implementación fallida; primero revierta la conversión, diagnostique con la copia de seguridad y vuelva a intentarlo en la siguiente ventana de mantenimiento.

¿Qué información debe registrar durante un cambio de formato de certificado?

Trate cada cambio de formato de certificado como un evento auditable, no como un comando único. Registre lo siguiente para cada conversión, ya sea que se realice manualmente o mediante automatización:

• Fecha y hora, identificación del operador y número de cambio o de ticket que autoriza el trabajo.
• Formato de origen, formato de destino y el comando OpenSSL exacto ejecutado (eliminando cualquier contraseña del registro).
• Una suma de verificación (por ejemplo, sha256sum certificate.pem) tanto del archivo original como del archivo convertido, de modo que se pueda demostrar que la conversión no ha alterado la identidad del certificado.
• El sistema y el servicio de destino en el que se implementó el certificado convertido, y el resultado de cada comprobación de validación.
• Confirmación de que el archivo original se conservó y dónde, para fines de reversión.

Este registro es lo que un auditor solicita según las normas ISO/IEC 27001:2022 o los controles de gestión de cambios SOC 2, y marca la diferencia entre un cambio operativo justificable y una sustitución de certificado inexplicable en un sistema de producción.

¿Cuáles son los errores más comunes en la conversión de certificados y cómo se solucionan?

Error o síntoma	Causa probable	Solución
OpenSSL solicita repetidamente una contraseña que usted no tiene	La clave privada PFX o PEM de origen está protegida con una contraseña, pero esta no se proporcionó o es desconocida.	Localice la contraseña original de quien emitió el certificado; si realmente no se puede recuperar, vuelva a emitir el certificado en lugar de intentar eludir la contraseña.
Errores como "no se puede cargar el certificado" o "no hay línea de inicio".	El archivo no es realmente un archivo PEM (a menudo es un archivo DER con extensión .cer o .pem, o una descarga corrupta).	Confirme la codificación real con una comprobación hexadecimal/de texto y, a continuación, utilice la coincidencia. -inform der or -inform pem bandera en lugar de adivinar
“no se pudo obtener el certificado del emisor local” durante openssl verify	Falta el certificado CA intermedio en el paquete de cadena pasado a -CAfile	Reconstruya el paquete de CA con los certificados intermedios y raíz correctos, en el orden correcto, y vuelva a ejecutar la verificación.
La exportación o importación de PKCS#12 falla en OpenSSL 3.x para un archivo PFX antiguo.	El PFX estaba cifrado con RC2 o 3DES, lo que OpenSSL 3.x trasladó a un proveedor heredado.	Agregar el formulario -legacy bandera a la openssl pkcs12 comando, o vuelva a exportar el PFX con un cifrado actual una vez que pueda descifrarlo.
Los valores del módulo del certificado y de la clave privada no coinciden después de la conversión.	Se utilizó un archivo de clave incorrecto o se convirtió el certificado incorrecto.	Vuelva a ejecutar la conversión utilizando el par clave/certificado correcto confirmado de la copia de seguridad y vuelva a comprobar la comparación del módulo.
La plataforma de destino sigue rechazando el certificado convertido.	El formato coincidía, pero la cadena requerida (certificados intermedios) no se incluyó en la salida.	Vuelva a ejecutar la exportación con -certfile señalando la cadena intermedia completa y confirme con openssl pkcs12 -info or openssl x509 -text que la cadena está presente

¿Qué resultados operativos cabe esperar de un proceso de conversión bien gestionado?

Un cambio de formato de certificado que siga los pasos de prerrequisitos, validación, reversión y registro mencionados anteriormente debería producir resultados medibles, no solo "funcionó":

• Cero tiempos de inactividad no planificados en el servicio de destino, porque el certificado convertido se validó según los requisitos de la plataforma antes de la implementación, no después.
• Una tasa de aprobación de validación del 100 por ciento. antes de que cualquier certificado convertido llegue a producción, verificado con el openssl verify y las comprobaciones de coincidencia de módulo anteriores.
• Un registro de cambios completo y auditable Para cada conversión, se satisfacen las solicitudes de evidencia de gestión del cambio sin trabajo de reconstrucción adicional.
• Un tiempo medio documentado para revertir dentro del período de observación definido para el cambio, en lugar de una intervención improvisada si algo se rompe.

¿Qué formato de certificado requiere cada plataforma?

Formato	Codificación	Caso de uso típico	Sistemas comunes
PEM (.pem, .crt, .cer, .key)	Texto ASCII en base64	Archivos de certificado, cadena y clave separados, servidos directamente por el servidor web.	Apache, Nginx, la mayoría de los servicios de Linux/Unix, aplicaciones basadas en OpenSSL
DER (.der, .cer)	Binario	Aplicaciones que requieren la estructura binaria X.509 sin encabezados.	Almacenes de claves de Java (a través de keytool), algunos sistemas embebidos e IoT, ciertos flujos de importación binaria de Windows.
PFX/PKCS#12 (.pfx, .p12)	Paquete binario protegido con contraseña	Transferencia de certificado, cadena y clave privada en un solo archivo.	Windows Server, IIS, Exchange, importación de llavero de macOS, secretos TLS de Kubernetes creados a partir de un paquete
P7B/PKCS#7 (.p7b, .p7c)	Texto ASCII en Base64, sin clave privada.	Distribuir una cadena de certificados sin exponer ningún material clave.	Importación de la cadena de Windows e IIS, importación del almacén de confianza de Java Tomcat

¿Cuáles son las limitaciones de la conversión manual del formato de los certificados?

El manual de OpenSSL anterior es fiable para un certificado o un lote pequeño y planificado, pero tiene limitaciones importantes a gran escala. El material de la clave privada pasa por comandos de shell y, si no se tiene cuidado, por el historial de shell y los registros de scripts, lo que supone un riesgo de exposición innecesario. El comportamiento de OpenSSL varía entre versiones principales, como el requisito de proveedor heredado 3.x para archivos PKCS#12 antiguos, y un script escrito para una versión puede fallar silenciosamente con otra. La conversión manual no tiene un registro de auditoría integrado; el operador debe aplicar la disciplina de registro anterior en cada ocasión, y es lo primero que se omite bajo presión de plazos. Nada de esto es escalable para los miles de certificados que una empresa mediana suele gestionar en múltiples plataformas y entornos de nube.

¿Qué recomendaría Encryption Consulting?

Para un número limitado de certificados, los comandos de OpenSSL mencionados anteriormente son la herramienta adecuada. Más allá de eso, la conversión manual de formatos se convierte en el riesgo operativo que este manual pretende controlar: claves privadas gestionadas manualmente, pasos de validación que dependen de que una persona recuerde ejecutarlos y ninguna fuente única de información sobre qué certificado está en qué formato y en qué servidor.

CertSecure Manager elimina por completo el paso manual: emite, renueva y exporta certificados directamente en el formato que requiere la plataforma de destino, ya sea un paquete PEM para Nginx o un PFX protegido con contraseña para IIS, sin que un operador tenga que modificar la clave privada en la línea de comandos. Cada exportación se registra automáticamente, la agrupación de cadenas se gestiona por usted y las discrepancias de formato se detectan antes de la implementación, en lugar de descubrirse como una interrupción en producción. Cuando los certificados se emiten a través de una CA administrada en lugar de una local, PKI-as-a-Service extiende el mismo modelo automatizado de emisión y exportación sin necesidad de gestionar la infraestructura de la CA. Si desea comprobar el contenido de un certificado antes o después de una conversión sin instalar nada, las herramientas gratuitas de EC, OpenSSL CSR and Certificate Decoder y ASN.1 CSR and Certificate Decoder , analizan y muestran los campos del certificado directamente en el navegador. Encryption Consulting cuenta con las certificaciones ISO/IEC 27001:2022 y SOC 2, por lo que el mismo registro de auditoría que se le pide que cree manualmente en este manual es una función integrada de los registros del ciclo de vida de los certificados de CertSecure Manager.

Para ver un ejemplo práctico relacionado que utiliza estos mismos comandos de OpenSSL durante la renovación de un certificado, consulte Renovación de certificados en Apache con CertSecure Manager . Para obtener un tutorial más detallado sobre la conversión de PFX a PEM, consulte Cómo convertir sin problemas un archivo de certificado codificado en PFX a formato PEM con OpenSSL.

Conclusión

Cambiar el formato de un certificado digital es una tarea operativa rutinaria si se trata como un procedimiento establecido en lugar de un comando puntual: confirmar los requisitos reales de la plataforma de destino, hacer una copia de seguridad de los originales, ejecutar el comando OpenSSL correcto, validar el resultado y registrar los cambios. Esta disciplina es lo que evita que una migración de certificados se convierta en una interrupción del servicio. A medida que el número de certificados que se gestionan supera la capacidad de un operador para realizar un seguimiento manual de forma segura, automatizar la emisión y exportación en el formato correcto para cada plataforma, con CertSecure Manager o una plataforma PKI-as-a-Service equivalente, es lo que garantiza la fiabilidad de este proceso a gran escala.

Preguntas frecuentes

¿Cuál es la diferencia entre los formatos de certificado PEM y DER? PEM (Privacy-Enhanced Mail) es un formato codificado en Base64 ASCII delimitado por las líneas “—–BEGIN CERTIFICATE—–” y “—–END CERTIFICATE—–”, comúnmente utilizado por Apache, Nginx y aplicaciones basadas en OpenSSL. DER (Distinguished Encoding Rules) es la forma binaria de los mismos datos X.509 sin líneas de encabezado, comúnmente requerida por los almacenes de claves de Java y algunas importaciones binarias de Windows. Puede convertir entre ellos con un solo comando de OpenSSL en cualquier dirección.

¿Puedo convertir un certificado sin OpenSSL? Para los formatos de la familia PEM (.pem, .crt, .cer, .key), cambiar la extensión del archivo funciona porque la codificación Base64 subyacente no cambia. No se puede convertir a o desde una codificación realmente diferente, como PEM a DER o PEM a PFX, simplemente cambiando la extensión, ya que esos formatos usan una codificación a nivel de bytes diferente o incluyen datos adicionales como una clave privada. Se requiere OpenSSL, o una biblioteca equivalente, para una conversión de formato real.

¿Es seguro convertir un archivo PFX que contiene una clave privada? Sí, siempre que se maneje la clave privada con el mismo cuidado que el archivo original. Mantenga la contraseña del archivo PFX y cualquier clave privada PEM exportada fuera del historial de comandos y del control de versiones, restrinja los permisos de archivo a la cuenta que los necesite y elimine los archivos intermedios descifrados una vez finalizada la conversión y la validación.

¿Qué formato de certificado necesitan IIS o Windows en comparación con Apache o Nginx? Windows Server, IIS y Exchange suelen requerir un archivo PFX (PKCS#12) porque este agrupa el certificado, su cadena y la clave privada en un único archivo protegido con contraseña. Apache y Nginx esperan archivos separados codificados en PEM para el certificado, la cadena y la clave privada. La conversión entre ambos formatos es uno de los cambios de formato de certificado más comunes que realizan los equipos de operaciones durante una migración de servidor.

¿Qué debo hacer si OpenSSL me pide una contraseña que desconozco durante la conversión? Esta solicitud indica que el archivo de origen está cifrado, normalmente un archivo PFX o una clave privada PEM con una frase de contraseña. Si la contraseña es realmente desconocida, no podrá descifrar el archivo con OpenSSL y deberá volver a emitir el certificado desde la autoridad de certificación o el sistema que lo generó originalmente. Nunca intente descifrar la contraseña mediante fuerza bruta ni eludirla en una clave de producción.

Referencias

• OpenSSL, Documentación de OpenSSL
• IETF, RFC 5280: Certificado de infraestructura de clave pública X.509 de Internet y perfil CRL
• IETF, RFC 7292: PKCS #12: Sintaxis de intercambio de información personal v1.1