ITEG pflegt derzeit 3 verschiedene Hierarchien von SSL-Zertifikaten (1 intern, 2 Projekt-spezifisch). Um die damit immer häufiger nötige manuelle Installation von CAs (den Zertifikaten der Zertifizierungs-Stellen) und Client-Zertifikaten zu vereinfachen haben wir die folgenden Kurz-Anleitungen geschrieben.

Vorbemerkungen

Für Ungeduldige: Detaillierte Anleitungen je Betriebssystem bzw. Browser finden sich weiter unten.

Genereller Tip: Importier-Reihenfolge

Weg 1: Einzeln

Im allgemeinen funktioniert Weg 1 gut, und alle unseren Anleitungen beschreiten diesen Weg:

Zuerst die RootCA (Beim Herunterladen eher .crt als .pem nennen)
Dann eine SubCA (analog RootCA, bei mehreren Zwischen-Zertifikats-Stufen "von oben nach unten" abarbeiten)
Dann in einem Schritt Zertifikat und Key als Paket (bzw. falls der CSR lokal erstellt wurde nur das Zertifikat)

Weg 2: PKCS12-Paket in einem Rutsch

Mit Ausnahme von Windows (das CA-Zertifikate gerne in die falsche Kategorie legt) funktioniert auch Weg 2 meist gut, ggfs. sogar besser:

Ganzes Zertifikats-Bundle (alle CAs, Zertifikat, und ggfs. private Key) auf einmal importieren, im PKCS12-Format als .p12-Datei importieren

Kurzinfo Datei-Formate für X.509-Zertifikatei

Eine Ausführlichere Übersicht bietet die Wikipedia-Seite zu X.509 (Überschrift "Dateinamenserweiterungen für Zertifikate").

Format	übliche Dateiendung(en)	Kurzbeschreibung
PEM	.crt, .cert, .cer (nur Zertifikate oder -Ketten) .key (nur Keys) .csr (nur CSRs) .pem (Alles, einzeln oder als Paket)	PEM ist das Text-basiertes de-fakto-Standard-Format bei OpenSSL, Apache, u.v.a Open-Source-Projekten. Es ist auch das üblichste Format für CSRs (Certificate Signing Requests). Meist ist nur 1 Komponente in einer Datei. Viele Daemons erlauben oder benötigen aber mehr oder alles (Root-CA und Sub-CAs, Zertifikat und Key, oder alles) in einer Datei.
PKCS#7	.p7b, .p7c	Binäres Bundle-Format, gerne für CA-Chains (CA-Ketten, also Root- und Zwischen-Zeritifkate der Zertifizierungsstellen) verwendet.
PKCS#12	.p12, .pfx	Binäres Bundle-Format, gerne für Zertifikat samt Key (und evtl. CA-Chain) verwendet. Von vielen GUIs, Windows, und Java-Daemons oft bevorzugt.

Anleitungen je Betriebssystem bzw. Browser

Die folgende Liste ist im Sinne der Neutralität alphabtisch sortiert ;-)

Android
Chrome standalone (z.B. unter Linux)
Firefox (Firefox ignoriert den Schlüsselbund des Betriebssystems bzw. Linux-Desktops, daher muss man hier alle Schritte direkt im Firefox erledigen)
Linux: Nur die CA-Installation unter Linux ist halbwegs vereinheitlicht. Für Client-Zertifikate bzw. Client-Applikationen gibt es aufgrund des Desktop-Wildwuchses keinen gemeinsamen Zertifikatsstore, daher für jeden Browser extra, z.B. Chrome standalone, Firefox.
MacOS (gemeinsamer Schlüsselbund, ausgenommen Firefox)
Windows (am Beispiel Windows 7)

Umwandlung von PKCS#12 Dateien mit neuen Passwörtern und Kompatibilität mit MacOS oder anderen Altsystemen

Es ist möglich, dass neuere PKCS#12 Dateien trotz des richtigen Passworts mit einem "MAC Error" oder "MAC Algorithm not supported" Fehler abgelehnt werden.

Dies gilt z.B. für den Import in MacOS. Manche Systeme verlangen auch komplexere Passwörter.

In all diesen Fällen muss eine PKCS#12 Datei umgeschrieben werden, was mit dem Java keytool funktioniert:

keytool -importkeystore -srcstorepass "<oldpw>" -srckeystore original.p12 -srcstoretype PKCS12 -destkeystore compatible.p12 -deststoretype PKCS12 -deststorepass "<newpw>" -J-Dkeystore.pkcs12.legacy

Hier wir die Datei original.p12 mit dem Passwort <oldpw> auf compatible.p12 mit Passwort <newpw> umgeschrieben.