Comprender la salida de openssl s

14

Desde que nuestro proveedor de correo electrónico cambió su certificado SSL, un cliente POP3 basado en mono se niega a conectarse a su servidor POP seguro para descargar correos electrónicos. Otros clientes no tienen un problema; por ejemplo, Thunderbird y Outlook; tampoco lo hacen la mayoría de los sitios de verificación SSL que son capaces de verificar puertos impares, excepto este . He estado trabajando con ambos proveedores en un intento por identificar el problema, pero finalmente he llegado a un punto muerto con ambos, ya que no sé lo suficiente sobre los Certificados SSL para poder guiar a cualquiera de los proveedores a comprender dónde está la falla.

Durante la investigación, me llamó la atención la diferencia en la salida de los siguientes dos comandos (he eliminado los certificados de la salida para facilitar la lectura):

echo "" | openssl s_client -showcerts -connect pop.gmail.com:995

CONECTADO (00000003)
profundidad = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust Global CAerror de 
verificación : num = 20: no se puede obtener el certificado de emisor local
verificar devolución: 0
---
Cadena de certificados
 0 s: / C = US / ST = California / L = Mountain View / O = Google Inc / CN = pop.gmail.com
   i: / C = US / O = Google Inc / CN = Autoridad de Internet de Google G2
----- COMIENCE EL CERTIFICADO -----
----- FINALIZAR CERTIFICADO -----
 1 s: / C = US / O = Google Inc / CN = Google Internet Authority G2
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- COMIENCE EL CERTIFICADO -----
----- FINALIZAR CERTIFICADO -----
 2 s: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = US / O = Equifax / OU = Equifax Secure Certificate Authority
----- COMIENCE EL CERTIFICADO -----
----- FINALIZAR CERTIFICADO -----
---
Certificado del servidor
subject = / C = US / ST = California / L = Mountain View / O = Google Inc / CN = pop.gmail.com
emisor = / C = US / O = Google Inc / CN = Autoridad de Internet de Google G2
---
No se enviaron nombres de CA de certificado de cliente
---
El protocolo de enlace SSL ha leído 3236 bytes y escrito 435 bytes
---
Nuevo, TLSv1 / SSLv3, Cipher es RC4-SHA
La clave pública del servidor es de 2048 bits
La renegociación segura es compatible
Compresión: NINGUNO
Expansión: NINGUNO
Sesión SSL:
    Protocolo: TLSv1
    Cifrado: RC4-SHA
    ID de sesión: 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06
    Session-ID-ctx:
    Master-Key: DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2
    Key-Arg: Ninguno
    Hora de inicio: 1397678434
    Tiempo de espera: 300 (seg)
    Verifique el código de retorno: 20 (no se puede obtener el certificado de emisor local)
---
+ OK Gpop listo para solicitudes de 69.3.61.10 c13mb42148040pdj
HECHO

echo "" | openssl s_client -showcerts -connect secure.emailsrvr.com:995

CONECTADO (00000003)
profundidad = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust Global CAerror de 
verificación : num = 19: certificado autofirmado en la cadena de certificados
verificar devolución: 0
---
Cadena de certificados
 0 s: / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = Ver www.rapidssl.com/resources/cps (c) 14 / OU = Control de dominio validado - RapidSSL (R) /CN=secure.emailsrvr.com
   i: / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
----- COMIENCE EL CERTIFICADO -----
----- FINALIZAR CERTIFICADO -----
 1 s: / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- COMIENCE EL CERTIFICADO -----
----- FINALIZAR CERTIFICADO -----
 2 s: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- COMIENCE EL CERTIFICADO -----
----- FINALIZAR CERTIFICADO -----
---
Certificado del servidor
subject = / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = Ver www.rapidssl.com/resources/cps (c) 14 / OU = Control de dominio validado - RapidSSL (R) /CN=secure.emailsrvr.com
emisor = / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
---
No se enviaron nombres de CA de certificado de cliente
---
El protocolo de enlace SSL ha leído 3876 bytes y escrito 319 bytes
---
Nuevo, TLSv1 / SSLv3, Cipher es DHE-RSA-AES256-SHA
La clave pública del servidor es de 2048 bits
La renegociación segura es compatible
Compresión: NINGUNO
Expansión: NINGUNO
Sesión SSL:
    Protocolo: TLSv1
    Cifrado: DHE-RSA-AES256-SHA
    ID de sesión: 3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161
    Session-ID-ctx:
    Master-Key: 016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F
    Key-Arg: Ninguno
    Hora de inicio: 1397678467
    Tiempo de espera: 300 (seg)
    Verifique el código de retorno: 19 (certificado autofirmado en la cadena de certificados)
---
HECHO

He estado tratando de entender si esto es significativo, porque cuando -CApathse proporciona la opción, los comandos no producen ningún error:

openssl s_client -CApath /etc/ssl/certs -showcerts -connect secure.emailsrvr.com:995

CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = "GeoTrust, Inc.", CN = RapidSSL CA
verify return:1
depth=0 serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD, OU = 4159320284, OU = See www.rapidssl.com/resources/cps (c)14, OU = Domain Control Validated - RapidSSL(R), CN = secure.emailsrvr.com
verify return:1
...

openssl s_client -CApath /etc/ssl/certs -showcerts -connect pop.gmail.com:995

CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = pop.gmail.com
verify return:1
...

También puedo usar la -CAfileopción con éxito después de descargar el certificado CAfile directamente desde GeoTrust.

Sin embargo, Fog Creek parece pensar que el problema radica en el certificado, porque han intentado agregar el certificado a la Trusttienda de mono sin éxito. No estaría de acuerdo con ellos, pero (como se mencionó anteriormente) aunque la mayoría de los verificadores SSL no verifican el puerto 995 o no tienen éxito durante el intento, encontré esta página que produce el error 7 de SSL.

¿Interpreto correctamente la salida que significa que no hay nada malo con el certificado?

ssl-certificate openssl jobu1324
fuente

2

Creo que el error "certificado autofirmado en la cadena de certificados" es una pista falsa. Una CA raíz siempre está autofirmada, por lo que un servidor que devuelve su cadena de certificados completa siempre devolverá un certificado autofirmado. Más información aquí .

bennettp123

2

En realidad, parece openssl s_clientque no importa ningún certificado raíz de forma predeterminada. Intente esto en su lugar: openssl s_client -connect secure.emailsrvr.com:995 -showcerts -CApath /etc/ssl/certsy probablemente encontrará que el error autofirmado desaparece.

bennettp123

@ bennettp123 Observo el resultado de ese comando hacia el final de la pregunta. ¿Tengo razón al entender que el resultado de ambas versiones del comando significa que el certificado es válido?

jobu1324

Sí, de acuerdo con esa salida, openssl piensa que el certificado es válido. ¿Por qué está siendo rechazado? No lo sé. Puede ser porque el campo Organización no está configurado, pero eso es solo una suposición.

bennettp123

5

La respuesta (como se explica en esta publicación de security.SE ) es que los dos certificados GeoTrust Global CA que ve en la cadena no son, de hecho, el mismo certificado , uno se deriva del otro.

¡Debido a la firma cruzada de CA!

Cuando el certificado GeoTrust Global CA se creó y firmó por primera vez, ninguna computadora / navegador / aplicación lo habría tenido en su almacén de confianza.

Al hacer que otra CA (con una reputación y distribución preexistentes) firme el certificado de CA raíz de GeoTrust, el certificado resultante (denominado certificado "puente") ahora puede ser verificado por la segunda CA, sin que el certificado de CA raíz de GeoTrust tenga para que el cliente confíe explícitamente.

Cuando Google presenta la versión con firma cruzada del certificado de CA raíz de GeoTrust, un cliente que no confía en el original solo puede usar el certificado de CA de Equifax para verificar GeoTrust, por lo que Equifax actúa como una especie de ancla de confianza "heredada".

Mathias R. Jessen
fuente

Es por eso que las dos cadenas de servidores son diferentes y, sin embargo, ambas son válidas. Pero no es necesariamente la razón del problema del OP con el cliente mono, sin datos claros sobre exactamente qué raíces están y no están instaladas en el almacén de confianza de la instancia mono en particular.

dave_thompson_085

0

Tuve un problema similar con fetchmail cuando habilité la comprobación de SSL pop.gmail.com.

Descargué el archivo pem Equifax pero no funcionó como está, tuve que ejecutarlo, lo c_rehash ssl/certsque creó un enlace simbólico con valor hash, luego simplemente funcionó.

Alternativamente, el valor hash también se puede conocer ejecutando ...

openssl x509 -in Equifax_Secure_Certificate_Authority.pem -fingerprint -subject -issuer -serial -hash -noout | sed  -n /^[0-9]/p

https://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.pem

chetangb
fuente

¿Podría por favor extender qué hacer con el archivo pem vinculado?

sebix

# ldd / usr / bin / fetchmail | grep ssl libssl.so.10 => /lib64/libssl.so.10

chetangb

lo que leí en algún momento es que fetchmail usa openssl libs y solo se ve por el valor hash del cert productforums.google.com/forum/#!topic/gmail/tqjOmqxpMKY # ldd / usr / bin / fetchmail | grep ssl libssl.so.10 => /lib64/libssl.so.10 yum whatprovides libssl.so.10 openssl-libs-1.0.1e-42.el7.i686: Una biblioteca de criptografía de propósito general con implementación TLS Repo: base coincidente de: Proporciona: libssl.so.10

chetangb

Extienda su respuesta y explique cuál puede ser el problema que desea lograr.

sebix

0

Al generar y configurar certificados, también se debe actualizar el openssl.cnfarchivo (Debian - /etc/ssl/openssl.cnf), para indicar la ruta correcta, los nombres de los certificados, etc., luego puede ejecutar el comando y verificarlos sin -CApathopción.

Y, en consecuencia, los hosts remotos también podrían verificar sus certificados correctamente en este caso.

Aquí está la openssl.cnfsección apropiada :

####################################################################
[ ca ]

default_ca  = CA_default        # The default ca section

####################################################################
[ CA_default ]

dir     = /etc/ssl

usuario155270
fuente

1

Esto esta mal . Los default_cadatos en el archivo de configuración openssl (cualquiera) se usan solo para que la utilidad 'ca' emita y opcionalmente revoque certificados, nunca para verificación. La forma de cambiar el almacén de verificación predeterminado (además de volver a compilar) es con las variables de entorno SSL_CERT_ {FILE, DIR}. Sin embargo (1) debido a un error s_client, no utiliza el valor predeterminado (corrección planificada a partir de abril de 2015) que (2) este OP no quería cambiar de todos modos.

dave_thompson_085

Comprender la salida de openssl s_client

Respuestas:

¡Debido a la firma cruzada de CA!