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

14

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

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

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

CONNECTED (00000003)
глубина = 2 / C = США / O = GeoTrust Inc./CN=GeoTrust Global CAошибка 
проверки : num = 20: невозможно получить сертификат локального эмитента
подтвердить возврат: 0
---
Цепочка сертификатов
 0 с: / C = США / ST = Калифорния / L = Маунтин-Вью / O = Google Inc / CN = pop.gmail.com
   я: / C = США / O = Google Inc / CN = Google Internet Authority G2
----- НАЧАТЬ СЕРТИФИКАТ -----
----- КОНЕЦ СЕРТИФИКАТА -----
 1 с: / C = США / O = Google Inc / CN = Google Internet Authority G2
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- НАЧАТЬ СЕРТИФИКАТ -----
----- КОНЕЦ СЕРТИФИКАТА -----
 2 с: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = US / O = Equifax / OU = Equifax Secure Certificate Authority
----- НАЧАТЬ СЕРТИФИКАТ -----
----- КОНЕЦ СЕРТИФИКАТА -----
---
Сертификат сервера
subject = / C = США / ST = Калифорния / L = Маунтин-Вью / O = Google Inc / CN = pop.gmail.com
эмитент = / C = США / O = Google Inc / CN = Google Internet Authority G2
---
Имена CA сертификатов клиентов не отправлены
---
SSL рукопожатие прочитало 3236 байт и записало 435 байт
---
Новый, TLSv1 / SSLv3, Шифр ​​RC4-SHA
Открытый ключ сервера 2048 бит
Безопасное пересмотр поддерживается
Сжатие: НЕТ
Расширение: НЕТ
SSL-сессии:
    Протокол: TLSv1
    Шифр: RC4-SHA
    ID сеанса: 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06
    Session-ID-CTX:
    Главный ключ: DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2
    Key-Arg: нет
    Время начала: 1397678434
    Тайм-аут: 300 (сек)
    Проверьте код возврата: 20 (невозможно получить сертификат местного эмитента)
---
+ OK Gpop готов для запросов от 69.3.61.10 c13mb42148040pdj
СДЕЛАНО

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

CONNECTED (00000003)
глубина = 2 / C = США / O = GeoTrust Inc./CN=GeoTrust Global CAошибка 
проверки : num = 19: самоподписанный сертификат в цепочке сертификатов
подтвердить возврат: 0
---
Цепочка сертификатов
 0 с: / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = См. Www.rapidssl.com/resources/cps (c) 14 / OU = контроль домена подтвержден - RapidSSL (R) /CN=secure.emailsrv
   i: / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
----- НАЧАТЬ СЕРТИФИКАТ -----
----- КОНЕЦ СЕРТИФИКАТА -----
 1 с: / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- НАЧАТЬ СЕРТИФИКАТ -----
----- КОНЕЦ СЕРТИФИКАТА -----
 2 с: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
   i: / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
----- НАЧАТЬ СЕРТИФИКАТ -----
----- КОНЕЦ СЕРТИФИКАТА -----
---
Сертификат сервера
subject = / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = См. www.rapidssl.com/resources/cps (c) 14 / OU = контроль домена подтвержден - RapidSSL (R) /CN=secure.emailsrv.com
эмитент = / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
---
Имена CA сертификатов клиентов не отправлены
---
SSL рукопожатие прочитало 3876 байт и записало 319 байт
---
Новый, TLSv1 / SSLv3, шифр DHE-RSA-AES256-SHA
Открытый ключ сервера 2048 бит
Безопасное пересмотр поддерживается
Сжатие: НЕТ
Расширение: НЕТ
SSL-сессии:
    Протокол: TLSv1
    Шифр: DHE-RSA-AES256-SHA
    Идентификатор сеанса: 3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161
    Session-ID-CTX:
    Главный ключ: 016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F
    Key-Arg: нет
    Время начала: 1397678467
    Тайм-аут: 300 (сек)
    Проверьте код возврата: 19 (самозаверяющий сертификат в цепочке сертификатов)
---
СДЕЛАНО

Я пытался понять, имеет ли это смысл, потому что когда -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.

Тем не менее, Fog Creek, похоже, считает, что проблема связана с сертификатом, потому что они безуспешно пытались добавить сертификат в Trustмагазин моно . Я не согласился бы с ними, но (как уже упоминалось выше), хотя большинство контроллеров SSL либо не проверяют порт 995, либо успешно выполняют попытку, я обнаружил, что эта страница выдает ошибку SSL 7.

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

ssl-certificate openssl jobu1324
источник
2
Я думаю, что ошибка "самоподписанный сертификат в цепочке сертификатов" - красная сельдь. Корневой ЦС всегда самоподписан, поэтому сервер, который возвращает свою полную цепочку сертификатов, всегда будет возвращать самоподписанный сертификат. Больше информации здесь .
bennettp123
2
На самом деле, кажется openssl s_client, по умолчанию не импортирует корневые сертификаты. Попробуйте вместо этого:, openssl s_client -connect secure.emailsrvr.com:995 -showcerts -CApath /etc/ssl/certsи вы, вероятно, обнаружите, что самоподписанная ошибка исчезает.
bennettp123
@ bennettp123 Я отмечаю вывод этой команды в нижней части вопроса. Правильно ли я понимаю, что вывод обеих версий команды означает, что сертификат действителен?
jobu1324
да, согласно этому выводу, openssl считает сертификат действительным. Почему это отклонено? Я не знаю. Это может быть потому, что поле «Организация» не задано, но это только предположение.
bennettp123

Ответы:

5

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

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

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

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

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

Матиас Р. Ессен
источник
Вот почему две цепочки серверов различны, но обе действительны. Но это не обязательно является причиной проблемы OP с моно-клиентом, без четких данных о том, какие именно корни есть и не установлены в доверенном хранилище конкретного моно-экземпляра.
dave_thompson_085
0

Подобная проблема была с 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

chetangb
источник
Не могли бы вы рассказать, что делать со связанным pem-файлом?
Sebix
# ldd / usr / bin / fetchmail | grep ssl libssl.so.10 => /lib64/libssl.so.10
chetangb
Что я прочитал некоторое время назад, так это то, что fetchmail использует библиотеки openssl, и он смотрит только по хеш-значению сертификата 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: библиотека криптографии общего назначения с реализацией TLS Repo: base Matched От: Предоставляет: libssl.so.10
chetangb
Пожалуйста, расширьте свой ответ и объясните, в чем заключается проблема, которую вы хотите достичь.
Sebix
0

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

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

Здесь уместно openssl.cnfраздел:

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

default_ca  = CA_default        # The default ca section

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

dir     = /etc/ssl
user155270
источник
1
Это неправильно . default_caДанные в (любом) OpenSSL конфигурационного файла используются только для «са» полезности для выпуска и , возможно , Отозвать сертификаты, никогда для проверки. Изменить хранилище проверки по умолчанию (кроме перекомпиляции) можно с помощью переменных среды SSL_CERT_ {FILE, DIR}. Однако (1) из-за ошибки s_clientне используется значение по умолчанию (исправление запланировано на апрель 2015 г.), которое (2) этот OP не хотел менять в любом случае.
dave_thompson_085