Розуміння результату openssl s_client


14

З тих пір, як наш постачальник електронної пошти змінив свій сертифікат SSL, клієнт POP3, заснований на монографії, відмовляється підключатися до свого захищеного POP-сервера для завантаження електронних листів. Інші клієнти не мають проблеми; наприклад, Thunderbird та Outlook; також більшість сайтів для перевірки SSL, які можуть перевірити непарні порти, крім цього . Я працював з обома постачальниками, намагаючись точно визначити проблему, але нарешті дійшов до тупикової точки з обома, оскільки я не знаю достатньо про сертифікати SSL, щоб можна було направити будь-якого постачальника, щоб зрозуміти, де несправність.

Під час розслідування мою увагу звернула на різницю у виведенні наступних двох команд (я видалив сертифікати з виводу для читабельності):

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

ПІДКЛЮЧЕНО (00000003)
глибина = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
Перевірте помилку: num = 20: неможливо отримати сертифікат місцевого емітента
перевірити повернення: 0
---
Ланцюг сертифікатів
 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
----- НАЧАЙТЕ СЕРТИФІКАТ -----
----- ЗАКОННИЙ СЕРТИФІКАТ -----
 1 s: / C = US / 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
----- НАЧАЙТЕ СЕРТИФІКАТ -----
----- ЗАКОННИЙ СЕРТИФІКАТ -----
---
Сертифікат сервера
subject = / C = US / ST = California / L = Mountain View / O = Google Inc / CN = pop.gmail.com
емітент = / C = US / O = Google Inc / CN = Google Internet Authority G2
---
Імена клієнтського сертифіката клієнтів не надіслані
---
Рукостискання SSL прочитало 3236 байт і записало 435 байт
---
Новий, TLSv1 / SSLv3, Шифр ​​RC4-SHA
Публічний ключ сервера - 2048 біт
Підтримується безпечна повторна переговорка
Стиснення: НІКОЛИ
Розширення: NONE
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

ПІДКЛЮЧЕНО (00000003)
глибина = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
перевірити помилку: num = 19: самопідписаний сертифікат у ланцюжку сертифікатів
перевірити повернення: 0
---
Ланцюг сертифікатів
 0 s: / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU = Див. Www.rapidssl.com/resources/cps (c) 14 / OU = Доменний контроль підтверджено - RapidSSL (R) /CN=secure.emailsrvr.com
   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.emailsrvr.com
емітент = / C = US / O = GeoTrust, Inc./CN=RapidSSL CA
---
Імена клієнтського сертифіката клієнтів не надіслані
---
Рукостискання SSL прочитало 3876 байт і записало 319 байт
---
Новий, TLSv1 / SSLv3, шифр - DHE-RSA-AES256-SHA
Публічний ключ сервера - 2048 біт
Підтримується безпечна повторна переговорка
Стиснення: НІКОЛИ
Розширення: NONE
SSL-сесія:
    Протокол: TLSv1
    Шифр: DHE-RSA-AES256-SHA
    ID сесії: 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, здається, вважає, що проблема полягає в kert, тому що вони намагалися додати cert до Trustмагазину моно без успіху. Я б не погоджувався з ними, але (як згадувалося вище), хоча більшість перевіряючих SSL або не перевіряє порт 995, або успішно під час спроби, я знайшов цю сторінку, яка створює SSL-помилку 7.

Чи правильно витлумачити висновок, щоб це означало, що з cert немає нічого поганого?


2
Я думаю, що помилка "самопідписаний сертифікат у ланцюжку сертифікатів" - це червона оселедець. Корінь CA завжди самопідписаний, тому сервер, який повертає повний ланцюжок сертифікатів, завжди повертає самопідписаний сертифікат. Більше інформації тут .
bennettp123

2
Насправді, схоже, openssl s_clientза замовчуванням не імпортуються жодні кореневі серти. Спробуйте це замість цього: openssl s_client -connect secure.emailsrvr.com:995 -showcerts -CApath /etc/ssl/certsі, ймовірно, ви виявите, що помилка самопідписання зникає.
bennettp123

@ bennettp123 Зауважу висновок цієї команди внизу питання. Чи правильно я розумію, що вихід обох версій команди означає, що cert є дійсним?
jobu1324

так, згідно з цим результатом, openssl вважає, що cert є дійсним. Чому його відхиляють? Не знаю. Це може бути тому, що поле Організація не встановлено, але це лише здогад.
bennettp123

Відповіді:


5

Відповідь (як пояснено в цій публікації про безпеку.SE ) полягає в тому, що два сертифікати GeoTrust Global CA, які ви бачите в ланцюжку, насправді не є одним і тим же сертифікатом , один отриманий з іншого.

Через перехресне підписання CA!

Коли вперше створено та підписано сертифікат GeoTrust Global CA, жоден комп'ютер / браузери / додатки не мали б його у своєму довірчому магазині.

Маючи ще один CA (з попередньою репутацією та розповсюдженням) підпишіть сертифікат кореня CA GeoTrust, отриманий сертифікат (іменований сертифікатом "міст") тепер може бути перевірений другим CA, без сертифікату кореневого CA GeoTrust root щоб клієнт прямо довіряв.

Коли Google представляє перехресну версію кореневого сертифіката CA GeoTrust, клієнт, який не довіряє оригіналу, може просто використовувати сервер Equifax CA для перевірки GeoTrust - тому Equifax виступає як своєрідний "спадщину" довіри довіри.


Ось чому дві ланцюги серверів різні, але обидві дійсні. Але це не обов'язково є причиною проблеми ОП з моно клієнтом, без чітких даних про те, які саме коріння є, а не встановлені в довіреній частині цього моноінстанції.
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_certificate/certificate/Equifax_Secure_Certificate_Authority.pem


Скажіть, будь ласка, що робити із пов'язаним файлом pem?
sebix

# ldd / usr / bin / fetchmail | grep ssl libssl.so.10 => /lib64/libssl.so.10
chetangb

що я читаю колись назад, це fetchmail використовує openssl libs, і це виглядає лише за хеш-значенням cert 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), щоб вказати правильний шлях, імена cert тощо., Тоді ви можете запустити команди та перевірити їх без -CApathможливості.

І відповідно віддалені хости також могли перевірити ваші сертифікати належним чином у цьому випадку.

Ось відповідний openssl.cnfрозділ:

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

default_ca  = CA_default        # The default ca section

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

dir     = /etc/ssl  

1
Це неправильно . default_caДані в (будь-якому) OpenSSL конфігураційного файлу використовуються тільки для «са» корисності для випуску і , можливо , Відкликати сертифікати, ніколи для перевірки. Спосіб зміни магазину підтвердження за замовчуванням (окрім перекомпіляції) - це змінні середовища SSL_CERT_ {FILE, DIR}. Однак (1) через помилку s_clientне використовується за замовчуванням (виправлення заплановано на квітня 2015 р.), Яке (2) ця ОП все одно не хотіла змінювати.
dave_thompson_085
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.