Вопросы Теги

Понимание вывода openssl s_client

С тех пор, как наш почтовый поставщик изменил их сертификат SSL, клиент POP3 на основе моно мусора для соединения с их безопасным сервером POP для загрузки электронных писем. У других клиентов нет проблемы; например, Thunderbird и Outlook; ни один не делает большинство сайтов средства проверки SSL, которые способны к проверке нечетных портов кроме этого. Я работал с обоими поставщиками в попытке точно определить проблему, но наконец достиг тупика с обоими, так как я не знаю достаточно о сертификатах SSL, чтобы смочь вести любого поставщика для понимания, где вина лежит.

Во время расследования мое внимание было привлечено к различию в выводе следующих двух команд (я удалил сертификаты из вывода для удобочитаемости):

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

Я пытался понять, значимо ли это, потому что когда -CApath возможность предоставляется, команды не производят ошибок:

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

Я могу также использовать -CAfile опция успешно после загрузки сертификата CAfile непосредственно от GeoTrust.

Тем не менее, Ручей Вуали, кажется, думает, что проблема связана с сертификатом, потому что они попытались добавить сертификат к mono's Trust хранилище без успеха. Я не согласился бы с ними, но (как упомянуто выше), в то время как большинство средств проверки SSL или не проверяет порт 995 или успешно выполняется во время попытки, я нашел эту страницу, которая производит ошибку SSL 7.

Я интерпретирую вывод правильно, чтобы означать, что нет ничего неправильно с сертификатом?

14
задан 17 April 2014 в 02:51
3 ответа

При генерации и настройке сертификатов необходимо также обновить файл openssl.cnf (Debian - /etc/ssl/openssl.cnf ), чтобы указать правильный путь, имена сертификатов и т. д., затем вы можете запустить команду и проверить их без опции -CApath .

И, соответственно, удаленные хосты также могут правильно проверить ваши сертификаты в этом случае.

Здесь является подходящим разделом openssl.cnf : 

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

default_ca  = CA_default        # The default ca section

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

dir     = /etc/ssl
0
ответ дан 2 December 2019 в 21:14

Ответ (как объясняется в этом сообщении security.SE ) заключается в том, что два сертификата GeoTrust Global CA , которые вы видите в цепочке, на самом деле не тот же сертификат , один является производным от другого.

Из-за перекрестной подписи CA!

Когда сертификат GeoTrust Global CA был впервые создан и подписан, ни один компьютер / браузеры / приложения не будет были в их доверенном магазине.

Если другой ЦС (с уже существующей репутацией и распространением) подписал сертификат корневого ЦС GeoTrust, полученный сертификат (называемый «мостовым» сертификатом) теперь может быть проверен вторым ЦС, без сертификата корневого ЦС GeoTrust, которому клиент должен явно доверять.

Когда Google представляет версию сертификата корневого ЦС GeoTrust с перекрестной подписью, клиент, не доверяющий оригиналу, может просто использовать ЦС Equifax сертификат для проверки GeoTrust - поэтому Equifax действует как своего рода «устаревший» якорь доверия.

5
ответ дан 2 December 2019 в 21:14

Была аналогичная проблема с fetchmail, когда я включил ssl-проверку для pop.gmail.com .

Я загрузил PEM-файл Equifax, но он не работал как есть, пришлось запустить c_rehash ssl / certs , который создал символическую ссылку с хеш-значением, затем он просто работал.

В качестве альтернативы, хеш-значение также можно узнать, запустив ... 

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

0
ответ дан 2 December 2019 в 21:14

Теги

Похожие вопросы