SSL-Stammzertifizierungsstellenzertifikat wird nicht erkannt, obwohl es im Trust Store vorhanden ist. Warum?

Hintergrund:

Ubuntu Server 14.10 64-Bit auf aws.amazon.com/ec2
Günstiges PositiveSSL Server Zertifikat von COMODO
1 Server-Zertifikat, 2 Zwischen-CA-Zertifikate und 1 Root-CA-Zertifikat als ZIP-Archiv von COMODO
Zitadelle WebCit httpsd

Problem:

Die verkettete Zertifikatkette scheint korrekt zu sein, die Überprüfung schlägt jedoch fehl.

openssl s_client myhost:port

Zeigt die Zertifikatskette und die Aussteller-Betreff-Paare korrekt in der Kette an, aber:

verify error:num=19:self signed certificate in certificate chain

Das Zertifikat der Stammzertifizierungsstelle wird von openssl nicht akzeptiert, obwohl es standardmäßig im Ubuntu Server Trust Store gefunden wird.

Konkret: AddTrustExternalCARoot.crtPer E-Mail von COMODO erhalten und /etc/ssl/certs/AddTrust_External_Root.pemwelche Links /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt identisch sind.

Was ist hier falsch?

linux ssl certificate Reinhard Seifert
quelle

Wenn Sie Firefox oder Chrome verwenden, um eine Verbindung zu Ihrer Site herzustellen, erhalten Sie eine Zertifikatswarnung?

John Siu

Nicht Firefox. Ich benutze Citadel.org als E-Mail-Server und die SSL-Zertifikate sind für SMTPS auf den Ports 465 und 587. In der Tat beschwert sich Thunderbird nicht.

Reinhard Seifert

Das Firefox-Problem hat meinen Post hier ausgelöst. Oh Mann, ich bin müde. Also, Thunderbird beschwert sich nicht über SMTPS, aber Firefox zeigt die HTML-Seite nicht an und ich vermute, es wird das Zertifikat angezeigt, da bei Verwendung openssl s_clientdes HTML-Codes der Seite angezeigt wird und w3m auch die Seite nach der Beschwerde über das nicht vertrauenswürdige Zertifikat anzeigt . Aber Firefox zeigt die Seite einfach nicht an, ohne eine Warnung über das Zertifikat zu erhalten.

Reinhard Seifert

Versuchen Sie den Browsertest mit einem anderen Gerät. Verwenden Sie nach Möglichkeit auch die neueste Version. Ich beginne zu vermuten, dass der für den Test verwendete Computer ein Root-CA-Paket-Update benötigt.

John Siu

Danke Jungs! Versuchte es auf einem anderen Rechner und es funktioniert jetzt sowohl in Firefox als auch in Thunderbird. Dies sagte, es scheint, dass Jotaps Antwort richtig ist. Obwohl es mit openssl verify -CAfile chained.crt chained.crtopenssl noch seltsamer ist: Übergibt "OK" (chained.crt ist das verkettete Zertifikat mit Server-Zertifikat, Zwischenzertifikaten und Root-CA-Zertifikat)! Für mich ist dies ein inkonsistentes und seltsames Verhalten von openssl. Die Zertifikatskette ist korrekt, das letzte Zertifikat befindet sich im Truststore und openssl erkennt es sowohl als einzelnes Zertifikat als auch als CA-Datei, jedoch nicht als letztes in einer Kette. Ist das ein Bug?

Reinhard Seifert

Antworten:

OpenSSL hat zumindest durch current (1.0.2a) einen Fehler, bei dem s_clientmit NO- -CA{path,file}Argument der Standard-Truststore nicht ordnungsgemäß verwendet wird und daher Zertifikate, die gemäß diesem Truststore gültig sind, nicht überprüft werden können. (Auch s_serverund s_time, aber die Überprüfung ist selten.) Siehe https://serverfault.com/questions/607233/how-to-make-openssl-s-client-using-default-ca . Ein Fix wird in dev angekündigt, es kann jedoch einige Zeit dauern, bis er veröffentlicht und verteilt wird. In der Zwischenzeit müssen Sie die -CA*Argumente explizit angeben . Beachten Sie, dass openssl verifydieser Fehler nicht vorliegt und dass das Zertifikat / die Kette daher korrekt als gültig gemeldet wurde.

UPDATES 26.08.2015: Update wurde am 12.06.2015 in 1.0.1o und 1.0.2c veröffentlicht. Als ich etwas anderes untersuchte, stellte ich außerdem fest, dass RedHat-Pakete möglicherweise in Ordnung waren . Genauer gesagt ist die CentOS-Quell-RPM, für openssl-1.0.1e-30.el6.11die ich verstehe, eine Kopie der RedHat- RPM (die sich jedoch nicht leicht bestätigen lässt), openssl-1.0.1c-default-paths.patchdie Änderungen s_client.c s_server.c s_time.cvom 06.12.2012 enthält, die der Version 2015 äquivalent (aber inhaltlich nicht identisch) zu sein scheinen / 06/12 Upstream-Korrekturen. Unter der Annahme, dass dieser Patch in RedHat- und CentOS-Paketen angewendet wurde, die ich nicht ohne Weiteres überprüfen kann, würden sie wie erwartet funktionieren.

dave_thompson_085
quelle

Danke. Das hat die Sache geklärt und in der Tat hat es mich ausnahmsweise nicht durcheinander gebracht ... im Browser und MUA wird die Kette akzeptiert.

Reinhard Seifert

Ich hatte kürzlich ein ähnliches Problem mit Comodo-Zertifikaten, als ich ein Skript mit Ruby entwickelte. Am Ende war es so, dass OpenSSL es nicht im Laden hatte, obwohl es so aussah.

Um dies zu testen, laden Sie alle Zwischenzertifikate von Comodo herunter und erstellen Sie so etwas wie ein Zertifikat-Bundle (Sie müssen je nach dem, was Sie heruntergeladen haben, unterschiedliche Zertifikatsnamen verwenden):

cat EssentialSSLCA_2.crt ComodoUTNSGCCA.crt UTNAddTrustSGCCA.crt AddTrustExternalCARoot.crt > yourDomain.ca-bundle

Comodo hat einen Artikel dazu.

Versuchen Sie anschließend erneut, das Zertifikat mit OpenSSL zu überprüfen und den Zertifikatsspeicher in der Befehlszeile anzugeben:

openssl verify -untrusted yourDomain.ca-bundle cert.pem

Dieses Beispiel wurde aus diesem Artikel zu Unix und Linux StackExchange übernommen .

Sobald Sie festgestellt haben, um welches Zertifikat es sich handelt, sollte es möglich sein, das Zertifikat zum lokalen Zertifikatspeicher hinzuzufügen. Dies wird hier für Ubuntu beschrieben und sieht in etwa so aus:

Erstellen Sie ein Verzeichnis für zusätzliche CA-Zertifikate in / usr / share / ca-certificates

sudo mkdir /usr/share/ca-certificates/extra

Kopieren Sie die CRT-Datei in das Verzeichnis

sudo cp foo.crt /usr/share/ca-certificates/extra/foo.crt

Lassen Sie Ubuntu den Pfad der '.crt'-Datei relativ zu / usr / share / ca-certificates zu /etc/ca-certificates.conf hinzufügen

sudo dpkg-reconfigure ca-certificates

Jotap
quelle

Dies ist auch meine Vermutung, deshalb bitte ich OP, mit einem Chrome- oder Firefox-Browser zu testen.

John Siu

"Am Ende war es so, dass OpenSSL es nicht im Store hatte ..." - OpenSSL hat kein Store. Sie müssen ihm ausdrücklich mitteilen, was er als Vertrauensanker verwenden soll. OpenSSL ist nicht mit Browsern vergleichbar, die fast allem vertrauen, was auf sie geworfen wird.

Jww

Vielen Dank für Ihre sofortigen Antworten und Kommentare Jungs. Ich werde es mir morgen genauer ansehen. Ich verstehe. Aber: Wenn nur das Stammzertifikat openssl verify AddTrustExternalRootCA.crt(das ist der Schuldige am Ende der Kette) bearbeitet wird, wird "OK" übergeben, dh openssl kennt die in / etc / ssl / certs verknüpften Zertifikate sehr gut.

Reinhard Seifert

... und ja, wenn Sie das Zwischenzertifikat und das Zertifikat der Stammzertifizierungsstelle in CAbundle.crt verketten und es versuchen, besteht openssl verify -CAfile CAbundle.crt myserver_com.crtes den Test "OK".

Reinhard Seifert

@jww OpenSSL - Bibliothek hat einen Standardspeicher Standort , sondern verwendet sie nur , wenn die Anwendung Anrufe SSL_CTX_set_default_verify_paths()oder einige verwandte X509_STORE Routinen. Die OpenSSL- Befehlszeile soll den Standardspeicher verwenden, dies schlägt jedoch derzeit für einige Funktionen fehl, auch s_clientaufgrund eines Fehlers. Siehe meine Antwort. OTOH verify tut es verwenden, die hier zur Verwirrung wahrscheinlich hinzugefügt.

Dave_thompson_085

Das comodo-Stammzertifikat ist nicht mehr vertrauenswürdig. Wenn Sie nicht wissen, warum, suchen Sie bei Google nach "comodo gestohlenes Zertifikat".

Während ein comodo-Zertifikat billig sein mag, ist sein Wert viel geringer als sein Preis: Es ist praktisch wertlos, die Vertrauenskette ist unterbrochen.

Eugen Rieck
quelle

Das ist vier Jahre her und die Zertifikate wurden widerrufen und ersetzt. Darüber hinaus stammt die Stammzertifizierungsstelle nicht von COMODO, sondern von AddTrust. Das Zertifikat der Stammzertifizierungsstelle wird bei der openssl verify AddTrustExternalCARoot.crtdirekten Verwendung als OK bestätigt , jedoch nicht als letztes Zertifikat in einer Kette akzeptiert.

Reinhard Seifert