El certificado de CA raíz de SSL no se reconoce, aunque esté presente en el almacén de confianza. ¿Por qué?

Fondo:

Ubuntu Server 14.10 de 64 bits en aws.amazon.com/ec2
Certificado de servidor PositiveSSL barato de COMODO
1 certificado de servidor, 2 certificados de CA intermedios y 1 certificado de CA raíz como archivo ZIP de COMODO
Citadel WebSite https

Problema:

La cadena de certificados concatenados parece ser correcta pero la verificación falla.

openssl s_client myhost:port

muestra la cadena de certificados y los pares emisor-sujeto alineados correctamente a través de la cadena, pero:

verify error:num=19:self signed certificate in certificate chain

El certificado raíz CA no es aceptado por openssl, aunque se encuentra por defecto en el almacén de confianza del servidor Ubuntu.

Específicamente: AddTrustExternalCARoot.crt recibido por correo electrónico de COMODO y /etc/ssl/certs/AddTrust_External_Root.pem que enlaza con /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt Son identicos.

¿Que esta mal aquí?

linux ssl certificate

— Reinhard Seifert
fuente

Si usa Firefox o Chrome para conectarse a su sitio, ¿recibe alguna advertencia de certificado?

— John Siu

No Firefox. Estoy utilizando Citadel.org como un servidor de correo electrónico y los certificados SSL son para SMTPS en los puertos 465 y 587. De hecho, Thunderbird no se queja.

— Reinhard Seifert

El problema de Firefox desencadenó mi publicación aquí. Oh hombre, estoy cansado. Entonces, Thunderbird no se queja en SMTPS, pero Firefox no muestra la página HTML y supongo que es el certificado, porque al usar openssl s_client el html de la página aparece y w3m también muestra la página después quejándose del certificado no confiable. Pero Firefox simplemente no muestra la página, sin ninguna advertencia sobre el certificado.

— Reinhard Seifert

Prueba la prueba del navegador con otro dispositivo. También use la última versión si es posible. Estoy empezando a adivinar que la computadora utilizada para la prueba necesita la actualización del paquete raíz de CA.

— John Siu

¡Gracias chicos! Probé en otra máquina y ahora funciona tanto en Firefox como en Thunderbird. Dicho esto parece que la respuesta de jotaps es correcta. Aunque es aún más raro con openssl: openssl verify -CAfile chained.crt chained.crt pasa "OK" (chained.crt es el certificado encadenado con certificado de servidor, certificados intermedios y certificado de CA raíz)! Para mí esto es un comportamiento inconsistente y extraño de openssl. La cadena de certificados es correcta, el último certificado está en el almacén de confianza y openssl lo reconoce como un único certificado y como un archivo de CA, pero no cuando es el último en una cadena. ¿Es esto un error?

— Reinhard Seifert

Respuestas:

OpenSSL al menos hasta la corriente (1.0.2a) tiene un insecto dónde s_client con ningún -CA{path,file} argumento en realidad no usa el almacén de confianza predeterminado como debería y, por lo tanto, no puede verificar los certificados que son válidos de acuerdo con ese almacén de confianza. (También s_server y s_time, pero preocuparse por la verificación en esos casos es raro.) Ver https://serverfault.com/questions/607233/how-to-make-openssl-s-client-using-default-ca . Se anuncia una solución en dev, pero puede tardar un tiempo en ser lanzado y distribuido. Mientras tanto, debe especificar explícitamente la -CA* argumento (s) Tenga en cuenta que openssl verify no tiene este error y, por lo tanto, informó correctamente el certificado / cadena como válido.

Actualizaciones 26/08/2015: arreglo fue lanzado 12/06/2015 en 1.0.1o y 1.0.2c. Además, mientras investigaba algo más encontré que Los paquetes de RedHat pueden haber estado bien . Más específicamente la fuente de RPM de CentOS para openssl-1.0.1e-30.el6.11 Lo que entiendo es una copia de la RedHat que contiene (pero no puedo confirmar fácilmente) openssl-1.0.1c-default-paths.patch que contiene cambios a s_client.c s_server.c s_time.c con fecha 2012/12/06 que parecen equivalentes a (aunque no textualmente lo mismo que) las correcciones ascendentes de 2015/06/12. Asumiendo que este parche se aplicó en los paquetes RedHat y CentOS, que no puedo volver atrás y verificar fácilmente, funcionarían (ed) como se esperaba.

— dave_thompson_085
fuente

Gracias. Eso aclaró el asunto y, de hecho, fue por una vez que no me estropeé las cosas ... en el navegador y en MUA se acepta la cadena.

— Reinhard Seifert

Recientemente tuve un problema similar con los certificados de Comodo cuando desarrollé un script con Ruby. Al final, fue que OpenSSL no lo tenía en la tienda, aunque parecía que sí.

Para probar esto, descargue todos los certificados intermedios de Comodo y cree un paquete de certificados algo como esto (deberá usar diferentes nombres de certificados según lo que haya descargado):

cat EssentialSSLCA_2.crt ComodoUTNSGCCA.crt UTNAddTrustSGCCA.crt AddTrustExternalCARoot.crt > yourDomain.ca-bundle

Comodo tiene un artículo sobre cómo hacer esto.

Una vez hecho esto, intente verificar el certificado nuevamente usando OpenSSL y especificando el almacén de certificados en la línea de comando:

openssl verify -untrusted yourDomain.ca-bundle cert.pem

Ese ejemplo fue adaptado de este artículo de Unix y Linux StackExchange .

Una vez que haya determinado qué certificado es, debería ser posible agregar el certificado al almacén de certificados local, que se detalla aquí para Ubuntu , y es algo como:

Cree un directorio para certificados de CA adicionales en / usr / share / ca-certificate

sudo mkdir /usr/share/ca-certificates/extra

Copie el archivo '.crt' al directorio

sudo cp foo.crt /usr/share/ca-certificates/extra/foo.crt

Permita que Ubuntu agregue la ruta del archivo '.crt' relativa a / usr / share / ca-certificate a /etc/ca-certificates.conf

sudo dpkg-reconfigure ca-certificates

— jotap
fuente

Esta es mi suposición también, por eso le pido a OP que pruebe con un navegador Chrome o Firefox.

— John Siu

"Al final, fue que OpenSSL no lo tenía en la tienda ..." - OpenSSL no tiene una tienda. Tiene que decirle explícitamente qué usar como un ancla de confianza. OpenSSL no es como los navegadores que confían en casi cualquier cosa que se les lance.

— jww

Gracias por sus respuestas inmediatas y comentarios chicos. Mañana lo miraré más de cerca. Entiendo el punto. Pero: al hacer openssl verify AddTrustExternalRootCA.crt (que es el culpable al final de la cadena) solo para el certificado raíz, luego pasa "OK", es decir, openssl conoce muy bien los certificados vinculados en / etc / ssl / certs.

— Reinhard Seifert

... y sí, al concatenar los certificados de CA intermedios y raíz en CAbundle.crt y probar openssl verify -CAfile CAbundle.crt myserver_com.crt Luego pasa la prueba "OK".

— Reinhard Seifert

@jww OpenSSL biblioteca tiene una tienda por defecto ubicación , pero lo usa solo si la aplicación llama SSL_CTX_set_default_verify_paths() o algunas rutinas X509_STORE relacionadas. OpenSSL línea de comando se supone que debe usar la tienda predeterminada, pero actualmente no lo hace para algunos funciones que incluyen s_client debido a un error; mira mi respuesta OTOH verify hace Úsalo, lo que probablemente se sumó a la confusión aquí.

— dave_thompson_085

El certificado raíz de comodo ya no es confiable: busque "certificado robado de comodo" en google si no sabe por qué.

Si bien un certificado de comodo puede ser barato, su valor es mucho menor que su precio: en efecto, es inútil, la cadena de confianza se rompe.

— Eugen Rieck
fuente

Eso es hace cuatro años y los certificados han sido revocados y reemplazados. En la parte superior, la CA raíz no es de COMODO sino de AddTrust; el certificado de CA raíz se verifica correctamente cuando se usa openssl verify AddTrustExternalCARoot.crt directamente, pero no se acepta como el último certificado en una cadena.

— Reinhard Seifert