Das Problem ist, dass openssl -verifydas nicht funktioniert.
Wie Priyadi erwähnt hat , openssl -verifystoppt es beim ersten selbstsignierten Zertifikat, daher überprüfen Sie die Kette nicht wirklich, da das Zwischenzertifikat häufig selbstsigniert ist.
Ich gehe davon aus, dass Sie zu 101% sicher sein möchten, dass die Zertifikatdateien korrekt sind, bevor Sie versuchen, sie im produktiven Webdienst zu installieren. Dieses Rezept hier führt genau diesen Pre-Flight-Check durch.
Bitte beachten Sie, dass die Antwort von Peter korrekt ist , die Ausgabe von openssl -verifyjedoch kein Hinweis darauf ist, dass danach wirklich alles funktioniert. Ja, es könnte einige Probleme geben, aber nicht alle.
Hier ist ein Skript, mit dem eine Zertifikatkette überprüft wird, bevor Sie sie in Apache installieren. Vielleicht kann dies mit etwas mystischerer OpenSSL-Magie verbessert werden, aber ich bin kein OpenSSL-Guru und folgende Werke:
#!/bin/bash
# This Works is placed under the terms of the Copyright Less License,
# see file COPYRIGHT.CLL. USE AT OWN RISK, ABSOLUTELY NO WARRANTY.
#
# COPYRIGHT.CLL can be found at http://permalink.de/tino/cll
# (CLL is CC0 as long as not covered by any Copyright)
OOPS() { echo "OOPS: $*" >&2; exit 23; }
PID=
kick() { [ -n "$PID" ] && kill "$PID" && sleep .2; PID=; }
trap 'kick' 0
serve()
{
kick
PID=
openssl s_server -key "$KEY" -cert "$CRT" "$@" -www &
PID=$!
sleep .5 # give it time to startup
}
check()
{
while read -r line
do
case "$line" in
'Verify return code: 0 (ok)') return 0;;
'Verify return code: '*) return 1;;
# *) echo "::: $line :::";;
esac
done < <(echo | openssl s_client -verify 8 -CApath /etc/ssl/certs/)
OOPS "Something failed, verification output not found!"
return 2
}
ARG="${1%.}"
KEY="$ARG.key"
CRT="$ARG.crt"
BND="$ARG.bundle"
for a in "$KEY" "$CRT" "$BND"
do
[ -s "$a" ] || OOPS "missing $a"
done
serve
check && echo "!!! =========> CA-Bundle is not needed! <========"
echo
serve -CAfile "$BND"
check
ret=$?
kick
echo
case $ret in
0) echo "EVERYTHING OK"
echo "SSLCertificateKeyFile $KEY"
echo "SSLCertificateFile $CRT"
echo "SSLCACertificateFile $BND"
;;
*) echo "!!! =========> something is wrong, verification failed! <======== ($ret)";;
esac
exit $ret
Beachten Sie, dass die Ausgabe danach EVERYTHING OKdie Apache-Einstellung ist, da Benutzer, die dies verwenden NginXoder haproxynormalerweise verwenden, dies auch perfekt lesen und verstehen können;)
Es gibt eine GitHub-Liste, die möglicherweise einige Updates enthält
Voraussetzungen dieses Skripts:
- Sie haben die vertrauenswürdigen CA-Stammdaten
/etc/ssl/certswie gewohnt, beispielsweise unter Ubuntu
- Erstellen Sie ein Verzeichnis,
DIRin dem Sie 3 Dateien speichern:
DIR/certificate.crt welches das Zertifikat enthältDIR/certificate.key welches den geheimen Schlüssel für Ihren Webservice enthält (ohne Passphrase)DIR/certificate.bundlewelches das CA-Bundle enthält. Informationen zur Vorbereitung des Bundles finden Sie weiter unten.
- Führen Sie nun das Skript aus:
./check DIR/certificate(Dies setzt voraus, dass das Skript checkim aktuellen Verzeichnis benannt ist.)
- Es ist sehr unwahrscheinlich, dass das Skript ausgegeben wird
CA-Bundle is not needed. Dies bedeutet, dass Sie (read /etc/ssl/certs/:) bereits dem Signaturzertifikat vertrauen. Dies ist jedoch im WWW höchst unwahrscheinlich.
- Für diesen Test muss Port 4433 auf Ihrer Workstation nicht verwendet werden. Führen Sie dies besser nur in einer sicheren Umgebung aus, da Port 4433 in Kürze für die Öffentlichkeit geöffnet wird, wodurch möglicherweise fremde Verbindungen in einer feindlichen Umgebung hergestellt werden.
Wie erstelle ich die certificate.bundleDatei?
Im WWW sieht die Vertrauenskette normalerweise so aus:
- vertrauenswürdiges Zertifikat von
/etc/ssl/certs
- unbekannte Zwischenzertifikate, möglicherweise von einer anderen Zertifizierungsstelle signiert
- Ihr Zertifikat (
certificate.crt)
Jetzt erfolgt die Auswertung von unten nach oben. Dies bedeutet, dass zuerst Ihr Zertifikat gelesen wird, dann das unbekannte Zwischenzertifikat benötigt wird, dann möglicherweise das Cross-Signing-Zertifikat und dann /etc/ssl/certskonsultiert wird, um das richtige vertrauenswürdige Zertifikat zu finden.
Das Ca-Bundle muss in genau der richtigen Verarbeitungsreihenfolge erstellt werden. Dies bedeutet, dass das erste benötigte Zertifikat (das Zwischenzertifikat, das Ihr Zertifikat signiert) an erster Stelle im Bundle steht. Dann wird das Cross-Signing-Zertifikat benötigt.
Normalerweise stellt Ihre Zertifizierungsstelle (die Behörde, die Ihr Zertifikat unterzeichnet hat) bereits eine solche ordnungsgemäße Ca-Bundle-Datei zur Verfügung. Wenn nicht, müssen Sie alle erforderlichen Zwischenzertifikate und catdiese zusammen in einer einzigen Datei (unter Unix) auswählen . Unter Windows können Sie einfach einen Texteditor (wie notepad.exe) öffnen und die Zertifikate in die Datei einfügen. Das erste wird oben benötigt und folgt den anderen.
Es gibt noch eine andere Sache. Die Dateien müssen im PEM-Format vorliegen. Einige Zertifizierungsstellen geben das DER-Format (ein Binärformat) aus. PEM ist leicht zu erkennen: Es ist ASCII-lesbar. Weitere Informationen zum Konvertieren von etwas in PEM finden Sie unter Konvertieren von .crt in .pem und Folgen der gelben Backsteinstraße.
Beispiel:
Du hast:
intermediate2.crt das Zwischenzertifikat, das Ihr unterschrieben hat certificate.crtintermediate1.crt ein weiteres Zwischenzertifikat, das sang intermediate2.crtcrossigned.crt Dies ist ein Cross-Signing-Zertifikat einer anderen Zertifizierungsstelle, die signiert hat intermediate1.crtcrossintermediate.crtDas ist ein weiteres Zwischenprodukt der anderen CA, die unterschrieben hat crossigned.crt(so etwas werden Sie wahrscheinlich nie sehen).
Dann würde das richtige catso aussehen:
cat intermediate2.crt intermediate1.crt crossigned.crt crossintermediate.crt > certificate.bundle
Und wie können Sie herausfinden, welche Dateien in welcher Reihenfolge benötigt werden oder nicht?
Nun, experimentiere, bis checkdir sagt, dass alles in Ordnung ist. Es ist wie ein Computer-Puzzlespiel, um das Rätsel zu lösen. Jeden. Single. Zeit. Auch für Profis. Aber Sie werden jedes Mal besser, wenn Sie dies tun müssen. Sie sind also definitiv nicht allein mit all dem Schmerz. Es ist SSL, weißt du? SSL ist wahrscheinlich eines der schlechtesten Designs, die ich je in über 30 Jahren professioneller Systemadministration gesehen habe. Haben Sie sich jemals gefragt, warum Krypto in den letzten 30 Jahren nicht zum Mainstream geworden ist? Deshalb. 'nuff sagte.
man verifyich verschiedene Optionen ausprobiert hatte , stellte ich fest, dass der-untrustedParameter der richtige ist, der bei der Angabe des Zwischenzertifikats verwendet werden soll.