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до сих пор нет. С чего бы это?
1 ответ
В вашей системе есть несколько криптографических библиотек:
- OpenSSL (золотой стандарт, с лицензией в стиле BSD (очень бесплатная), которая включает в себя несколько проблематичное предложение (предотвращающее совместимость с GPL, но ничего «Плохо») ограничивает его принятие в мире GNU)
- GnuTLS (замена от FSF; поставляется в двух вариантах: LGPLv2-лицензируется (но не поддерживается) и LGPLv3-лицензируется (и, следовательно, несовместим с GPLv2-only программ); исторически не такой функциональный, как OpenSSL, немного более глючный, но и более строгий, что повышает безопасность)
- NSS (библиотека Netscape / Mozilla, редко используемая снаружи; медленная для принятия новых стандартов)
- второстепенные, такие как PolarSSL, MatrixSSL, NaCl / Salt
Все они, конечно, имеют сходства и различия. Программное обеспечение, которое их использует (для криптографических целей или для использования SSL / TLS), иногда поддерживает использование более чем одной из этих библиотек (например, веб-браузер Lynx, как правило, связан с OpenSSL, но также поддерживает GnuTLS (но не так хорошо) в чтобы успокоить людей GNU).
cURL также является одним из проектов, поддерживающих использование одной из трех основных криптографических библиотек. Это в основном потому, что cURL - это, в первую очередь, библиотека, предназначенная для использования другими программами, когда они хотят загружать (или даже загружать) вещи, используя соединения http, ftp и т. Д. Инструмент командной строки curl может быть из любого из этих вариантов.
Теперь я совершенно уверен, что проблема, с которой вы сталкиваетесь с неустановленной системой, заключается в следующем:
OpenSSL и GnuTLS поддерживают использование каталогов CA в стиле /etc/ssl/certs/<hash>.<number>. 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, это тот же хеш. Вы можете создавать такие символические ссылки вручную.
Я могу обновить эту публикацию, как только вы предоставите отзыв об отладке.