it-swarm.com.de

Zertifikate können nicht geladen werden, wenn versucht wird, eine pfx-Datei zu generieren

Ich habe die letzten drei Stunden damit zu kämpfen, eine .pfx-Datei mit OpenSSL zu erstellen. Ich habe dieses document verfolgt und die Anweisungen unter dem Get a certificate using OpenSSL-Header befolgt.

Ich bin am Schritt hier: openssl pkcs12 -export -out myserver.pfx -inkey myserver.key -in myserver.crt und verwende die OpenSSL.exe-Konsole.

Ich erhalte die Fehlermeldung: unable to load certificates

Ich habe auch folgendes ausprobiert: x509 -text -in myserver.key und die Fehlermeldung erhalten: 0906D06D06C:PEM_read_bio:no start line:.\crypto\pem\pem_lib.b.c:703:Expecting: TRUSTED CERTIFICATE Ich erhalte diese Fehlermeldung auch, wenn ich myserver.crt versuche.

Ich scheine es zu verstehen, egal was ich tue.

Kann jemand bitte helfen?

14
davy

Ich erhalte die Fehlermeldung: Zertifikate können nicht geladen werden

myserver.crt muss im PEM-Format vorliegen. Hat es ----- BEGIN CERTIFICATE ----- und ----- END CERTIFICATE -----?


myserver.crt sollte eigentlich eine Kette von Zertifikaten sein (und nicht nur ein Serverzertifikat). Die Kette sollte alle Zwischenzertifikate enthalten, die der Kunde zur Verifizierung der Kette benötigt.

Sie senden alle Zwischenzertifikate, um das Problem "welches Verzeichnis" zu lösen. Das "which directory" ist ein bekanntes Problem in PKI. Im Wesentlichen weiß der Client nicht, wo er das fehlende Zwischenzertifikat abholen soll. Um das Problem zu vermeiden, senden Sie alle Zwischenprodukte.

Ich benutze oft Startcom , weil sie kostenlose Zertifikate der Klasse 1 anbieten. Wenn ich das signierte Serverzertifikat von ihnen erhalte (z. B. www-example-com.crt), füge ich ihr Class 1 Server Intermediate hinzu. Ihre Class 1 Server Intermediate bekomme ich von ihrer Website unter Startcom CA-Zertifikate . Die, die ich verwende, ist sub.class1.server.ca.pem.

Mit dem www-example-com.crt sieht mein Serverzertifikat folgendermaßen aus:

$ cat www-example-com.crt

-----BEGIN CERTIFICATE-----
< My Server Certificate >
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
< Startcom Intermediate >
-----END CERTIFICATE-----

Der Vollständigkeit halber hat der private Schlüssel (z. B. www-example-com.key) auch das PEM-Format. Es verwendet -----BEGIN RSA PRIVATE KEY----- und -----END RSA PRIVATE KEY-----.

Mit meinem Serverzertifikat im PEM-Format (und den erforderlichen Zwischenprodukten) und dem privaten Schlüssel erteile ich dann Folgendes (der wie derselbe Befehl aussieht, den Sie verwenden):

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

Wenn sich Clients verbinden, verwenden sie die Startcom-Zertifizierungsstelle. So testen Sie die Verbindung (nach dem Laden in IIS):

openssl s_client -connect www.example.com:443 -CAfile startcom-ca.pem

Der Befehl sollte mit "Verify OK" abgeschlossen werden:

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)

Ich habe es auch ausprobiert: x509 -text -in myserver.key und habe den Fehler erhalten ...

x509 ist für Zertifikate. Wenn Sie einen Schlüssel sichern möchten, verwenden Sie den Befehl pkey von OpenSSL. Siehe die Dokumentation zu OpenSSLs Befehl pkey(1) .

11
jww

Ich habe dieses Dokument verfolgt ...

Übrigens aus den Dokumenten, die Sie zitiert :

Basiszertifikate sind Zertifikate, bei denen der Common Name (CN) der Zertifikat wird auf die bestimmte Domäne oder Unterdomäne festgelegt, die diese Clients verwenden wird verwendet, um die Website zu besuchen. Zum Beispiel www.contoso.com. Diese Zertifikate sichern nur den einzelnen, vom CN angegebenen Domänennamen.

Es gibt zwei Standards für diese Art von Dingen. Zum einen die RFCs und zum anderen die Anforderungen des CA-Browsers (CA/B). Die RFCs sind allgemein, weil sie für so viele verschiedene Protokolle und Dienste gelten und ein breites Netz bilden, um viele bestehende Praktiken abzudecken. Aufgrund dieser Dinge sind die RFCs etwas schlampig - sie erlauben eine Menge Dinge, die kontraproduktiv sind. Sehen Sie sich zum Beispiel das zulässige keyUsage von RFC 5280 in Abschnitt 4.2.1.3 an.

Die CAs und Browser kamen zusammen und bildeten die CA/B-Foren. Zusammen veröffentlichen sie Standards, denen sie folgen. Die CA/B-Praktiken sind etwas disziplinierter (Sie können sich das als eine Untermenge der RFCs vorstellen). Wenn Sie die Baseline-Anforderungen betrachten, werden Sie feststellen, dass CN veraltet ist und nicht verwendet werden sollte. Wenn ein CN verwendet wird, muss derselbe Name in einem SAN vorhanden sein:

9.2.2 Feld "Antragstellername"

Zertifikatsfeld: Betreff: allgemeiner Name (OID 2.5.4.3)

Erforderlich/Optional: Veraltet (Nicht empfohlen, aber nicht verboten)

Inhalt: Falls vorhanden, MUSS dieses Feld eine einzige IP-Adresse oder .__ enthalten. Vollständig qualifizierter Domänenname, der einer der Werte in .__ ist. Erweiterung subjectAltName des Zertifikats (siehe Abschnitt 9.2.1).

Unterm Strich: Sie sollten es vermeiden, einen Hostnamen oder einen Domänennamen in CN einzugeben. Sie vermeiden dies, weil die CA dies zugestimmt hat und die Browser dies erwarten. (Und wenn Sie nicht über einen Browser auf die Website zugreifen, tun Sie, was Sie möchten.).

Aus humoristischer Sicht legen beide Standards die Verwendung eines vollständig qualifizierten Domänennamens fest. FQDNs sind Namen, die mit einem Punkt "." Enden. Ich muss noch ein Zertifikat sehen, das für beide Standards gut formuliert ist.

1
jww