Ich verwende CentOS, auf dem OpenSSL 1.0.2k-fips installiert ist, und habe parallel dazu Version 1.1.0g als Teil einer hier beschriebenen HTTP2-Installation erstellt und installiert:https://www.tunetheweb.com/performance/http2/
Ich habe 1.1.0g problemlos verwendet, aber vor kurzem habe ich die Zertifikate erneuert und jetzt scheint es beim Versuch, die CA zu verifizieren, verloren zu gehen. Der Speicherort der CA-Datei hat sich nicht geändert, die Version 1.0.2k-fips scheint damit gut zurechtzukommen, aber 1.1.0g kommt nicht über die Beschwerde hinaus:
Verify return code: 20 (unable to get local issuer certificate)
Ich habe also überprüft, dass die Zertifikate gültig sind, der Speicherort sich nicht geändert hat und ich keine Konfiguration manuell geändert habe.
Ich dachte, ich sollte vielleicht 1.1.0g neu erstellen, aber das ändert nichts. Ich habe auch versucht, die -CApathOption für den opensslBefehl zu verwenden, und zwar so (unter Verwendung desselben Verzeichnisses wie bei 1.0.2k-fips):
echo | /usr/local/ssl/bin/openssl s_client -connect example.com:443 -CApath /etc/pki/tls
Ich habe auch versucht -CAfile, direkt auf zu verweisen, ca-bundle.crtvon dem ich weiß, dass es die richtigen Zertifikate hat (1.0.2k-fips verwendet sie ohne Probleme), trotzdem keine Änderung.
Ich habe keine Ahnung, warum meine Zertifikate nicht erkannt werden, und frage mich, ob dieses Problem möglicherweise schon vor der Änderung der Zertifikate bestand (ich habe nach der Änderung geprüft, ob sie funktionierten. Möglicherweise war 1.1.0g zu diesem Zeitpunkt bereits defekt).
Ich denke, es könnte an Updates liegen, die am System durchgeführt wurden, wodurch ein Link oder eine Datei beschädigt wird, aber wo soll ich suchen, wenn das Zertifikatsmaterial ganz normal aussieht? Oder fehlen in 1.1.0g andere/weitere Zertifikate, auf die ich hinweisen muss?
Antwort1
Sie können s_client dazu bringen, Ihnen die Zertifikatskette mit folgendem anzuzeigen -showcerts:
openssl s_client -connect example.com:443 -showcerts </dev/null
Dies beginnt mit der Zertifikatskette und zeigt dann weitere Informationen zum Serverzertifikat und zur TLS-Verbindung an. All dies sollte Ihnen helfen, herauszufinden, wo das Problem liegt. Es könnte an einem Zwischenzertifikat liegen, nicht an der Zertifizierungsstelle.
Sie können eine schnelle Zusammenfassung der Zertifikatskette erhalten, indem Sie die Ausgabe filtern:
openssl s_client -connect example.com:443 -showcerts </dev/null 2>/dev/null |
sed -e '1,/Certificate chain/d' -e '/BEGIN CERTIFICATE/,/END CERTIFICATE/d' -e '/---/,$d'