Comprensione dell'output di openssl s_client

14

Da quando il nostro provider di posta elettronica ha cambiato il certificato SSL, un client POP3 basato su mono si rifiuta di connettersi al proprio server POP sicuro per scaricare e-mail. Gli altri client non hanno problemi; ad esempio Thunderbird e Outlook; né la maggior parte dei siti di controllo SSL in grado di controllare le porte dispari tranne questo . Ho lavorato con entrambi i provider nel tentativo di individuare il problema, ma alla fine ho raggiunto un vicolo cieco con entrambi, poiché non conosco abbastanza i certificati SSL per essere in grado di guidare entrambi i provider a capire dove si trova l'errore.

Durante l'indagine, la mia attenzione è stata attirata dalla differenza nell'output dei seguenti due comandi (ho rimosso i certificati dall'output per leggibilità):

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

COLLEGATO (00000003)
profondità = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA.errore di 
verifica : num = 20: impossibile ottenere il certificato emittente locale
verifica ritorno: 0
---
Catena di certificati
 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
----- INIZIA ATTESTATO -----
----- CERTIFICATO DI FINE -----
 1 s: / C = US / O = Google Inc / CN = Google Internet Authority G2
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA.
----- INIZIA ATTESTATO -----
----- CERTIFICATO DI FINE -----
 2 s: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA.
   i: / C = US / O = Equifax / OU = Autorità di certificazione sicura Equifax
----- INIZIA ATTESTATO -----
----- CERTIFICATO DI FINE -----
---
Certificato del server
subject = / C = US / ST = California / L = Mountain View / O = Google Inc / CN = pop.gmail.com
emittente = / C = US / O = Google Inc / CN = Google Internet Authority G2
---
Nessun nome CA certificato client inviato
---
L'handshake SSL ha letto 3236 byte e scritto 435 byte
---
Nuovo, TLSv1 / SSLv3, Cipher è RC4-SHA
La chiave pubblica del server è 2048 bit
Rinegoziazione sicura IS supportata
Compressione: NESSUNO
Espansione: NESSUNO
SSL-Session:
    Protocollo: TLSv1
    Cifra: RC4-SHA
    ID sessione: 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06
    Session-ID-CTX:
    Chiave principale: DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2
    Key-Arg: Nessuno
    Ora di inizio: 1397678434
    Timeout: 300 (sec)
    Verifica codice di ritorno: 20 (impossibile ottenere il certificato dell'emittente locale)
---
+ OK Gpop pronto per le richieste da 69.3.61.10 c13mb42148040pdj
FATTO

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

COLLEGATO (00000003)
profondità = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA.errore di 
verifica : num = 19: certificato autofirmato nella catena di certificati
verifica ritorno: 0
---
Catena di certificati
 0 s: / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = Vedi www.rapidssl.com/resources/cps (c) 14 / OU = Controllo dominio convalidato - RapidSSL (R) /CN=secure.emailsrvr.com
   i: / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
----- INIZIA ATTESTATO -----
----- CERTIFICATO DI FINE -----
 1 s: / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA.
----- INIZIA ATTESTATO -----
----- CERTIFICATO DI FINE -----
 2 s: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA.
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA.
----- INIZIA ATTESTATO -----
----- CERTIFICATO DI FINE -----
---
Certificato del server
subject = / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = Vedi www.rapidssl.com/resources/cps (c) 14 / OU = Controllo dominio validato - RapidSSL (R) /CN=secure.emailsrvr.com
emittente = / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
---
Nessun nome CA certificato client inviato
---
L'handshake SSL ha letto 3876 byte e ha scritto 319 byte
---
Nuovo, TLSv1 / SSLv3, Cipher è DHE-RSA-AES256-SHA
La chiave pubblica del server è 2048 bit
Rinegoziazione sicura IS supportata
Compressione: NESSUNO
Espansione: NESSUNO
SSL-Session:
    Protocollo: TLSv1
    Cifra: DHE-RSA-AES256-SHA
    ID sessione: 3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161
    Session-ID-CTX:
    Chiave principale: 016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F
    Key-Arg: Nessuno
    Ora di inizio: 1397678467
    Timeout: 300 (sec)
    Verifica codice di ritorno: 19 (certificato autofirmato nella catena di certificati)
---
FATTO

Ho cercato di capire se questo è significativo, perché quando -CApathviene fornita l' opzione, i comandi non generano errori:

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

Posso anche utilizzare -CAfilecorrettamente l' opzione dopo aver scaricato il certificato CAfile direttamente da GeoTrust.

Tuttavia, Fog Creek sembra pensare che il problema risieda nel certificato, perché hanno provato ad aggiungere il certificato al Trustnegozio di Mono senza successo. Non sarei d'accordo con loro, ma (come menzionato sopra) mentre la maggior parte dei controllori SSL non controlla la porta 995 o riesce durante il tentativo, ho trovato questa pagina che produce l'errore SSL 7.

Interpreto correttamente l'output per indicare che non c'è nulla di sbagliato nel certificato?

ssl-certificate  openssl 
— jobu1324
fonte
2
Penso che l'errore "certificato autofirmato nella catena di certificati" sia un'aringa rossa. Una CA radice è sempre autofirmata, quindi un server che restituisce la sua catena di certificati completa restituirà sempre un certificato autofirmato. Maggiori informazioni qui .
— bennettp123,
2
In realtà, sembra openssl s_clientnon importare alcun root root per impostazione predefinita. Prova invece questo: openssl s_client -connect secure.emailsrvr.com:995 -showcerts -CApath /etc/ssl/certse probabilmente scoprirai che l'errore autofirmato scompare.
— bennettp123,
@ bennettp123 Prendo atto dell'output di quel comando verso il fondo della domanda. Ho ragione a capire l'output di entrambe le versioni del comando per indicare che il certificato è valido?
— jobu1324,
sì, secondo quell'output, openssl pensa che il certificato sia valido. Perché viene rifiutato? Non lo so. Potrebbe essere perché il campo Organizzazione non è impostato, ma è solo un'ipotesi.
— bennettp123,

Risposte:

5

La risposta (come spiegato in questo post di security.SE ) è che i due certificati GeoTrust Global CA che vedi nella catena non sono in realtà lo stesso certificato , uno è derivato dall'altro.

A causa della firma incrociata di CA!

Quando il certificato CA globale GeoTrust è stato creato e firmato per la prima volta, nessun computer / browser / applicazione lo avrebbe avuto nel proprio archivio fidato.

Avendo un'altra CA (con reputazione e distribuzione preesistenti) firmare il certificato CA radice GeoTrust, il certificato risultante (indicato come certificato "bridge") può ora essere verificato dalla seconda CA, senza che il certificato CA radice GeoTrust abbia fidarsi esplicitamente del cliente.

Quando Google presenta la versione con firma incrociata del certificato CA radice GeoTrust, un client che non si fida dell'originale può semplicemente utilizzare il certificato CA Equifax per verificare GeoTrust, quindi Equifax agisce come una sorta di ancoraggio di fiducia "legacy".

— Mathias R. Jessen
fonte
Ecco perché le due catene di server sono diverse e tuttavia entrambe valide. Ma non è necessariamente la ragione del problema dell'OP con il client mono, senza dati chiari su quali root siano e non siano installati nel truststore dell'istanza mono specifica.
— dave_thompson_085,
0

Ho avuto un problema simile con fetchmail quando ho abilitato il controllo ssl per pop.gmail.com.

Ho scaricato il file pem di Equifax ma non ha funzionato così com'è, ho dovuto eseguire quello c_rehash ssl/certsche ha creato un collegamento simbolico con valore hash, poi ha funzionato.

In alternativa, il valore hash può anche essere conosciuto eseguendo ... 

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
Potresti estendere cosa fare con il file pem collegato?
— Sebix,
# ldd / usr / bin / fetchmail | grep ssl libssl.so.10 => /lib64/libssl.so.10
— chetangb
quello che ho letto qualche volta fa è che fetchmail usa librerie openssl e guarda solo dal valore hash del prodotto cert forums.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: libreria di crittografia per scopi generici con implementazione TLS Repo: base Matched da: Fornisce: libssl.so.10
— chetangb
Estendi la tua risposta e spiega quale potrebbe essere il problema che desideri raggiungere.
— Sebix,
0

Durante la generazione e la configurazione dei certificati, è necessario aggiornare anche il openssl.cnffile (Debian - /etc/ssl/openssl.cnf), per indicare il percorso corretto, i nomi dei certificati ecc., Quindi è possibile eseguire il comando e controllarli senza -CApathopzione.

Di conseguenza, anche gli host remoti potrebbero controllare correttamente i certificati in questo caso.

Ecco la openssl.cnfsezione appropriata :

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

default_ca  = CA_default        # The default ca section

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

dir     = /etc/ssl
— user155270
fonte
1
Questo è sbagliato . I default_cadati nel (qualsiasi) file di configurazione di openssl vengono utilizzati solo per l'utilità 'ca' per emettere e facoltativamente revocare certificati, mai per verifica. Il modo per modificare l'archivio di verifica predefinito (oltre alla ricompilazione) è con le variabili di ambiente SSL_CERT_ {FILE, DIR}. Tuttavia (1) a causa di un bug s_clientnon utilizza l'impostazione predefinita (correzione pianificata a partire da aprile 2015) che (2) questo PO non voleva cambiare comunque.
— dave_thompson_085,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.