partir - openssl pkcs12

Agregar un certificado intermedio a un archivo pkcs12 (2)

Añadiendo un certificado intermedio a un archivo pkcs12 ...

Así es como lo hago en mis servidores web y de correo.

Primero, www-example-com.crt es el www-example-com.crt servidor web firmado por Startcom. Startcom ofrece certificados de clase 1 gratuitos de confianza en la mayoría de los navegadores y dispositivos móviles, así que los uso. El certificado está en formato PEM ( ----- BEGIN CERT ----- y ----- END CERT ----- ).

En segundo lugar, abro www-example-com.crt y añado el Intermedio Clase 1 de Startcom. Obtengo el intermedio del Índice de certificados de Startcom. Ahora mi www-example-com.crt tiene dos www-example-com.crt codificados en PEM.

Tercero, realizo lo siguiente para crear un archivo PKCS12 / PFX para usar en IIS.

openssl pkcs12 -export -in www-example-com.crt -inkey www.example.key -out www-example-com.p12

En su caso, su www-example-com.crt tendrá al menos tres certificados codificados PEM:

----- BEGIN CERT ----- < My JBoss Certificate > ----- END CERT ----- ----- BEGIN CERT ----- < My Issuing CA > ----- END CERT ----- ----- BEGIN CERT ----- < My CA > ----- END CERT -----

El tercer certificado de la cadena, My CA , es opcional. No lo necesita si sus clientes usan My CA como un ancla de confianza. Si sus clientes utilizan Entrust como un ancla de confianza, entonces deberá incluirlo.

Si www-example-com.crt su www-example-com.crt y NO tiene múltiples certificados, entonces no continúe. No realice openssl pkcs12 hasta que su certificado de servidor tenga todos los certificados intermedios requeridos para verificar la cadena.

No incluya el certificado de CA de Entrust.

Dudo que Entrust firme con su CA directamente. Probablemente usen un intermedio, también. Por lo tanto, su cadena de certificados probablemente debería verse como:

----- BEGIN CERT ----- < My JBoss Certificate > ----- END CERT ----- ----- BEGIN CERT ----- < My Issuing CA > ----- END CERT ----- ----- BEGIN CERT ----- < My CA > ----- END CERT ----- ----- BEGIN CERT ----- < Entrust Intermediate > ----- END CERT -----

Entrusts proporciona sus certificados de CA e intermedios en los certificados de raíz de Entrust . No puedo decirle cuál necesita porque no proporcionará una URL ni nos mostrará la cadena que tiene. Pero supongo que va a ser uno o más de:

Entrust L1E Chain Certificate
Entrust L1C Chain Certificate
Entrust L1E Chain Certificate (SHA2)
Certificado de cadena L1C de Entrust (SHA2)

Puedes probar tu cadena con el `s_client de OpenSSL. Esta vez, usarás el certifcado de Entrust:

echo -e "GET / HTTP/1.0/r/n" | openssl s_client -connect myserver:8443 / -CAfile entrust-ca.pem

Puede obtener entrust-ca.pem desde Entrust Root Certificates . Ejecutalo y dinos que errores obtienes. O mejor, publique la URL en su servidor para que podamos ver lo que está pasando.

Tengo un certificado que tiene la siguiente cadena de certificación: Entrust-> My CA-> My Issuing CA-> My JBoss Certificate. Ahora, si instalo mi certificado en mi instancia de JBoss, cualquier página a la que tenga acceso que se ejecute en esta instancia aparecerá como no confiable, ya que mi navegador no reconoce mi CA emisora. Sé que mi computadora tiene la clave pública para la autoridad de firma de Entrust. ¿Cómo puedo instalar mi certificado para que cualquier navegador pueda ver toda la cadena de certificados?

Hice un solo archivo .pem de todos los certificados pensando que funcionaría. No lo hizo. ¿Alguien puede explicar lo que estoy haciendo mal o incluso si esto es posible?

Tengo un certificado que tiene la siguiente cadena de certificación: Entrust-> My CA-> My Issuing CA-> My JBoss Certificate ...

Creo que tienes dos problemas aquí. Primero está el CA firmado a la inversa, y el segundo es una cadena de clientes incompleta.

Primero, el problema fácil. El servidor debe enviar el certificado de la entidad final (servidor) y cualquier certificado intermedio para construir la cadena requerida. El servidor envía los certificados intermedios para evitar el problema de "qué directorio". El "qué directorio" es un problema bien conocido en PKI. Esencialmente, el cliente no sabe dónde ir a buscar el certificado intermedio faltante.

Entonces, su primera solución es que el servidor envíe una cadena con:

Su certificado intermedio (''Mi CA Emisora'')
Su certificado de servidor (''Mi certificado de JBoss'')

Segundo, tienes el problema de un emisor que no es de confianza. El cliente debe confiar en su CA emisora interna.

Entonces, su segunda solución es asegurarse de que su cliente confíe en su CA interna (''Mi CA''). En este caso, no es necesario que el cliente use Entrust, ya que el punto de confianza está enraizado en su CA interna.

Es posible que el servidor envíe una cadena con "Mi CA", "Mi CA emisora" y "Mi certificado JBoss". En este caso el cliente debe confiar en ''Entrust''.

Si el cliente no confía en ''Entrust'' o ''My CA'', obtendrá errores de verificación.

Hice un solo archivo .pem de todos los certificados pensando que funcionaría. No lo hizo. ¿Alguien puede explicar lo que estoy haciendo mal o incluso si esto es posible?

En este caso, deberíamos ver los certificados en un esfuerzo por ver qué está pasando. ¿Puedes publicar una URL que sirva el certificado y use la cadena? ¿Y publicar su certificado interno de CA (''Mi CA'') en línea?

Aquí hay una manera rápida y sucia de probar una conexión con s_client de OpenSSL:

echo -e "GET / HTTP/1.0/r/n" | openssl s_client -connect myserver:8443 / -CAfile my-issuing-ca.pem

OpenSSL no confía en nada por defecto (a diferencia de los navegadores), por lo que debe especificar su ancla de confianza con -CAfile .

Ese comando debe terminar con algo similar a lo siguiente.

SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 37E5AF0EE1745AB2... Session-ID-ctx: Master-Key: 7B9F8A79D3CC3A41... Key-Arg : None Start Time: 1243051912 Timeout : 300 (sec) Verify return code: 0 (ok)

Si el comando OpenSSL da como resultado OK, entonces el problema está en el navegador y el punto de confianza.