Nie można lokalnie zweryfikować uprawnień emitenta

19

Nie mogę otworzyć żadnych adresów URL https za pomocą wget lub 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.

Korzysta z wget 1.12 i curl 7.30.0 na CentOS 5.5. Wygląda na to, że coś jest nie tak z moim lokalnym magazynem certyfikatów, ale nie mam pojęcia, jak to zrobić. Jakieś pomysły?

Aktualizacja: Po zaktualizowaniu pakietu openssl z wersji 0.9.8e-12.el5_4.6 do 0.9.8e-33.el5_11 występuje teraz inny błąd:

$ 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'.
aco
źródło
Myślę, że główne certyfikaty są w ca-certificatespakiecie. Czy ten pakiet jest zainstalowany? Może spróbuj go ponownie zainstalować. Jeśli to nie jest problem, uruchom strace -o /tmp/wget.strace wget https://www.python.orgi opublikuj wynikowy ślad, który powinien nam powiedzieć, gdzie jest problem.
Gilles „SO- przestań być zły”
@Gilles - Zaktualizowałem pakiet openssl z 0.9.8e-12.el5_4.6 do 0.9.8e-33.el5_11 i błąd zniknął (być może ponownie zainstalowałem certyfikaty root?), Ale teraz jest inny błąd.
aco
Wygląda to na przejściowy błąd w tej konkretnej witrynie. Czy działają inne witryny?
Gilles „SO- przestań być zły”
@Gilles - Inne strony również nie działają. Na przykład Google zwraca błąd: nazwa zwyczajowa certyfikatu „google.com” nie zgadza się z żądaną nazwą hosta „www.google.com.au”.
aco
Mógłbym rozwiązać ten sam problem wyłączając Selinux: crypt.gen.nz/selinux/disable_selinux.html Na zdrowie!

Odpowiedzi:

2

wgetprzed wersją 1.14 nie obsługuje alternatywnej nazwy podmiotu (SAN) *. PyPI używa SAN jako alternatywy dla swojej CN w swoim certyfikacie, a wget dusi się z powodu niezgodności. Uaktualnienie wget powinno go rozwiązać.

* lub ewentualnie Wskazanie nazwy serwera (SNI) - nie jestem pewien, co dotyczy tutaj.

Bibliografia:

Heath Raftery
źródło
1

Rozwiązanie 1:

openssl s_client -connect whateversite.com:443 -debug 

Uzyskaj klucz certyfikatu i skopiuj do /etc/ssl/certs.

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

Jeśli chcesz przejść w niepewny sposób, wypróbuj rozwiązanie 2

Rozwiązanie 2:

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

lub Korzystanie Curl

$ curl https://www.python.org --insecure
Ruban Savvy
źródło
9
„Doktorze, nie mogę chodzić na lewej nodze. - Rozwiązanie 1: przesuń to, czego potrzebujesz, blisko swojego krzesła, aby nie trzeba było stać. Rozwiązanie 2: chmiel. ”Nie, rozwiązaniem jest rozwiązanie problemu. Co tutaj oznacza naprawę lub ponowną instalację certyfikatów głównego urzędu certyfikacji.
Gilles „SO- przestań być zły”
4
jest to dobre tylko w przypadku samopodpisanych certyfikatów
Pavel Niedoba
1
Tak, to zły pomysł. Rozwiązanie 1 jest również niepewne . Wszystko, co robisz, to omijanie sprawdzania wget poprzez automatyczne zaufanie do certyfikatu od tego momentu. Powinieneś naprawić podstawowy problem, faktycznie naprawiając certyfikaty root, do których dostęp ma wget.
Andrew Ferrier
Chociaż jest to tylko obejście problemu, jeśli administratorzy systemu zmuszają cię do korzystania z uszkodzonych list certyfikatów głównych lub drakońskich ustawień bezpieczeństwa, nie zasługuje na nienawiść.
nurettin
0

Zaktualizuj czas na serwerze. Jedna sekunda może spowodować ten problem!

Sprawdź z: 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

użytkownik1926449
źródło
0

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

Robert A.
źródło
1
Jest to raczej niebezpieczne sugerowanie.
ploth
Dotyczy to tylko wgetpolecenia i nie jest rozwiązaniem, ale obejściem.
mrc02_kr