Cómo crear y utilizar correctamente certificados y certificados de CA

Question

Cómo crear y utilizar correctamente certificados y certificados de CA

#1 de Pawel Veselov (2 votos)
#2 de HanC (0 votos)

12

Estoy tratando de crear un entorno con CAs con firma cruzada, y verificar un certificado emitido contra una de las CA, todas usando openssl . Lo mejor que obtuve hasta ahora es obtener openssl en un bucle sin fin mientras se verifica (el bucle termina en el nivel 100).

He publicado todos los certificados que creé . Ahora, hay una serie de suposiciones que estoy haciendo y que se basan en gran medida en este documento Oasis para construir el modelo. Aquí están mis suposiciones:

Debe haber 4 certificados, autofirmados por las autoridades # 1 y # 2, y con firma cruzada, donde la autoridad # 1 está firmada por la autoridad # 2 y viceversa.
Solo se utilizan 2 sujetos reales (DN) (el mismo sujeto utilizado por una autoridad para autofirmado es lo que ha firmado por la otra autoridad, aunque en un certificado diferente).
Los 4 certificados deben ser parte de la confianza del usuario final.
Las claves utilizadas por la misma autoridad, tanto para certificados autofirmados como para certificados cruzados deben ser el mismo
La AKI no debe usarse (puede ser "no debería" es una palabra muy fuerte, pero no usarla no debe doler. Debido a la misma regla de las teclas, no debería importar)
Intenté establecer CA: VERDADERO para certificados firmados con el mismo resultado.

Mi comprensión de la firma cruzada, es que le da al proceso de verificación rutas alternativas. Teniendo en cuenta que veo openssl loop, parece que está seleccionando certificados firmados cada vez. Entonces, el punto crucial de la pregunta es: ¿qué haría que el proceso de verificación favoreciera el certificado autofirmado sobre el firmado de forma cruzada, considerando que ambos tienen el mismo tema?

Aquí hay un certificado de hoja de prueba , no puedo hacer openssl verify para verificarlo correctamente.

[vps@druid]~/ws/EF/pki3$  openssl verify -verbose -CAfile cas.pem cert.pem 
cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 2 at 100 depth lookup:unable to get issuer certificate

public-key-infrastructure openssl x.509

pregunta Pawel Veselov 08.08.2016 - 11:18

fuente

2 respuestas

Lea otras preguntas en las etiquetas public-key-infrastructure openssl x.509

¿Qué cifrado impide la manipulación de las cookies de FedAuth de Windows Identity Foundation (WIF)? protocolo TextSecure

score 2 · Answer 1

Bien, esto es lo mejor que se me ocurrió hasta ahora.

El problema con el procesamiento en profundidad, creo, es solo de OpenSSL. No es bueno que no pueda construir caminos apropiados. RFC-5280, Sec. 6.1 dice:

Un certificado NO DEBE aparecer más de una vez en una perspectiva ruta de certificación.

OpenSSL probablemente viola eso. Sin embargo, debo decir que no veo una explicación en RFC-5280 sobre cómo crear rutas, excepto para su Sec 3.2 ; se sugiere que las rutas deben terminar con una única al final de cada cadena (esto, sin embargo, contradice con las declaraciones de que la cadena de verificación no debe tener anclas de confianza, pero las anclas de confianza pueden contener intermedios certs, que hace que el lado posterior a la cadena contenga múltiples certificados, donde OpenSSL termina con un bucle infinito). De cualquier manera, no estoy de acuerdo con lo que está haciendo OpenSSL.

También debo decir que no estaba hablando solo de certificados firmados, sino de certificados firmados mutuamente. La diferencia obvia es que la firma cruzada normal no crea tal dependencia circular, y se logra al tener un ancla de confianza de una CA firmada por otra CA (desde la perspectiva del verificador, es el mismo caso que un intermediario confiable) , AFAIU).

La forma de hacerlo funcionar con OpenSSL es no agregando certificados firmados en la lista de confianza, sino que los proporciona como parte de los certificados intermedios producidos por el titular de la clave.

Si pongo todos los autofirmados en trust.pem , todos los certificados cruzados en untrust.pem , entonces el verificador funciona, aunque arroja errores intermedios (lo que tiene sentido ya que no todos los árboles se construyen / verifican correctamente):

Aquí está con ambas raíces presentes:

$  openssl verify -verbose -CAfile trust.pem -untrusted nontrust.pem host1/cert.pem 
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 24 at 2 depth lookup:invalid CA certificate
OK

Aquí está con solo una u otra raíz presente:

$  openssl verify -verbose -CAfile ca1/ca1.pem -untrusted nontrust.pem host1/cert.pem 
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
C = US, O = Excelfore, OU = PoC, CN = xl4 CA 2
error 24 at 2 depth lookup:invalid CA certificate
OK
$  openssl verify -verbose -CAfile ca2/ca2.pem -untrusted nontrust.pem host1/cert.pem 
host1/cert.pem: C = US, O = Excelfore, OU = PoC, CN = xl4 CA 1
error 24 at 1 depth lookup:invalid CA certificate
OK

Lo que muestra la parte más interesante de la firma cruzada es que podemos atacar a una CA y seguir teniendo certificados originales.

HOWEVER

RFC-5246, Sec. 7.4.2 el documento TLS 1.2 dice que el servidor solo tiene una cadena para presentar al cliente (y viceversa). Si los certificados con firma cruzada no pueden ser parte del almacén de confianza, entonces el cliente tiene que proporcionar múltiples cadenas para que el lado verificador tenga opciones. Entonces, sí, funciona en teoría, pero no con SSL (puede funcionar con otros protocolos de verificación, no lo he comprobado), al menos en la implementación de OpenSSL.

score 0 · Answer 2

Empezaré diciendo que en mi respuesta se incluye un poco de conjeturas. Mi mejor suposición es que usted emitió 2 certificados de hoja y que el emisor de un certificado apunta al otro y al revés, lo que provoca el bucle.

No intenté reproducir tu problema yo mismo, pero sí jugué con la firma cruzada. El sitio de LE ( Cross Signing by LE ) y sus sugerencias, me permitieron emitir y utilizar certificados firmados con cruz. Mi objetivo no era la capacidad de recuperación de la raíz de CA sino la renovación de la raíz de CA. Si su rol es CA, básicamente no es muy diferente de lo que trató de lograr. Los factores críticos son:

El campo Asunto debe ser idéntico (ver arriba también)
Las claves deben ser idénticas (ver arriba también)
Los certificados deben tener un emisor diferente y 1 puede ser autofirmado, como mi solicitud

En parte, como el enlace LE, creé un certificado Intermedio con firma cruzada y un nuevo certificado raíz. Un certificado Intermedio permanente (PATHLEN: 0) está firmado por uno de los 2 certificados firmados en cruz, sin importar cuál, ya que el sujeto y las claves son idénticos. Sugerencia: reutilice la CSR de los próximos cruces para ambos, por lo que el sujeto no puede estar equivocado. En el certificado intermedio (temporal) con firma cruzada, puse el PATHLEN en 1 (¡no puede ser 0!)

Para que quede muy claro:

Ruta 1 (raíz antigua): hoja cert, perm. Certificado intermedio, temp. Certificado intermedio, certificado de raíz 'antiguo'
Ruta 2 (nueva raíz): hoja cert, perm. Certificado intermedio, 'nuevo' certificado raíz

Puedes jugar con SAN y las fechas de inicio / finalización que quieras. El certificado intermedio (temp o roll-over) en la ruta raíz "antigua" tiene una validez de 5 años, la raíz "nueva" de 10 años. Después de importar el "nuevo" certificado raíz, Firefox utilizó de inmediato la ruta más corta (4 → 3). En mi caso, necesita cargar 3 certificados en el servidor web: hoja cert, perm. certificado intermedio, temp. certificado intermedio ('antiguo' root / temp / roll-over)

OpenSSL no me decepcionó al probar el certificado de hoja para una ruta válida. Utilicé la herramienta de verificación de OpenSSL con CAfile para la raíz en la ruta y no confiable para los certificados intermedios usados. Tanto las rutas a la raíz antigua como las nuevas se podrían verificar de esta manera.

Como usuario final (no CA), si desea tener capacidad de recuperación, debería trabajar con 1 CSR para obtener (ordenar) certificados de 2 CA y cargar su servidor web con esos 2 certificados encadenados con Certificado intermedio de la CA emisora. Así que 4 certificados en total.