Entendendo a saída do openssl s_client

14

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 SSL capazes de verificar portas ímpares, exceto esta . Eu tenho trabalhado com os dois provedores na tentativa de identificar o problema, mas finalmente cheguei a um beco sem saída com os dois, pois não conheço o suficiente sobre os Certificados SSL para poder orientar os provedores a entender onde está a falha.

Durante a investigação, chamei a atenção 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

CONECTADO (00000003)
depth = 2 / C = EUA / O = GeoTrust Inc./CN=GeoTrust Global CA
verificar erro: num = 20: não é possível obter o certificado do emissor local
verificar retorno: 0
---
Cadeia de certificados
 0 s: / C = EUA / ST = Califórnia / L = Mountain View / O = Google Inc / CN = pop.gmail.com
   i: / C = EUA / O = Google Inc / CN = Google Internet Authority G2
----- COMEÇAR CERTIFICADO -----
----- TERMINAR CERTIFICADO -----
 1 s: / C = EUA / O = Google Inc / CN = Google Internet Authority G2
   i: / C = EUA / O = GeoTrust Inc./CN=GeoTrust Global CA
----- COMEÇAR CERTIFICADO -----
----- TERMINAR CERTIFICADO -----
 2 s: / C = EUA / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = US / O = Equifax / OU = Autoridade de certificação segura Equifax
----- COMEÇAR CERTIFICADO -----
----- TERMINAR CERTIFICADO -----
---
Certificado do servidor
subject = / C = US / ST = Califórnia / L = Mountain View / O = Google Inc / CN = pop.gmail.com
emissor = / C = EUA / O = Google Inc / CN = Google Internet Authority G2
---
Nenhum nome de CA de certificado de cliente enviado
---
O handshake SSL leu 3236 bytes e gravou 435 bytes
---
Novo, TLSv1 / SSLv3, a cifra é RC4-SHA
A chave pública do servidor é 2048 bits
A renegociação segura é suportada
Compressão: NENHUM
Expansão: NENHUM
Sessão SSL:
    Protocolo: TLSv1
    Cifra: RC4-SHA
    ID da sessão: 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06
    ID da sessão-ctx:
    Chave mestra: DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2
    Argumento-chave: nenhum
    Hora de início: 1397678434
    Tempo limite: 300 (s)
    Verifique o código de retorno: 20 (não é possível obter o certificado do emissor local)
---
+ OK Gpop pronto para pedidos a partir de 69.3.61.10 c13mb42148040pdj
FEITO

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

CONECTADO (00000003)
depth = 2 / C = EUA / O = GeoTrust Inc./CN=GeoTrust Global CA
verificar erro: num = 19: certificado autoassinado na cadeia de certificados
verificar retorno: 0
---
Cadeia de certificados
 0 s: / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = Consulte www.rapidssl.com/resources/cps (c) 14 / OU = Controle de domínio validado - RapidSSL (R) /CN=secure.emailsrvr.com
   i: / C = EUA / O = GeoTrust, Inc./CN=RapidSSL CA
----- COMEÇAR CERTIFICADO -----
----- TERMINAR CERTIFICADO -----
 1 s: / C = EUA / O = GeoTrust, Inc./CN=RapidSSL CA
   i: / C = EUA / O = GeoTrust Inc./CN=GeoTrust Global CA
----- COMEÇAR CERTIFICADO -----
----- TERMINAR CERTIFICADO -----
 2 s: / C = EUA / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = EUA / O = GeoTrust Inc./CN=GeoTrust Global CA
----- COMEÇAR CERTIFICADO -----
----- TERMINAR CERTIFICADO -----
---
Certificado do servidor
subject = / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = Consulte www.rapidssl.com/resources/cps (c) 14 / OU = Controle de domínio validado - RapidSSL (R) /CN=secure.emailsrvr.com
emissor = / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
---
Nenhum nome de CA de certificado de cliente enviado
---
O handshake SSL leu 3876 bytes e gravou 319 bytes
---
Novo, TLSv1 / SSLv3, a cifra é DHE-RSA-AES256-SHA
A chave pública do servidor é 2048 bits
A renegociação segura é suportada
Compressão: NENHUM
Expansão: NENHUM
Sessão SSL:
    Protocolo: TLSv1
    Cifra: DHE-RSA-AES256-SHA
    ID da sessão: 3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161
    ID da sessão-ctx:
    Chave mestra: 016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F
    Argumento-chave: nenhum
    Hora de início: 1397678467
    Tempo limite: 300 (s)
    Verificar código de retorno: 19 (certificado autoassinado na cadeia de certificados)
---
FEITO

Eu tenho tentado entender se isso é significativo, porque quando a -CApathopção é fornecida, os comandos não produzem erros:

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

Também posso usar a -CAfileopção com sucesso depois de baixar o certificado CAfile diretamente do GeoTrust.

No entanto, a Fog Creek parece pensar que esse problema está no certificado, porque eles tentaram adicionar o certificado à Trustloja mono sem sucesso. Eu discordaria deles, mas (como mencionado acima), embora a maioria dos verificadores SSL não verifique a porta 995 ou tenha êxito durante a tentativa, encontrei esta página que produz o erro SSL 7.

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

ssl-certificate openssl jobu1324
fonte
2
Eu acho que o erro "certificado autoassinado na cadeia de certificados" é um arenque vermelho. Uma CA raiz sempre é autoassinada, portanto, um servidor que retorna sua cadeia de certificados completa sempre retornará um certificado autoassinado. Mais informações aqui .
precisa saber é o seguinte
2
Na verdade, parece openssl s_clientque não importa nenhum certificado de raiz por padrão. Tente isso:: openssl s_client -connect secure.emailsrvr.com:995 -showcerts -CApath /etc/ssl/certse provavelmente você descobrirá que o erro autoassinado desaparece.
precisa saber é o seguinte
@ bennettp123 Observo a saída desse comando na parte inferior da pergunta. Estou certo de entender a saída das duas versões do comando para significar que o certificado é válido?
jobu1324
sim, de acordo com essa saída, o openssl acha que o certificado é válido. Por que está sendo rejeitado? Eu não sei. Pode ser porque o campo Organização não está definido, mas isso é apenas um palpite.
precisa saber é o seguinte

Respostas:

5

A resposta (conforme explicado nesta publicação security.SE ) é que os dois certificados de CA Global GeoTrust que você vê na cadeia não são de fato o mesmo certificado , um é derivado do outro.

Por causa da assinatura cruzada do CA!

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

Ao ter outra autoridade de certificação (com reputação e distribuição preexistentes) assinar o certificado de autoridade de certificação raiz GeoTrust, o certificado resultante (referido como certificado de "ponte") agora pode ser verificado pela segunda autoridade de certificação, sem que o certificado de autoridade de certificação raiz GeoTrust tenha ser confiado explicitamente pelo cliente.

Quando o Google apresenta a versão com assinatura cruzada do certificado CA da raiz do GeoTrust, um cliente que não confia no original pode usar o certificado CA da Equifax para verificar o GeoTrust - para que o Equifax atue como uma espécie de âncora confiável "legada".

Mathias R. Jessen
fonte
É por isso que as duas cadeias de servidores são diferentes e, ainda assim, válidas. Mas não é necessariamente o motivo do problema do OP com o cliente mono, sem dados claros sobre exatamente quais raízes estão e não estão instaladas no armazenamento confiável da instância mono específica.
Dave_thompson_085
0

Tive um problema semelhante com o fetchmail quando ativei a verificação de SSL pop.gmail.com.

Eu baixei o arquivo pif Equifax, mas ele não funcionou como está, tinha que ser executado, o c_rehash ssl/certsque criava um link simbólico com valor de hash, e então funcionava.

Como alternativa, o valor do hash também pode ser conhecido executando-se ... 

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
fonte
Você poderia estender o que fazer com o arquivo pem vinculado?
sebix
# ldd / usr / bin / fetchmail | grep SSL libssl.so.10 => /lib64/libssl.so.10
chetangb
o que li em algum momento é que o fetchmail usa bibliotecas openssl e parece apenas com o valor de hash do certificado 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: Uma biblioteca de criptografia de uso geral com implementação TLS Repo: base Matched A partir de: Fornece: libssl.so.10
chetangb
Estenda sua resposta e explique qual o problema que você deseja alcançar.
sebix
0

Ao gerar e configurar certificados, é necessário atualizar o openssl.cnfarquivo também (Debian - /etc/ssl/openssl.cnf), para indicar o caminho apropriado, nomes de certificados etc., então você pode executar o comando e verificá-los sem -CApathopção.

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

Aqui está a openssl.cnfseção apropriada :

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

default_ca  = CA_default        # The default ca section

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

dir     = /etc/ssl
user155270
fonte
1
Isto está errado . Os default_cadados no (qualquer) arquivo openssl config são usados apenas para o utilitário 'ca' emitir e, opcionalmente, revogar certs, nunca para verificação. A maneira de alterar o armazenamento de verificação padrão (além de recompilar) é com as variáveis ​​de ambiente SSL_CERT_ {FILE, DIR}. No entanto (1) devido a um erro s_clientnão usa o padrão (correção planejada em abril de 2015) que (2) este OP não desejava alterar de qualquer maneira.
Dave_thompson_085