web-dev-qa-db-de.com

Hinzufügen von Zwischenzertifikaten zu einer pkcs12-Datei

Ich habe ein Zertifikat mit der folgenden Zertifizierungskette: Entrust-> Meine CA-> Meine ausstellende CA-> Mein JBoss-Zertifikat. Wenn ich nun mein Zertifikat in meiner JBoss-Instanz installiere, wird jede Seite, auf die ich in dieser Instanz laufe, nicht als vertrauenswürdig eingestuft, da meine ausstellende Zertifizierungsstelle von meinem Browser nicht erkannt wird. Ich weiß, dass mein Computer über den öffentlichen Schlüssel für die Entrust-Signaturbehörde verfügt. Wie kann ich mein Zertifikat installieren, damit jeder Browser die gesamte Zertifikatskette sehen kann? 

Ich habe eine einzige .pem-Datei aller Zertifikate erstellt, die meiner Meinung nach funktionieren würden. Es hat nicht. Kann jemand erklären, was ich falsch mache oder ob dies möglich ist? 

16
blackirishman

Hinzufügen eines Zwischenzertifikats zu einer pkcs12-Datei ...

So mache ich das auf meinen Web- und Mail-Servern.

Erstens ist www-example-com.crt das von Startcom signierte Webserverzertifikat. Startcom bietet kostenlose Zertifikate der Klasse 1 an, denen meine meisten Browser und mobilen Geräte vertraut sind. Ich verwende sie also. Das Zertifikat hat das PEM-Format (----- BEGIN CERT ----- und ----- END CERT -----).

Zweitens öffne ich www-example-com.crt und füge Startcoms Klasse 1 Intermediate an. Ich bekomme das Intermediate von Startcoms Index von/certs . Jetzt enthält mein www-example-com.crt zwei PEM-codierte codierte Zertifikate.

Drittens führe ich die folgenden Schritte aus, um eine PKCS12/PFX-Datei für die Verwendung in IIS zu erstellen.

openssl pkcs12 -export -in www-example-com.crt -inkey www.example.key -out www-example-com.p12

In Ihrem Fall enthält Ihr www-example-com.crt mindestens drei PEM-codierte Zertifikate:

----- BEGIN CERT -----
< My JBoss Certificate >
----- END CERT -----

----- BEGIN CERT -----
< My Issuing CA >
----- END CERT -----

----- BEGIN CERT -----
< My CA >
----- END CERT -----

Das dritte Zertifikat in der Kette - My CA - ist optional. Sie benötigen es nicht, wenn Ihre Kunden My CA als Vertrauensanker verwenden. Wenn Ihre Kunden Entrust als Vertrauensanker verwenden, müssen Sie ihn einschließen.

Wenn Sie cat Ihren www-example-com.crt haben und NICHT über mehrere Zertifikate verfügen, fahren Sie nicht fort. Führen Sie openssl pkcs12 erst aus, wenn Ihr Serverzertifikat über alle erforderlichen Zwischenzertifikate verfügt, um die Kette zu überprüfen.

Schließen Sie das Entrust CA-Zertifikat nicht ein.


Ich bezweifle, Entrust-Schilder direkt mit ihrer CA zu kontaktieren. Sie verwenden wahrscheinlich auch ein Zwischenprodukt. So sollte Ihre Zertifizierungskette wahrscheinlich so aussehen:

----- BEGIN CERT -----
< My JBoss Certificate >
----- END CERT -----

----- BEGIN CERT -----
< My Issuing CA >
----- END CERT -----

----- BEGIN CERT -----
< My CA >
----- END CERT -----

----- BEGIN CERT -----
< Entrust Intermediate >
----- END CERT -----

Entrusts stellt ihre CA- und Zwischenzertifikate unter Entrust Root-Zertifikate bereit. Ich kann Ihnen nicht sagen, welche Sie benötigen, da Sie keine URL angeben oder uns die Kette zeigen, die Sie haben. Aber ich vermute, es wird eine oder mehrere der folgenden sein:

  • Entrust L1E-Kettenzertifikat
  • L1-Kettenzertifikat entladen
  • Entrust L1E-Kettenzertifikat (SHA2)
  • Entrust L1C-Kettenzertifikat (SHA2)

Sie können Ihre Kette mit dem `s_client von OpenSSL testen. Dieses Mal werden Sie das Zertifikat von Entrust verwenden:

echo -e "GET / HTTP/1.0\r\n" | openssl s_client -connect myserver:8443 \
                                       -CAfile entrust-ca.pem

Sie können entrust-ca.pem von Entrust Root Certificates erhalten. Führen Sie es aus und teilen Sie uns mit, welche Fehler Sie erhalten. Oder besser, posten Sie die URL auf Ihrem Server, damit wir sehen können, was los ist.

21
jww

Ich habe ein Zertifikat mit der folgenden Zertifizierungskette: Entrust-> Meine CA-> Meine ausstellende CA-> Mein JBoss-Zertifikat ....

Ich denke, du hast hier zwei Probleme. Erstens ist die gegengezeichnete CA und zweitens eine unvollständige Client-Kette.

Zuerst das einfache Problem. Der Server muss das Zertifikat der Endeinheit (Server) und alle Zwischenzertifikate senden, um die Kette aufzubauen. Der Server sendet die Zwischenzertifikate, um das Problem "welches Verzeichnis" zu vermeiden. Das "which directory" ist ein bekanntes Problem in PKI. Im Wesentlichen weiß der Client nicht, wo er das fehlende Zwischenzertifikat abholen soll.

Ihre erste Lösung besteht darin, dass der Server eine Kette sendet mit:

  • Ihr Zwischenzertifikat ("Meine ausstellende CA")
  • Ihr Serverzertifikat ("Mein JBoss-Zertifikat")

Zweitens haben Sie das Problem eines nicht vertrauenswürdigen Emittenten. Der Client muss Ihrer internen ausstellenden Zertifizierungsstelle vertrauen.

Ihre zweite Lösung besteht also darin, sicherzustellen, dass Ihr Client Ihrer internen Zertifizierungsstelle ("Meine Zertifizierungsstelle") vertraut. In diesem Fall muss der Client nicht einmal Entrust verwenden, da der Vertrauenspunkt in Ihrer internen Zertifizierungsstelle verankert ist.

Möglicherweise kann der Server eine Kette mit "Meine Zertifizierungsstelle", "Meine ausstellende Zertifizierungsstelle" und "Mein JBoss-Zertifikat" senden. In diesem Fall muss der Client 'Entrust' vertrauen.

Wenn der Client "Entrust" oder "Meine Zertifizierungsstelle" nicht vertraut, werden Überprüfungsfehler angezeigt.


Ich habe eine einzige .pem-Datei aller Zertifikate erstellt, die meiner Meinung nach funktionieren würden. Es hat nicht. Kann jemand erklären, was ich falsch mache oder ob dies möglich ist? 

In diesem Fall müssten wir die Zertifikate sehen, um zu sehen, was los ist. Können Sie eine URL posten, die das Zertifikat bereitstellt und die Kette verwendet; und veröffentlichen Sie Ihr internes CA-Zertifikat ("Meine CA") online?

Hier ist eine schnelle und schmutzige Möglichkeit, eine Verbindung mit s_client von OpenSSL zu testen:

echo -e "GET / HTTP/1.0\r\n" | openssl s_client -connect myserver:8443 \
                                       -CAfile my-issuing-ca.pem

OpenSSL vertraut standardmäßig nicht (im Gegensatz zu Browsern). Daher müssen Sie Ihren Vertrauensanker mit -CAfile angeben.

Dieser Befehl sollte mit einem ähnlichen Ergebnis wie dem folgenden enden.

SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 37E5AF0EE1745AB2...
    Session-ID-ctx:
    Master-Key: 7B9F8A79D3CC3A41...
    Key-Arg   : None
    Start Time: 1243051912
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

Wenn der OpenSSL-Befehl zu OK führt, liegt das Problem beim Browser und beim Vertrauenspunkt.

0
jww