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 -connect the-problem-site.com:443 -CAfile /etc/ssl/certs/GeoTrust_Global_CA.pem

тогда все работает. Сертификат также присутствует как файл с хеш-именем 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 с openssl 0.9.8e, то он будет работать нормально, и я вижу, что он читает файл сертификата в strace. В той же точке в Ubuntu нет эквивалентного доступа к файлу. Если я копирую openssl.cnfфайл с виртуальной машины CentOS на компьютеры с Ubuntu, это не имеет значения. Нет ничего очевидного в среде или файле .rc, которые могут быть причиной этого.

Есть идеи, что я делаю не так? Должно ли это работать, т.е. должен ли openssl и curl автоматически извлекать установленные CA из командной строки? Как это настроено? Спасибо!

Еще один момент данных: при чистой установке 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 (но не так хорошо) в чтобы успокоить людей GNU).

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, это тот же хеш. Вы можете создать такие символические ссылки вручную.

Я могу обновить эту публикацию, как только вы предоставите отзыв об отладке.