Wie kann ich mit curl überprüfen, ob das Zertifikat einer Site widerrufen wurde?

25

Um zu überprüfen, ob das Zertifikat für google.com widerrufen wurde, habe ich den folgenden Befehl ausgeführt:

curl https://www.google.com --cacert GeoTrust_Global_CA.pem --crlfile gtglobal.pem -v

, aber ich habe den gefürchteten Fehler "SSL certificate problem" erhalten:

* About to connect() to www.google.com port 443 (#0)
*   Trying 81.24.29.91... connected
* successfully set certificate verify locations:
*   CAfile: GeoTrust_Global_CA.pem
  CApath: /etc/ssl/certs
* successfully load CRL file:
*   CRLfile: gtglobal.pem
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
* Closing connection #0
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html

Ich denke, dieser Fehler ist nicht korrekt, da Google ein gültiges Zertifikat haben sollte.

Wissen Sie, wie ich einen Curl-Befehl ausgeben kann, der dies korrekt ausführt?

Mehr Details

Wenn Sie sich fragen, warum ich diese spezifischen Dateien (GeoTrust_Global_CA.pem und gtglobal.pem) im Befehl curl verwendet habe, gehen Sie folgendermaßen vor:

  • Ich habe mir zuerst angesehen, von welcher Zertifizierungsstelle das Zertifikat für https://www.google.com ausgestellt wurde . Es stellte sich heraus, dass es sich um GeoTrust Global CA handelt.
  • Ich habe das GeoTrust Global CA-Stammzertifikat von hier heruntergeladen (dies ist die Datei GeoTrust_Global_CA.pem).
  • Ich habe die entsprechende CRL (Zertifikatssperrliste) von hier heruntergeladen (dies ist die Datei gtglobal.pem).
linux  certificate  curl 
— Claudiu
quelle
Scheint mir, als ob es schon funktioniert? Ich bin mir nicht sicher, was deine Frage ist.
— MTAK
1
@mtak - In Anbetracht der fehlgeschlagenen Überprüfung scheint der Autor nach dem Grund zu fragen, warum die Überprüfung des Zertifikats fehlgeschlagen ist. Das Zertifikat hätte überprüft werden müssen, da das aktuelle Google-Zertifikat nicht widerrufen wurde.
— Ramhound
Sorry, mir ist jetzt klar, dass die Frage etwas unklar ist. Ich werde es bearbeiten. @ Ramhound das ist richtig :)
— Claudiu
Ich verstehe im Prinzip nicht, warum Sie eine Verbindung zu google.com herstellen , um zu bestätigen, ob ein Zertifikat (das Sie bereits während des TLS-Handshakes erhalten haben) auf einer CRL vorhanden ist (die Sie bereits heruntergeladen haben). Sollten Sie das nicht auf Ihrem eigenen Computer tun? Was wäre, wenn google.com tatsächlich eine MITM wäre?
— Craig Hicks
Hier ist ein Beispiel für die manuelle Überprüfung eines Zertifikats. Ist auf einer CRL einmal beide das Zertifikat. und CRL befinden sich im lokalen Speicher --- feistyduck.com/library/openssl%2dcookbook/online/…
— Craig Hicks

Antworten:

12

Das ist mein alltägliches Drehbuch:

curl --insecure -v https://www.google.com 2>&1 | awk 'BEGIN { cert=0 } /^\* Server certificate:/ { cert=1 } /^\*/ { if (cert) print }'

Ausgang:

* Server certificate:
*    subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=www.google.com
*    start date: 2016-01-07 11:34:33 GMT
*    expire date: 2016-04-06 00:00:00 GMT
*    issuer: C=US; O=Google Inc; CN=Google Internet Authority G2
*    SSL certificate verify ok.
* Server GFE/2.0 is not blacklisted
* Connection #0 to host www.google.com left intact
— Antonio Feitosa
quelle
10

Anscheinend können Sie eine Site nicht einfach mit einer einzigen einfachen Anfrage überprüfen. Siehe /programming/16244084/how-to-programmatically-check-if-a-certificate-has-been-revoked?lq=1 und ältere verwandte Fragen zum Stackoverflow.

curl hat für mich weder unter Windows noch unter Linux mit Zertifikatswiderrufslisten funktioniert . Warum sollten Sie Locken verwenden ? Openssl scheint angemessener:

openssl s_client -connect www.google.com:443

Wir bekommen

---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---

Dann können wir überprüfen einige zertifikat:

curl http://pki.google.com/GIAG2.crt | openssl x509 -inform der -text

grep crlin der Ausgabe des obigen Befehls. Die interessanten Teile sind:

        X509v3 CRL Distribution Points:
            URI:http://crl.geotrust.com/crls/gtglobal.crl

        Authority Information Access:
            OCSP - URI:http://gtglobal-ocsp.geotrust.com

Jetzt können wir crl manuell überprüfen:

curl http://crl.geotrust.com/crls/gtglobal.crl | openssl crl -inform der -text
curl http://pki.google.com/GIAG2.crl | openssl crl -inform der -text

Jetzt sehen wir eine Liste der gesperrten Zertifikate. IMHO, mit curl ist nicht genug, ein anderes Programm ist erforderlich, um Zertifikate zu überprüfen. Mit einem einfachen

strace curl https://www.google.com   -v

Wir sehen, dass Curl keine Widerrufsbelehrung überprüft (auch keine Verbindung zu den relevanten Stellen). Es heißt nur

* Server certificate:
*        subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=www.google.com
*        start date: 2014-04-09 11:40:11 GMT
*        expire date: 2014-07-08 00:00:00 GMT
*        subjectAltName: www.google.com matched
*        issuer: C=US; O=Google Inc; CN=Google Internet Authority G2
*        SSL certificate verify ok.
— MKaama
quelle
2
Warum kann Curl das nicht? Die Manpage curl gibt die Option '--crlfile' an, die genau für diesen Zweck existiert. Außerdem wird curl mit openssl kompiliert und für seine kryptobezogenen Operationen (einschließlich Zertifikaten) verwendet - es funktioniert nur nicht bei mir und versucht herauszufinden, warum :)
— Claudiu
3

Anscheinend ist dies ein ziemlich häufiges Problem unter Windows, wie diese Frage zum Stackoverflow zeigt . Ich beziehe mich speziell auf die Antwort des Benutzers Артур Курицын, die ich hier zur Vereinfachung zitiere:

Es ist ein ziemlich häufiges Problem in Windows. Sie müssen nur Satz cacert.pemzu curl.cainfo.

Seit PHP 5.3.7 haben Sie folgende Möglichkeiten:

  1. Laden Sie http://curl.haxx.se/ca/cacert.pem herunter und speichern Sie es irgendwo.
  2. update php.ini- add curl.cainfo = "PATH_TO / cacert.pem"

Andernfalls müssen Sie für jede cURL-Ressource Folgendes ausführen:

curl_setopt ($ch, CURLOPT_CAINFO, "PATH_TO/cacert.pem");

Auch dieser Artikel könnte auch nützlich sein.

— user1301428
quelle
Soweit ich weiß, entspricht die Befehlszeilenoption '--cacert' (die ich verwendet habe) dem Festlegen der Option CURLOPT_CAINFO in libcurl, sodass ich nicht glaube, dass dies das Problem in meinem Fall ist (auch ich bin es) unter Linux)
— Claudiu
Nicht genau die Antwort auf die Frage, noch sehr nützliche Informationen!
— Amenthes
1

Ich habe festgestellt, dass die Arbeitsweise derjenigen ähnelt, die bereits belichtet wurden, nur dass die Ausgabe an dev/nullgesendet wird und die Verwendung relativ schnell erfolgt.

curl -L -v -s https://www.google.de 1>/dev/null

# curl -L -v -s https://www.google.de 1>/dev/null
* About to connect() to www.google.de port 443 (#0)
*   Trying 216.58.208.35...
* Connected to www.google.de (216.58.208.35) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*   subject: CN=www.google.de,O=Google LLC,L=Mountain View,ST=California,C=US
*   start date: Okt 23 16:53:00 2018 GMT
*   expire date: Jan 15 16:53:00 2019 GMT
*   common name: www.google.de
*   issuer: CN=Google Internet Authority G3,O=Google Trust Services,C=US
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.google.de
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Mon, 12 Nov 2018 15:36:17 GMT
< Expires: -1
< Cache-Control: private, max-age=0
< Content-Type: text/html; charset=ISO-8859-1
< P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."
< Server: gws
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
< Set-Cookie: 1P_JAR=2018-11-12-15; expires=Wed, 12-Dec-2018 15:36:17 GMT; path=/; domain=.google.de
< Set-Cookie: NID=146=4SDchvTa39-4IskdXfZpgjtm2ym5zzvHVx8g0v39Q1fiOzk26NQl1TGkFMllh_pg8bFWr6x4jG3ODYDWrkn6TXmd0Ewp4DC_N3p1NPlWqdBUfwFR_PTHIXRi8RuTxdA54w9Zr0uNyhN__5xjUdrCLZTLujNEQ2MV9EVwnmxux6o; expires=Tue, 14-May-2019 15:36:17 GMT; path=/; domain=.google.de; HttpOnly
< Alt-Svc: quic=":443"; ma=2592000; v="44,43,39,35"
< Accept-Ranges: none
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
<
{ [data not shown]
* Connection #0 to host www.google.de left intact
— Pierfrancesco PierQR Aiello
quelle
Dies scheint nichts darüber zu sagen, ob das Zertifikat der Site widerrufen wurde. In der Tat wird dies gemäß der Dokumentation curlunter Unix nicht überprüft (es sei denn, Sie kompilieren es speziell mit einer SSL-Bibliothek, die dies automatisch für Sie erledigt).
— Tripleee
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.