как заставить Gnu / Linux доверять сертификату, который доверяет Windows из коробки?

11

Существует сервер с разорванной цепочкой SSL, о чем сообщает эта проверка SSL :

Отчет о проверке SSL

Я знаю, что это проблема, которая должна решаться на самом сервере, но иногда это трудно исправить (я не администратор сервера).

Дело в том, что Chrome / Mozilla / Edge в Windows все равно доверяют сертификату сайта :

введите описание изображения здесь

Однако в развертывании Gnu / Linux (Ubuntu 18.04 в Docker) сертификат не является доверенным:

curl: (60) SSL certificate problem: unable to get local issuer certificate

Я попробовал update-ca-certificatesи даже импортировал корневой сертификат Globalsign. update-ca-certificatesсообщили дубликат сертификата в этом случае. Во всяком случае, ничего не работает.

Как воспроизвести

Используя Docker:

docker run -it ubuntu:18.04

# within container:
apt-get update
apt-get -y install curl
curl https://betriebsheft.vog.it  # <---- "unable to get local issuer certificate"

Как я могу заставить Gnu / Linux доверять этому сертификату?

PS: тот же сертификат правильно развернут на другом сервере .

Удо Г
источник
почему отрицание?
Udo G
1
Я голосую, чтобы закрыть этот вопрос как не по теме, потому что ФП спрашивает что-то, на что он не может повлиять сам. Он сказал, что не может ничего изменить на стороне сервера , так что это, вероятно, принадлежит суперпользователю, так как описывает проблему, не имеющую решения на стороне клиента.
LinuxSecurityFreak
2
Я специально прошу решение на стороне клиента . Я не могу влиять на сервер, но у меня есть полный контроль над клиентским O / S (Ubuntu), и я хочу, чтобы эта конкретная установка O / S доверяла сертификату, как и другие O / S (Windows). Речь не идет об исправлении HTTPS-сайта для других.
Udo G
1
Вы не управляете сервером, но все же можете сообщить о проблеме человеку, который контролирует сервер.
Майкл Хэмптон

Ответы:

11

Реальное исправление для этого - убедиться, что ваш сервер представляет все сертификаты в цепочке, а не только сертификат конечного объекта (сервера).

Укажите вашему администратору сервера раздел 7.4.2 RFC 5246, в котором четко указано, что это сообщение передает клиенту цепочку сертификатов сервера .


Если ваш администратор отказывается / не может сделать это по какой-то причине, альтернативный вариант - попытаться приступить curlк работе с неправильно сформированным рукопожатием.

Согласно сообщению в списке рассылки Curl:

Может кто-нибудь подтвердить, поддерживает ли cURL (или нет) промежуточный сертификат?

Да, это так. Все сертификаты CA имеют цепочку сертификатов, идущую до корня. Пакет ca, который вы используете с curl, должен состоять из сертификатов для всей цепочки.

/ daniel.haxx.se

Вы должны быть в состоянии добавить Root CA и все промежуточные сертификаты в пакет и указать curlна него, используя --cacert <file>опцию.

Поскольку ваши браузеры работают, вы можете получить доступ к правильным сертификатам CA оттуда. На вкладке сертификаты (разные для каждого браузера, но я уверен, что вы это выясните), просмотрите цепочку сертификатов. Дважды щелкните Root CA первого Globalsign Root CA - G1 и на Подробнее вкладке, щелкните Копировать в файл ... . Сохранить как root.cer. Сделайте то же самое с AlphaSSL CA - SHA256 - G2 и сохраните его как issuing.cer. Соедините их вместе в один файл (например chain.cer) и используйте это в качестве аргумента -cacert.

Как любезно указано @AB, недостающий сертификат также можно найти здесь .


Ваши браузеры работают, потому что они кэшируют сертификаты CA. Если вы когда-то переходили на правильно настроенный веб-сайт, сертификат которого был выдан тем же центром сертификации, что и сертификат вашего сервера, он будет кэшироваться браузером. При последующем посещении неправильно настроенного сайта ваш браузер будет использовать сертификаты CA в своем кэше для построения цепочки. Вам кажется, что все в порядке, хотя за кадром сервер неправильно настроен.

Обратите внимание, что в Windows IE / Edge и Chrome используют один и тот же кеш, а Firefox использует свой собственный.

В дополнение к вышесказанному IE / Edge и Chrome (поскольку они совместно используют один и тот же стек шифрования) будут использовать расширение в сертификатах, которое называется AuthorityInformationAccess . У этого есть опция caIssuer, которая предоставляет URL, с которого можно загрузить сертификат CA сертификата конечного объекта. Поэтому, даже если один из этих браузеров не кэшировал отсутствующие сертификаты из предыдущего просмотра, он может извлечь их при необходимости. Обратите внимание, что Firefox этого не делает, поэтому иногда Firefox может показывать ошибки сертификатов, когда IE / Edge и Chrome работают.

garethTheRed
источник
1
Это не мой сервер, поэтому не могу ничего изменить на стороне сервера. Я попытался использовать пакет CA из curl.haxx.se/docs/caextract.html (поскольку Firefox доверяет сертификату) и передать его с помощью, --cacert cacert.pemно CURL по-прежнему не принимает сертификат.
Удо G
1
Это является сервер. Запустите, echo q | openssl s_client -showcerts -connect betriebsheft.vog.it:443и вы увидите только один сертификат, представленный вашим сервером. Должно быть два - сертификат конечного объекта (который представлен) и выдающий CA - сертификат Alpha SSL - SHA256 - G2. Последний не отправляется сервером, но должен.
garethTheRed
2
@garethTheRed: Я понимаю, что сервер не предоставляет все сертификаты, но сервер не находится под моим контролем (это я имел в виду под словом «не мой сервер»). Я просто пытаюсь получить доступ к API на чужом сервере. Под Windows ни один из моих браузеров не жалуется на сертификат, только Linux / Debian / Ubuntu.
Udo G
@AB: спасибо большое! Установка всех корневых сертификатов с этой страницы решила проблему . Однако я хотел бы понять, почему этот ручной шаг необходим.
Udo G
2
Отсутствующий промежуточный сертификат (как упомянуто @garethTheRed) можно найти там: support.globalsign.com/customer/portal/articles/… . Первоначально OP только пытался добавить корневой сертификат, который, вероятно, уже был на месте, ничего не добившись.
AB