Compreendendo a saída de openssl s_client

Question

Desde que nosso provedor de e-mail alterou seu certificado SSL, um cliente POP3 baseado em mono se recusa a se conectar ao servidor POP seguro para baixar e-mails. Outros clientes não têm um problema; por exemplo. Thunderbird e Outlook; nem a maioria dos sites verificadores de SSL são capazes de verificar portas ímpares exceto este . Eu tenho trabalhado com ambos os provedores em uma tentativa de identificar o problema, mas finalmente cheguei a um beco sem saída com ambos, já que não sei o suficiente sobre Certificados SSL para poder guiar qualquer provedor para entender onde está a falha.

Durante a investigação, minha atenção foi atraída para a diferença na saída dos dois comandos a seguir (removi os certificados da saída para facilitar a leitura):

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

CONNECTED(00000003)
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=pop.gmail.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=pop.gmail.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 3236 bytes and written 435 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06
    Session-ID-ctx:
    Master-Key: DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2
    Key-Arg   : None
    Start Time: 1397678434
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
+OK Gpop ready for requests from 69.3.61.10 c13mb42148040pdj
DONE

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

CONNECTED(00000003)
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/serialNumber=tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD/OU=4159320284/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=secure.emailsrvr.com
   i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
 1 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
---
Server certificate
subject=/serialNumber=tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD/OU=4159320284/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=secure.emailsrvr.com
issuer=/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
---
No client certificate CA names sent
---
SSL handshake has read 3876 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161
    Session-ID-ctx:
    Master-Key: 016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F
    Key-Arg   : None
    Start Time: 1397678467
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
DONE

Eu tenho tentado entender se isso é significativo, porque quando a opção -CApath é fornecida, os comandos não produzem nenhum erro:

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
...

Eu também posso usar a opção -CAfile com êxito depois de fazer o download do certificado CAfile diretamente do GeoTrust.

No entanto, a Fog Creek parece achar que o problema está no cert, porque eles tentaram adicionar o certificado à loja Trust da mono sem sucesso. Eu discordaria deles, mas (como mencionado acima) enquanto a maioria dos verificadores de SSL não verifica a porta 995 ou obtém sucesso durante a tentativa, eu encontrei esta página que produz o erro SSL 7.

Interpreto a saída corretamente para dizer que não há nada errado com o certificado?

    

Answer 1

A resposta (conforme explicado neste post de segurança.SE ) é que os dois certificados GeoTrust Global CA que você vê na cadeia são, na verdade, não o mesmo certificado , um é derivado do outro.

Por causa da assinatura cruzada da CA!

Quando o certificado da GeoTrust Global CA foi criado e assinado pela primeira vez, nenhum computador / navegador / aplicativo o teria em seu armazenamento confiável.

Por ter outra autoridade de certificação (com uma reputação e distribuição pré-existentes) assinar o certificado da CA raiz GeoTrust, o certificado resultante (referido como um certificado "ponte") agora pode ser verificado pelo segunda CA, sem que o certificado de CA raiz GeoTrust tenha que ser confiado pelo cliente explicitamente.

Quando o Google apresenta a versão Cross-signed do certificado CA da GeoTrust, um cliente que não confia no original pode usar o certificado Equifax CA para verificar o GeoTrust - então a Equifax atua como uma espécie de âncora de confiança "legada" .

    

Answer 2

Tive problemas semelhantes com o fetchmail quando habilitei o ssl para verificar pop.gmail.com .

Eu fiz o download do arquivo pem do Equifax, mas ele não funcionou como está, tive que executar o c_rehash ssl/certs , que criou um link simbólico com o valor do hash, e depois funcionou.

Como alternativa, o valor de hash também pode ser conhecido executando ...

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

link

    

Answer 3

Durante a geração e configuração de certificados, deve-se atualizar o arquivo openssl.cnf (Debian - /etc/ssl/openssl.cnf ), para indicar o caminho correto, nomes de certificados, etc., então você pode executar o comando e marcá-los sem -CApath .

E, consequentemente, os hosts remotos também podem verificar seus certificados corretamente neste caso.

Aqui está a seção openssl.cnf apropriada:

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

default_ca  = CA_default        # The default ca section

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

dir     = /etc/ssl