¿Por qué no puedo verificar esta cadena de certificados?


16

Tengo tres certificados en una cadena:

  • root.pem
  • intermedio.pem
  • john.pem

Cuando los examino usando, openssl x509 -in [filename] -text -nooutse ven bien, root.pem parece que está autofirmado (Emisor == Asunto), y el Asunto de cada certificado es el Emisor del siguiente, como se esperaba.

Y de hecho puedo verificar la cadena hasta el certificado intermedio:

$ openssl verify -CAfile root.pem root.pem
root.pem: OK
$ openssl verify -CAfile root.pem intermediate.pem
intermediate.pem: OK

Sin embargo, john.pem falla:

$ openssl verify -CAfile root.pem -CAfile intermediate.pem john.pem
john.pem: C = CL, [...redacted data...]
error 2 at 1 depth lookup:unable to get issuer certificate

Que yo sepa, esto significa que openssl no puede encontrar el emisor de intermediario.pem. Lo cual no tiene sentido ya que root.pem es de hecho el emisor de intermediario.pem.

¿Qué me estoy perdiendo?


Editar: Originalmente había publicado una respuesta que decía que root.pem e intermedio.pem deberían concatenarse en un archivo, y luego uno debería usar este archivo como parámetro para -CAfile. Esto es INCORRECTO, porque esto confía implícitamente en intermed.pem, como señala Johannes Pille . Lea el enlace que publicó en mi respuesta eliminada: https://mail.python.org/pipermail/cryptography-dev/2016-August/000676.html


Por favor borre su respuesta, ¡es información errónea peligrosa!
Johannes Pille

1
@JohannesPille Hecho, gracias por la información
Jong Bor

Felicitaciones por hacerlo y la reacción rápida.
Johannes Pille

Respuestas:


14

No tiene que juntar los dos certificados para verificarlos.

Si tiene los siguientes tres certificados:

  • root.pem: almacena un certificado autofirmado.
  • intermediario.pem: almacena un certificado firmado por root.pem
  • john.pem - almacena un certificado firmado por intermediario.pem

Y confía solo en root.pem, luego verificaría john.pemcon el siguiente comando:

openssl verify -CAfile root.pem -untrusted intermediate.pem john.pem

Si tuvieras muchos intermedios, podrías encadenar -untrusted intermediate2.pem -untrusted intermediate3.pem ...


Esta. Es la única respuesta correcta.
Johannes Pille

Pensé que si tuviera los Certificados de CA Intermedio y Raíz en el paquete openssl, los recogería y verificaría los certificados. ¿Hay alguna razón por la que esto estaría sucediendo? Por ejemplo, la persona que firmó el certificado de usuario no lo firmó con el Intermedio sino con la raíz, ¿o algo así?
FilBot3

La última oración de esta respuesta es incorrecta. Si tiene muchos intermedios, debe concatenarlos en un archivo intermedio y luego usar el untrustedindicador una vez. Usar la bandera no confiable varias veces no funciona.
AjaxLeung

1
@AjaxLeung: funcionan varias -untrustedopciones múltiples (en cualquier orden) o una sola -untrustedopción que apunta a un paquete de intermedios (concatenados en cualquier orden). Esto es con OpenSSL versión 1.1.1c en Ubuntu.
garethTheRed

Sí, me equivoqué. Creo que no estaba usando los archivos correctos cuando escribí el comentario.
AjaxLeung

3

lo que dijo @antiduh solo funciona para un caso de certificado intermedio único para mí. Al agregar más de uno -untrusted intermediate.pemen el comando parece que no funciona. No estoy seguro de si está relacionado con una versión específica de openssl.

De acuerdo con el documento openssl: [ https://linux.die.net/man/1/verify]

archivo no confiable

Un archivo de certificados no confiables. El archivo debe contener múltiples certificados.

En mi caso tengo una cadena como: root.pem -> intermediate1.pem -> intermediate2.pem -> john.pem

por cat intermediario1.pem e intermediario2.pem en un solo archivo intermedio-chain.pem y luego ejecutar openssl verify -CAfile root.pem -untrusted intermediate-chain.pem john.pemfunciona para mí.

También parece la extensión in ca que necesita establecer; de lo basicConstraints = CA:truecontrario, aún encuentro el error de informe de verificación de openssl.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.