Невозможно локально проверить полномочия эмитента

19

Я не могу открыть URL-адреса https с помощью wget или curl:

$ wget https://www.python.org
--2015-04-27 17:17:33--  https://www.python.org/
Resolving www.python.org (www.python.org)... 103.245.222.223
Connecting to www.python.org (www.python.org)|103.245.222.223|:443... connected.
ERROR: cannot verify www.python.org's certificate, issued by "/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA":
  Unable to locally verify the issuer's authority.
To connect to www.python.org insecurely, use '--no-check-certificate'.

$ curl https://www.python.org
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Это использует wget 1.12 и curl 7.30.0 на CentOS 5.5. Похоже, что-то не так с моим локальным хранилищем сертификатов, но я не знаю, как действовать дальше. Есть идеи?

Обновление: после обновления пакета openssl с 0.9.8e-12.el5_4.6 до 0.9.8e-33.el5_11, теперь есть другая ошибка:

$ wget https://pypi.python.org
--2015-04-28 10:27:35--  https://pypi.python.org/
Resolving pypi.python.org (pypi.python.org)... 103.245.222.223
Connecting to pypi.python.org (pypi.python.org)|103.245.222.223|:443... connected.
ERROR: certificate common name "www.python.org" doesn't match requested host name "pypi.python.org".
To connect to pypi.python.org insecurely, use '--no-check-certificate'.
centos  ssl  certificates 
— ACO
источник
Я думаю, что корневые сертификаты находятся в ca-certificatesпакете. Этот пакет установлен? Может быть, попробуйте переустановить его. Если это не проблема, запустите strace -o /tmp/wget.strace wget https://www.python.orgи опубликуйте полученную трассировку, которая должна сообщить нам, где проблема.
— Жиль "ТАК - перестань быть злым"
@Gilles - я обновил пакет openssl с 0.9.8e-12.el5_4.6 до 0.9.8e-33.el5_11 и ошибка исчезла (возможно, это переустановило корневые сертификаты?), Но теперь есть другая ошибка.
— aco
Это похоже на временную ошибку с этим конкретным сайтом. Работают ли другие сайты?
— Жиль "ТАК - перестань быть злым"
@Gilles - другие сайты тоже не работают. Например, Google возвращает ошибку: общее имя сертификата "google.com" не соответствует запрашиваемому имени хоста "www.google.com.au".
— aco
Я мог бы решить ту же проблему, отключив Selinux: crypt.gen.nz/selinux/disable_selinux.html Cheers!

Ответы:

4

Проблема заключается в отсутствии поддержки для индикации имени сервера. Вам нужен как минимум wget 1.14 или curl 7.18.1 и вам нужен как минимум OpenSSL 0.98f, согласно Википедии:

https://en.wikipedia.org/wiki/Server_Name_Indication#Implementation

— Чак Е
источник
1
Я использую: GNU Wget 1.19.4 и OpenSSL 1.1.1, и я все еще получаю ту же ошибку.
— mchid
4

У меня была похожая ошибка с https://excellmedia.dl.sourceforge.net/project/astyle/astyle/astyle%203.0.1/astyle_3.0.1_linux.tar.gz на образе докера (circleci / jdk8: 0.1. 1),

В моем случае обновление CA-сертификатов решило проблему:

sudo apt-get install ca-certificates
— Суровая Кумар Бхартия
источник
Спасибо! Отлично работал на Ubuntu 16.04. Я должен был переустановить CA-сертификаты
— Ubuntuser
2

wgetдо 1.14 не поддерживает альтернативное имя субъекта (SAN) *. PyPI использует SAN в качестве альтернативы своему CN в своем сертификате, а wget задыхается от несоответствия. Обновление wget должно разрешить это.

* или, возможно, указание имени сервера (SNI) - я не уверен, что здесь применимо.

Ссылки:

— Хит Рафтери
источник
1

Решение 1:

openssl s_client -connect whateversite.com:443 -debug

Получите ключ сертификата и скопируйте в /etc/ssl/certs.

$ wget https://www.python.org --ca-certificate=/etc/ssl/certsfile

Если вы хотите пойти небезопасным путем, попробуйте решение 2

Решение 2:

$ wget https://www.python.org --no-check-certificate

или используя Curl 

$ curl https://www.python.org --insecure
— Рубан Савви
источник
9
«Доктор, я не могу ходить по левой ноге. - Решение 1: подвиньте то, что вам нужно, к вашему стулу, чтобы вам не нужно было стоять. Решение 2: хоп ». Нет, решение состоит в том, чтобы вылечить проблему. Что здесь означает восстановление или переустановку корневых сертификатов CA.
— Жиль "ТАК - перестань быть злым"
4
это хорошо только для самоподписывающемхся самоуправления выдано сертификатов
— Павел Niedoba
1
Да, это плохая идея. Решение 1 тоже небезопасно . Все, что вы делаете, это обходя проверку wget, автоматически доверяя сертификату с этого момента. Вы должны исправить основную проблему, фактически исправив корневые сертификаты, к которым имеет доступ wget.
— Эндрю Ферье
Хотя это только обходной путь, если ваши системные администраторы заставляют вас использовать поврежденные списки корневых сертификатов или драконовские настройки безопасности, это не заслуживает ненависти.
— Нуреттин
0

Обновите время на сервере. Одна секунда может вызвать эту проблему!

Проверить с: date

Redhat / CentOS 6/7 yum -y install ntpdate; /usr/sbin/ntpdate -u pool.ntp.org

Ubuntu / Debian apt-get -y install ntpdate; /usr/sbin/ntpdate -u pool.ntp.org

— user1926449
источник
0

echo "check_certificate = off" >> ~ / .wgetrc

— Роберт А
источник
1
Это довольно опасно, чтобы предположить.
— заговор
Это касается только wgetкоманды, и это не решение, а обходной путь.
— mrc02_kr
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.