November 25, 2020
Articles
Keine Kommentare

So erhalten Sie openssl zur Verwendung eines Zertifikats ohne Angabe über -CAfile

Ich verwende diesen Befehl: 

openssl s_client -connect example.com:443 -CAfile /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem

Es funktioniert. Wenn ich diese CA-Datei nicht spezifiziere, erhalte ich einen Code 20. Das Zertifikat befindet sich in /etc/ssl/certs und /usr/lib/ssl/certs -> /etc/ssl/certs Es ist auch in der ca-certificates.crt

enthalten. Was regelt, ob openssl mein Zertifikat finden kann oder nicht und wie kann ich es akzeptieren lassen? Dieses Zertifikat ohne explizite Angabe?

Kommentare

  • Ist GTE_CyberTrust_Global_Root.pem eine Zwischenzertifizierungsstelle? In diesem Fall kann es sein, dass Ihr Webserver dieses Zwischenzertifizierungsstellenzertifikat nicht zusammen mit Ihrem Standortzertifikat bereitstellt. Dieser Mangel Ihres Webservers kann bei einigen Computern zu Kompatibilitätsproblemen führen. Wenn das GTE_CyberTrust_Global_Root.pem ein Stammzertifikat der obersten Ebene ist, sollte es standardmäßig funktionieren.
  • @GeorgeBailey Vielen Dank. Es ist mittelschwer. Kein wirklicher Grund, den Standort nicht zu teilen: bigfishgames-a.akamaihd.net:443 Wenn ich ' unsere Web-Leute auffordere, dies zu beheben, was würde ich fragen? Fühlen Sie sich frei, Ihre Antwort zu einer Antwort zu machen (dh " Sie können auf dem Client nichts tun, der Server muss X " ausführen).
  • Das ' ist seltsam. Ich hätte erwartet, dass es funktioniert, wenn es in / etc / ssl / certs und ca-certificates.crt enthalten ist.
  • Nun, ' ist noch nicht klar, ob der Server ist das Problem. Es sieht so aus, als würde der Server eine Zwischenzertifizierungsstelle bedienen und SSLLabs behandelt CyberTrust als Root der obersten Ebene. Sie können sich irren, wenn CyberTrust ein Intermediate ist, aber vielleicht haben Sie Recht. Ich ' bin mir nicht sicher. Überprüfen Sie die Zertifikatkette / den Zertifikatpfad in Ihrem bevorzugten Browser und / oder in SSLLabs . Vielleicht ist openssl nicht mit Root-Zertifikaten der obersten Ebene konfiguriert? Haben Sie versucht, google.com:443?
  • Gleiches Verhalten für google.com

Antwort

Es gibt einen bekannten OpenSSL-Fehler, bei dem s_client den Standardzertifikatsspeicher nicht überprüft, wenn Sie die -CApath oder -CAfile. OpenSSL unter Ubuntu 14.04 leidet unter diesem Fehler, wie ich zeigen werde:

Version: 

ubuntu@puppetmaster:/etc/ssl$ openssl version OpenSSL 1.0.1f 6 Jan 2014

Kann den Standardspeicher nicht verwenden, wenn ich Übergeben Sie nicht das `-ca: 

ubuntu@puppetmaster:/etc/ssl$ openssl s_client -quiet -connect gmail.com:443 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify error:num=20:unable to get local issuer certificate verify return:0

Jetzt übergebe ich null als -CApath und es funktioniert: 

ubuntu@puppetmaster:/etc/ssl$ openssl s_client -quiet -connect gmail.com:443 -CApath /dev/null depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = mail.google.com verify return:1

Leider glaube ich nicht, dass eine Liste der betroffenen OpenSSL-Versionen existiert. Sie können sie nur testen.

Kommentare

  • Danke. Ich habe diese Version verwendet. OpenSSL 1.1.0 scheint das Problem nicht behoben zu haben. I ' m Das hier aufgeführte Problem wird nicht angezeigt: github.com/openssl/openssl/issues Können Sie auf das Problem verweisen?
  • Es ' s im alten RT-Issue-Tracker . Dort gibt es einen Patch, ' s hinter einem Login (Gast: Gast) Es ist ' das Problem # 3697, das als behoben markiert wurde. rt.openssl.org/Ti cket / Display.html? id = 3697
  • Ok, ich habe bestätigt, dass dies in 1.1 behoben ist, zumindest in der Richsalz-Gabel. Beim Upgrade habe ich zunächst nicht bemerkt, dass das Basisverzeichnis auf /usr/local/ssl verschoben wurde, wobei ein Zertifikatsverzeichnis nicht /etc/ssl/certs zugeordnet war.
  • Ich kann überprüfen, ob der Fehler in CentOS 6.8 vorhanden ist (OpenSSL 1.0.1e-fips, 11. Februar 2013).
  • Außerdem gibt openssl version -d das Basiskonfigurationsverzeichnis an …

Antwort 

"How to get openssl to use a cert without specifying it via -CAfile".

Ich hatte das gleiche Anforderung. Ich wollte ein Verzeichnis von Zertifizierungsstellen verwenden, denen ich " " lokal vertraute. Ich wollte keine standardmäßigen Trust store umweltschädlichen Ergebnisse.

c_rehash

Bevor ich den Befehl verify aufrief, führte mich die Hilfeseite: man verify zur Verwendung von c_rehash:

Rehash scannt Verzeichnisse und berechnet einen Hashwert für jedes " .pem ", " .crt ", " .cer " oder " .crl " in der Datei angegebene Verzeichnisliste und erstellt symbolische Links für jede Datei 

export CERTS=/Users/{path_to_your_certs} [path to openssl]/openssl/bin/c_rehash ${CERTS}

Überprüfen Sie ein Blattzertifikat 

openssl verify -CApath ${CERTS} local_leaf.pem local_leaf.pem: OK

Sie laden die Stammzertifizierungsstelle und IntCA in das Verzeichnis CERTS.Wenn ich den Aufbereitungsschritt nicht ausführen würde, würde ich den Fehler 20 unable to get local issuer certificate.

erhalten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.