Wie das Root-CA-Zertifikat-Fingerabdruck erhalten mit OpenSSL

Question

Mit dem folgenden Befehl kann ich den SHA1-Fingerabdruck des vorgelegten Zertifikats überprüfen:

$ openssl s_client -connect hooks.slack.com:443 -showcerts < /dev/null 2>/dev/null | openssl x509 -in /dev/stdin -sha1 -noout -fingerprint 
SHA1 Fingerprint=AB:F0:5B:A9:1A:E0:AE:5F:CE:32:2E:7C:66:67:49:EC:DD:6D:6A:38 

Aber was ist, wenn ich den Fingerabdruck des Top Level erhalten möchten Unterschreibende Behörde?

Falls ich dies gegen einen Java Keystore verifizieren möchte, um definitiv zu prüfen, ob es dieselbe CA enthält.

geotrustglobalca, 18-Jul-2003, trustedCertEntry, 
Certificate fingerprint (SHA1): DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12 

Da "geotrustglobalca" und "/ C = US/O = GeoTrust Inc./CN=GeoTrust Globale CA" ist nicht wirklich vergleichbar.

Answer 1

Seit "Geotrustglobalca" und "/ C = US/O = GeoTrust Inc./CN = GeoTrust Global CA" sind nicht wirklich vergleichbar.

Ich werde in den Pool mit einer Antwort für "X.509 Certificate Äquivalenz" wandern, da es nicht sofort offensichtlich oder leicht zu bekommen.

Zuerst sollten Sie vorsichtig sein, Zertifikate auf Gleichheit zu vergleichen. Wenn <certificate bits 1> == <certificate bits 2>, dann können Sie sagen, dass sie das gleiche Zertifikat und gleich sind. Das Gegenteil gilt jedoch nicht.

Um das Gegenteil zu verstehen, müssen Sie zwei Dinge wissen. Erstens stellen Zertifizierungsstellen manchmal ein Zertifikat mit nahezu denselben Parametern erneut aus. Basierend auf dem Antragstellernamen sind sie gleichwertig; aber basierend auf den Bits sind sie nicht gleich. Einige Zertifizierungsstellen haben dies in der Vergangenheit getan, um von SHA-1 zu SHA-256 zu stoßen.

Die zweite Sache zu verstehen ist, was sind die wichtigen Bits, damit Sie feststellen können, ob Zertifikate gleichwertig sind. Die IETF hat kein X.509-Validierungsdokument. Der nächste ist RFC 4158: Internet X.509 Public Key Infrastructure: Certification Path Building, gemischt mit einigen anderen Dokumenten, wie Ausstellungsregeln (die nicht mit Validierungsregeln identisch sind).

Laut RFC 4158, können Sie eindeutig ein Zertifikat mit entweder identifizieren:

• {Issuer DN, Serial Number} Paar
• {Authority Key identifier (AKID), Subject Key identifier (SKID)} Paar

Die Ecke bei einem CA Wieder Ausstellen eines Root CA Ergebnisse in:

1. der Hash ändert
2. die Seriennummer ändert
3. der öffentliche Schlüssel bleibt
4. der Distinguished Name bleibt

Artikel (3), der öffentliche Schlüssel bleibt, ist bedeutsam, weil es bedeutet, weder die Authority Key Identifier (AKID) noch die Betreff Schlüsselkennung (SKID) ändert. Artikel (4), der Distinguished Name bleibt, ist wichtig, weil es, was viele Leute für den Vergleich verwenden (und es war die Ursache für viele Sicherheitsfehler im Laufe der Jahre).

In diesem Fall sind die Schlüsselbezeichner identisch, daher sollten Sie in Betracht ziehen, diese zu akzeptieren, auch wenn sich die Seriennummer geändert hat. (Die Seriennummer muss sich entsprechend der IETF- und CA/B-Regeln ändern).

Ein sehr seltsame Ecke Fall, die vor kurzem in der öffentlichen Schlüsseln Pinning kamen, stellt ein Server ein Elliptische-Kurven-Zertifikat mit Domain-Parametern (die vollständige Erweiterung der p, g, Q, etc), aber der Kunde erwartet eine benannte Kurve (wie secp256r1). Sollte dieser Schlüssel als gleichwertig akzeptiert werden? (Die IETF sagt, dass das Zertifikat die benannte Kurve verwenden muss).

---

die oben genannten Informationen gegeben, sind diese Informationen in Ihrem Vergleich nutzlos:

• "geotrustglobalca"

Und diese Informationen für Ihren Vergleich unvollständig:

• "/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA"

In diesem Fall sollten Sie auf der sicheren Seite bleiben und den Vergleich für Gleichheit oder Äquivalenz ablehnen.

Answer 2

In einer ähnlichen Situation mit einem encrypt Zertifikat des let auf einer Shared-Hosting-Lösung, die ich Erfolg die servername Parameter mit Angabe hatte:

openssl s_client -connect hooks.slack.com:443 -servername hooks.slack.com -showcerts < /dev/null 2>/dev/null | openssl x509 -in /dev/stdin -sha1 -noout -fingerprint 

Answer 3

Ich bin mir nicht sicher, dass dies Ihre Frage direkt beantwortet, aber wenn der Server präsentiert Das Root-Zertifikat als Teil der Kette (dies ist optional, so kann es nicht), können Sie die Option -showcerts verwenden, um alle zu zeigen.

Ich habe dies vorher zusammen (was hoffentlich jemand verbessern kann), um den Fingerabdruck für jedes der Zertifikate zu bekommen. Sie können mit den Argumenten zu openssl x509 am Ende spielen, um andere Informationen zu erhalten, wenn Sie brauchen.

echo "" | openssl s_client -showcerts -connect eistest.mtsu.edu:443 2>&1 |\ 
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p;/-END CERTIFICATE-/a\\x0' |\ 
sed -e '$ d' |\ 
xargs -0rl -I% sh -c "echo '%' | openssl x509 -subject -issuer -fingerprint -noout" 

eine leere Zeichenfolge zu openssl s_client Echoing hält es für den Anschluss an eine Auszeit von zu warten. Das erste sed gibt nur die PEM-formatierten Zertifikate aus, die durch ein NUL-Zeichen getrennt sind.