Importación de certificado SSL de WAF: conversión de formato JKS, PFX y PEM

Por qué el mismo certificado se niega a cargar dos veces

El certificado es real, no ha expirado, y aun así no entra en el WAF — porque el archivo en sí tiene la forma equivocada.

La mayoría de las plataformas de servidor web no almacenan los certificados como una simple clave pública, clave privada y cadena. Apache y Nginx, construidos sobre OpenSSL, son los que más se acercan — ya funcionan con archivos de tipo CRT, KEY y CER. Tomcat, WebLogic y JBoss corren sobre Java y guardan todo en un único archivo Java Keystore (JKS) construido con el Keytool del JDK. IIS de Microsoft usa el almacén de certificados de Windows y exporta como PFX. La configuración HTTPS de un WAF quiere directamente los archivos estilo OpenSSL, así que cualquier cosa que salga de un contenedor JKS o PFX debe convertirse primero — y la cadena debe viajar con ella, o el sitio seguirá inalcanzable incluso con un certificado perfectamente válido.

A continuación, la relación de conversión entre los tres formatos, los comandos exactos para cada paso, cómo generar una cadena de certificados cuando falta la del cliente, cómo distinguir un archivo de clave pública de un archivo de CA antes de cargar cualquiera de los dos, y algunas respuestas de preguntas frecuentes extraídas de casos reales de campo.

Cómo se relacionan realmente los tres formatos entre sí

JKS, PFX y PEM/KEY/CRT no son tres formatos sin relación — se sitúan en una única cadena de conversión, y toda carga de certificado de WAF termina recorriéndola desde un extremo u otro.

Saber de qué extremo se parte le indica exactamente cuántos saltos hay entre usted y una carga que realmente funcione.

Las etiquetas del diagrama se mantienen en inglés por claridad técnica.

Todo lo que está a la izquierda de PEM/KEY/CRT tiene que hacer el recorrido por este diagrama antes de que un WAF lo acepte. La cadena de certificados es un asunto aparte que viaja junto al par de clave pública/privada, no un cuarto formato en la misma cadena — y es la pieza que más a menudo se olvida.

Los pasos de conversión reales

Dos saltos, un paso de construcción de cadena si lo necesita, y una pasada de verificación antes de tocar el formulario de carga.

Paso 1 — De JKS a PFX (Keytool)

Si el certificado proviene de un servidor Tomcat, WebLogic o JBoss, está en un único archivo JKS y necesita primero un paso por Keytool.

1. Localice la utilidad Keytool del JDK en la máquina que contiene el archivo JKS — viene incluida con cualquier instalación estándar del JDK.
2. Ejecute el comando importkeystore, apuntándolo al archivo JKS de origen y nombrando el archivo PFX de destino, con el tipo de origen configurado como JKS y el tipo de destino como PKCS12.
3. Keytool solicitará la contraseña del keystore; proporcione la que usó el administrador del servidor del cliente al crear el archivo JKS.

keytool -importkeystore -srckeystore D:\server.jks -destkeystore D:\server.pfx -srcstoretype JKS -deststoretype PKCS12

Paso 2 — De PFX a PEM / KEY / CRT (OpenSSL)

Ya sea que el PFX venga del Paso 1 o directamente de un servidor IIS, este es el paso que produce los archivos que el WAF realmente quiere.

1. Copie el archivo PFX en el directorio de instalación de OpenSSL (o asegúrese de que OpenSSL esté accesible desde donde se encuentra el archivo).
2. Ejecute openssl pkcs12 para extraer todo en un único archivo PEM sin cifrar — este contiene tanto la clave privada como el certificado.
3. Ejecute openssl rsa contra ese archivo PEM para extraer solo la clave privada como su propio archivo KEY.
4. Ejecute openssl x509 contra el mismo archivo PEM para extraer solo el certificado público como su propio archivo CRT.

openssl pkcs12 -in server.pfx -nodes -out server.pem
openssl rsa -in server.pem -out server.key
openssl x509 -in server.pem -out server.crt

Paso 3 — Construir la cadena de certificados (si falta)

Cuando el certificado proviene de una CA intermedia en lugar de una autoridad raíz — el caso normal — la cadena también debe cargarse, o el sitio seguirá inalcanzable para cualquiera cuyo navegador no confíe ya en ese intermediario.

1. Verifique si el cliente ya proporcionó un archivo de cadena junto con el certificado. Si lo hizo y está intacto, pase directamente al Paso 4.
2. Si la cadena falta o se ha perdido, importe el certificado de CA del sitio en una herramienta en línea de descarga de cadena como la página chain_download de myssl.com.
3. Una vez importado el certificado de CA, use la herramienta para generar la cadena, luego descargue el archivo de cadena resultante para cargarlo junto con la clave pública y privada.

Paso 4 — Verificar antes de cargar

Un archivo que se abre sin error no es prueba de que sea el archivo correcto para el campo en el que está a punto de colocarlo.

1. Haga doble clic en cada archivo de certificado para abrirlo y revise la ruta del certificado. Un nombre de dominio en la ruta significa que está viendo la clave pública — el certificado hoja realmente emitido para este sitio.
2. Sin nombre de dominio en la ruta significa que es un certificado de CA — útil para la cadena, pero no pertenece al campo de carga de clave pública.
3. Cargue la clave pública, la clave privada y la cadena de certificados en sus campos correspondientes, habilite el descifrado HTTPS/SSL en el sitio protegido, y confirme que el sitio sea alcanzable por HTTPS antes de dar por terminado el trabajo.

4 trampas que causan la mayoría de las fallas de carga de certificados

Los comandos de conversión en sí rara vez fallan — estas cuatro cosas a su alrededor son las que realmente rompen la carga.

Diseños de soluciones relacionadas

Cinco preguntas que surgen constantemente

Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.

Límites honestos de esta nota

Lectura relacionada