Почему curl работает с определенным https сайтом, а wget испытывает проблемы с сертификатами?

Question 1

CentOS 6. После недавнего обновления ca-certificates у меня возникли проблемы. У меня самые последние версии curl для CentOS 6:

-bash-4.1$ curl -V -v
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Протоколы: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp 
Особенности: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

И wget:

-bash-4.1$ wget -V -v
GNU Wget 1.12 собран на linux-gnu.

+digest +ipv6 +nls +ntlm +opie +md5/openssl +https -gnutls +openssl 
-iri 

Wgetrc: 
    /etc/wgetrc (система)
Локаль: /usr/share/locale 
Компиляция: gcc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc" 
    -DLOCALEDIR="/usr/share/locale" -I. -I../lib -O2 -g -pipe -Wall 
    -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
    --param=ssp-buffer-size=4 -m64 -mtune=generic -fno-strict-aliasing 
Ссылка: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
    -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic 
    -fno-strict-aliasing -Wl,-z,relro -lssl -lcrypto 
    /usr/lib64/libssl.so /usr/lib64/libcrypto.so -ldl -lrt ftp-opie.o 
    openssl.o http-ntlm.o gen-md5.o ../lib/libgnu.a 

Авторские права (C) 2009 Free Software Foundation, Inc.
Лицензия GPLv3+: GNU GPL версия 3 или более поздняя
<http://www.gnu.org/licenses/gpl.html>.
Это свободное программное обеспечение: вы можете изменять и распространять его.
Гарантий НЕТ, в том объеме, в котором это разрешено законом.

Изначально написано Хрвойе Никичем <[email protected]>.
В настоящее время поддерживается Микахом Кованом <[email protected]>.
Пожалуйста, отправляйте отчеты об ошибках и вопросы на <[email protected]>.

Теперь у меня проблема с сертификатами от CA https://www.certum.pl/. curl работает нормально:

-bash-4.1$ curl -v 'https://certum.pl/'
* Подключение к certum.pl на порт 443 (#0)
*   Пытаюсь 213.222.201.147... подключено
* Подключено к certum.pl (213.222.201.147) порт 443 (#0)
* Инициализация NSS с certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL-соединение с использованием TLS_DHE_RSA_WITH_AES_256_CBC_SHA
* Серверный сертификат:
*       предмет: CN=certum.pl,businessCategory=Private Organization,serialNumber=0000421310,incorporationState=pomorskie,incorporationLocality=Gdańsk,incorporationCountry=PL,postalCode=81-321,STREET=Podolska 21,ST=pomorskie,L=Gdynia,OU=Certification Authority Division,O=Asseco Data Systems S.A.,C=PL
*       дата начала: 16 авг 09:10:07 2017 GMT
*       дата окончания: 16 авг 09:10:07 2019 GMT
*       общее имя: certum.pl
*       издатель: CN=Certum Extended Validation CA SHA2,OU=Certum Certification Authority,O=Unizeto Technologies S.A.,C=PL
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: certum.pl
> Accept: */*
> 
< HTTP/1.1 302 Found
< Date: Tue, 17 Jul 2018 07:02:41 GMT
< Server: Apache
< Pragma: no-cache
< Location: https://www.certum.pl/pl/
< Content-Length: 209
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>Документ перемещен <a href="https://www.certum.pl/pl/">сюда</a>.</p>
</body></html>
* Закрытие соединения #0

Но wget возвращает ERROR:

-bash-4.1$ wget -d -O-  'https://certum.pl/'
Установка --output-document (outputdocument) в -
DEBUG вывод, созданный Wget 1.12 на linux-gnu.

--2018-07-17 09:04:42--  https://certum.pl/
Разрешение certum.pl... 213.222.201.147
Кэширование certum.pl => 213.222.201.147
Подключение к certum.pl|213.222.201.147|:443... подключено.
Создан сокет 3.
Освобождение 0x0000000000d2af00 (новое число ссылок 1).
Инициация SSL рукопожатия.
Успешное рукопожатие; подключенный сокет 3 к SSL-обработчику 0x0000000000d4bb40
сертификат:
  предмет: /C=PL/O=Asseco Data Systems S.A./OU=Certification Authority Division/L=Gdynia/ST=pomorskie/street=Podolska 21/postalCode=81-321/1.3.6.1.4.1.311.60.2.1.3=PL/1.3.6.1.4.1.311.60.2.1.1=Gda\\xC5\\x84sk/1.3.6.1.4.1.311.60.2.1.2=pomorskie/serialNumber=0000421310/businessCategory=Private Organization/CN=certum.pl
  издатель:  /C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Extended Validation CA SHA2
ERROR: невозможно проверить сертификат certum.pl, выданный `/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Extended Validation CA SHA2':
  Невозможно локально подтвердить полномочия издателя.
Чтобы подключиться к certum.pl небезопасно, используйте `--no-check-certificate'.
Закрыто 3/SSL 0x0000000000d4bb40

–ca-certificate=/etc/pki/tls/certs/ca-bundle.crt и для curl: --cacert /etc/pki/tls/certs/ca-bundle.crt

Версия ca-certificates сейчас 2018.2.22-65.1.el6 – самая новая. Версия openssl сейчас 1.0.1e-57.el6 – самая новая.

Есть ли у вас какие-либо идеи, что происходит?

Question 2

wget привязан к OpenSSL, в то время как curl привязан к библиотекам NSS, что, вероятно, объясняет, почему они используют разные хранилища доверия.

У меня нет системы RHEL 6 под рукой, но вероятно rpm -ql nss покажет другое/дополнительное хранилище доверия по сравнению с тем, что использует OpenSSL.

Этот ресурс Red Hat может быть актуален https://access.redhat.com/solutions/1549003

Кратко: update-ca-trust extract

Question 3

Мое рабочее решение для этой проблемы с CentOS 6 – добавить “отсутствующий” CA сертификат в хранилище доверия, которым управляет ca-certificates. Я не знаю, почему его убрали в этом обновлении. Итак:

Скопируйте корневой CA сертификат со страницы “https://certum.pl/” в /etc/pki/ca-trust/source/anchors/
Выполните: update-ca-trust enable
Выполните: update-ca-trust extract

Тем не менее, я все еще не знаю полностью, почему wget не работал, а curl работал. Когда я выполнил rpm -ql nss, не было информации о каком-либо другом хранилище доверия. Я не знаю, где его можно найти.

Question 4

В моем случае на системе RHEL 9 с STIG проблема заключалась в том, что файлы сертификатов CA, которые я добавил в /etc/pki/ca-trust/source/anchors/, имели права доступа, которые были слишком ограничительными (например, 0600), в результате чего система имела umask 0077. Поэтому только у root были права на чтение файлов сертификатов CA, так что wget мог проверять сертификаты только при запуске от имени root и завершал работу с ошибкой при запуске от обычного пользователя. Я был удивлен, потому что curl не нуждается в чтении этих файлов сертификатов CA и, следовательно, работал нормально, но, по-видимому, wget их читает.

Почему curl работает с определенным https сайтом, а wget испытывает проблемы с сертификатами?

Вопрос или проблема

Ответ или решение

Причины различий в работе curl и wget:

Решение проблемы:

Заключение: