OpenSSL не збирає CA в папці certs

У нас виникають проблеми з curlне підключенням до сервера HTTPS:

$ curl https://the-problem-site.com    (not the real URL!)   
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:reason(1112)

1112 SSL_R_TLSV1_UNRECOGNIZED_NAMEв ssl.h.

Якщо я спробую openssl s_client -connect the-problem-site.com:443замість цього, то бачу

CONNECTED(00000003)   
depth=1 /C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
verify error:num=20:unable to get local issuer certificate   
verify return:0   

Certificate chain   
0 s:/serialNumber=xx/C=xx/ST=xx/L=xxxx/O=xx/OU=xx/CN=the-problem-site.com   
i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA   
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA   

тобто виглядає проблема в тому, що вона не довіряє /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA. Однак встановлено цей сертифікат: він є /etc/ssl/certs/GeoTrust_Global_CA.pem, і якщо замість цього я запускаю

openssl s_client-підключити the-problem-site.com:243 -CAfile /etc/ssl/certs/GeoTrust_Global_CA.pem

тоді все працює. Cert також присутній у вигляді файлу з іменем хешу b0f3e76e.0і знаходиться в ньому ca-certificates.crt. Однак, наскільки я бачу, ні curl, ні openssl не намагаються прочитати будь-які сертифікати; якщо я straceїх, то немає спроби читати з /usr/lib/ssl/certsабо /etc/ssl/certsвзагалі, навіть з помилками. Однак він читає openssl.cnf. Ми бігли update-ca-certificates.

Це Ubuntu 10.04 з openssl 0.9.8k. Ми можемо відтворити проблему у двох окремих встановленнях (хоча можливо, один клон інший із зворотного шляху). Якщо я спробую той самий тест на CentOS VM з openssl 0.9.8e, він працює добре, і я можу побачити, як він читає файл сертифіката в strace. Немає еквівалентного доступу до файлів у тій самій точці у рядках Ubuntu. Якщо я скопіюю openssl.cnfфайл з CentOS VM на машини Ubuntu, це не має ніякого значення. У середовищі або файлі .rc нічого очевидного не може бути причиною цього.

Будь-які ідеї, що я роблю неправильно? Чи має це працювати, тобто чи має openssl і curl автоматично підбирати встановлені КА з командного рядка? Як це налаштовано? Дякую!

Ще один момент даних: на чистому встановленні 13-сервера curlвибирає файл сертифікатів і працює добре. openssl s_clientвсе ще не робить, хоча. Чому це було б?

У вашій системі є кілька криптографічних бібліотек:

• OpenSSL (золотий стандарт, ліцензія в стилі BSD (дуже безкоштовна), яка включає дещо проблематичне положення (запобігання сумісності GPL, але нічого "поганого"), що обмежує його прийняття у світі GNU)
• GnuTLS (заміна від FSF; постачається у двох варіантах, з ліцензією на LGPLv2 (але без збереження) та з LGPLv3 (і, таким чином, несумісний з програмами, що стосуються лише GPLv2); історично не настільки функціональний, як OpenSSL, трохи більш глючно, але суворіше теж підвищує безпеку)
• NSS (бібліотека Netscape / Mozilla, рідко використовується зовні; повільно приймати нові стандарти)
• незначні, такі як PolarSSL, MatrixSSL, NaCl / Salt

Усі вони мають, звичайно, схожість та відмінності. Програмне забезпечення, яке їх використовує (для криптографічних цілей або для використання SSL / TLS), іноді підтримує використання більш ніж однієї з цих бібліотек (наприклад, веб-браузер Lynx, як правило, пов'язаний з OpenSSL, але також підтримує GnuTLS (не дуже добре) у щоб заспокоїти людей ГНУ).

cURL також є одним із проектів, що підтримують використання будь-якої з трьох основних бібліотек криптовалют. Це здебільшого тому, що cURL є, головним чином, бібліотекою, призначеною для використання іншими програмами, коли вони хочуть завантажити (або навіть завантажити) речі за допомогою з'єднань http, ftp тощо. Інструмент curlкомандного рядка може надходити з будь-якого з цих варіантів.

Тепер я цілком впевнений, що проблема, яку ви бачите із ще не встановленою системою, полягає в наступному:

OpenSSL і GnuTLS підтримують використання /etc/ssl/certs/<hash>.<number>каталогів -style CA. Однак для OpenSSL версії 0.x та GnuTLS для обчислення згаданого хеша використовується інший алгоритм, ніж використовує OpenSSL версії 1.x. (Обидва можуть спільно існувати в системі; якщо різні сертифікати мають один і той же хеш, ви просто використовуєте для них різний номер . Але чомусь ca-certificatesпакет Debian / Ubuntu, схоже, не робить цього.) Крім того, деякі версії GnuTLS не мали підтримка за допомогою каталогу, але лише за допомогою файлу /etc/ssl/certs/ca-certificates.crt(яким також зазвичай керують ca-certificatesсценарії підтримки пакета, але може відхилятися); ти, здається, використовуєш старішу версію, тож це може бути те, що ти потрапив.

openssl s_clientза замовчуванням (тобто без параметра -CApathабо -CAfileопції) не шукає ніде сертифікатів.

Ваш curlз оновленої установки, швидше за все, використовує іншу криптобібліотеку, ніж curlзі свіжої інсталяції.

Спробуйте openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -connect the-problem-site.com:443додатково openssl s_client -CApath /etc/ssl/certs -connect the-problem-site.com:443імітувати поведінку старих версій GnuTLS.

Двічі перевірте, чи є OpenSSL 1.x десь у вашій системі (Ubuntu відомий тим, що прокрадається до основних оновлень навіть у версіях LTS), і якщо так, перевірте хеш файлу:

openssl x509 -noout -hash -in /etc/ssl/certs/GeoTrust_Global_CA.pem
openssl x509 -noout -subject_hash_old -in /etc/ssl/certs/GeoTrust_Global_CA.pem
openssl x509 -noout -subject_hash -in /etc/ssl/certs/GeoTrust_Global_CA.pem

Як правило, або друга, і третя команди повинні вийти з ладу (OpenSSL 0.x), або перша і третя команди повинні відображати один і той же хеш, але друга повинна відображати інший хеш (OpenSSL 1.x). GnuTLS використовує вихід з другої команди (якщо встановлено OpenSSL 1.x); якщо встановлено OpenSSL 0.x, це той самий хеш. Такі посилання можна створити вручну.

Я можу оновити цю публікацію, коли ви надасте зворотній зв'язок про налагодження.