PKCS12, PEM oder DER: Was ein VPN-Client wirklich braucht

Zwei Behauptungen kursieren in Zertifikatsdiskussionen. Die erste besagt, eine .p12 sei die starke Option und eine .pem die lockere; die zweite, eine Textdatei müsse sicher zu versenden sein, weil man sie lesen kann. Keine von beiden übersteht eine Minute Prüfung.

PKCS12, PEM und DER beschreiben, wie Zertifikatsobjekte gepackt und kodiert werden. Sie entscheiden nicht darüber, wer die Gegenstelle ist, ob der Aussteller vertrauenswürdig ist oder ob die Datei ein Passwort braucht.

Was der Client akzeptiert, ist eine Kompatibilitätsfrage. Was in der Datei steckt, ist eine Identitätsfrage. Hält man beides auseinander, verlieren die meisten Importfehler ihr Geheimnis.

Drei Container, ein Objektmodell

Beginnen Sie mit dem, was Sie tatsächlich haben. Ein Zertifikat ist eine signierte Aussage über einen öffentlichen Schlüssel. Der private Schlüssel ist separates Material, das belegt, dass Sie diesen Schlüssel kontrollieren. Eine Kette ist die Menge der Aussteller, die Ihr Zertifikat mit einer Wurzel verbindet, der der Client vertraut. Alle drei existieren unabhängig von der Verpackung.

Eine PKCS12-Datei, meist .p12 oder .pfx, ist ein in RFC 7292 definierter Container, der einen privaten Schlüssel, ein oder mehrere Zertifikate und die Kette in einem einzigen passwortgeschützten Block tragen kann, mit einem Alias, der die Identität benennt. Eine PEM-Datei ist eine Textrahmung nach RFC 7468: ein Base64-Körper zwischen BEGIN- und END-Zeilen, und eine Datei kann mehrere Blöcke hintereinander enthalten. DER ist die binäre Kodierung derselben ASN.1-Strukturen, und der PEM-Körper ist buchstäblich DER mit Base64 darum.

Der letzte Satz ist der, den man behalten sollte. Die Umwandlung von PEM nach DER schreibt die Rahmung um, nicht den Inhalt, und die Rückwandlung liefert die ursprünglichen Bytes.

Kodierung ist keine Verschlüsselung

Base64 ist ein Transportalphabet. Es verbirgt nichts, und jeder kann einen PEM-Block in einer Shell dekodieren. Eine DER-Datei ist binär und ebenso öffentlich. Keine der beiden Eigenschaften ist Schutz, und keine von beiden impliziert, dass ein Passwort existiert.

Echter Schutz liegt im Schlüsselmaterial. Ein PKCS12-Bündel kann seinen Inhalt unter einem passwortabgeleiteten Schlüssel verschlüsseln. Ein privater PEM-Schlüssel lässt sich mit einem alten Kopfblock verschlüsseln oder in PKCS#8 EncryptedPrivateKeyInfo aufbewahren. Ein Zertifikat allein enthält nichts Geheimes, weshalb ein Export, der nur ein Zertifikat erzeugte, den Client nicht authentifizieren lässt, egal in welches Format man ihn packt.

Die Dateiendung ist ein Hinweis, kein Vertrag. Dateien mit .cer und .crt erscheinen in beiden Kodierungen, und Appliances exportieren DER-Zertifikate oft genug unter .pem-Namen, dass Raten anhand des Suffixes einen Nachmittag kostet. Lesen Sie stattdessen die ersten Bytes: Eine PEM-Datei beginnt mit einer BEGIN-Zeile, während DER mit 0x30 beginnt, weil die äußere Struktur eine SEQUENCE ist.

Warum der Import tatsächlich scheitert

Client-Fehlermeldungen pressen mehrere verschiedene Probleme in einen Satz über ein ungültiges Zertifikat, also trennen Sie sie nach Ursache. Am häufigsten ist eine Kodierungsabweichung: Ein Client, der PEM parst, liefert bei einer DER-Datei einen Parsefehler, und die Lösung ist eine Umwandlung statt eines neuen Zertifikats. Die zweite ist ein fehlender Schlüssel, wobei das Zertifikat in Ordnung ist und die Identität nicht bewiesen werden kann. Die dritte ist die Kette, wobei ein Bündel ohne Zwischenzertifikat im Importdialog korrekt aussieht und im Handshake scheitert.

Verschlüsselungsparameter verursachen einen vierten, und er sieht genau wie ein falsches Passwort aus. Ältere Appliances exportierten PKCS12-Dateien mit RC2-40 und 3DES, die OpenSSL 3 ablehnt, sofern der Legacy-Provider nicht geladen ist. Der erneute Export aus der Appliance mit AES-256-CBC und PBKDF2 ist die dauerhafte Lösung. Alte Chiffren dauerhaft auf einem Client-Rechner freizuschalten, um eine Datei zu bedienen, ist ein schlechtes Geschäft.

Ein fünfter Punkt ist Mehrdeutigkeit. Ein Container mit zwei Schlüsseln und zwei Zertifikaten oder eine PEM-Datei mit drei CERTIFICATE-Blöcken zwingt den Client zu wählen, und seine Wahl ist oft schlicht der erste Eintrag. Wenn ein Tunnel mit der falschen Identität hochkommt, ist das meist der Grund.

Vor dem Konvertieren prüfen

Lesen Sie die Struktur, ohne Geheimnisse auszugeben. openssl pkcs12 -in bundle.p12 -info -noout meldet die Verschlüsselungsalgorithmen und die Aliasse und unterdrückt dabei Schlüssel- und Zertifikatsausgabe, und das Handbuch zu openssl-pkcs12 dokumentiert die Optionen. -noout wegzulassen und -nodes zu ergänzen, dient dem Erzeugen von Dateien, die Sie aufbewahren wollen, nicht einem kurzen Blick, denn es schreibt den privaten Schlüssel im Klartext.

Für ein Zertifikat beantwortet openssl x509 -in cert.pem -noout -subject -issuer -dates, was ein Importdialog nicht beantwortet, und ergänzt um -ext subjectAltName zeigt es die Namen, für die das Zertifikat tatsächlich gültig ist. Ist die Datei DER, ergänzen Sie -inform DER; dieses eine Flag löst die meisten Unable-to-load-Fehler.

Einen Schlüssel einem Zertifikat zuzuordnen ist mechanisch und lohnt sich vor jedem Import:

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in key.pem -pubout | openssl sha256

Gleiche Digests bedeuten, dass das Paar zusammengehört. Unterschiedliche Digests bedeuten, dass Sie den falschen Schlüssel haben, und keine Formatumwandlung ändert das.

Was das Format nie ändert

Vertrauensentscheidungen finden oberhalb des Containers statt. Der Client geht die Kette zu einer Wurzel in seinem Speicher durch, prüft das Gültigkeitsfenster, prüft die erweiterte Schlüsselverwendung für die Client-Authentifizierung und prüft auf der Serverseite, ob der gewählte Name im Zertifikat erscheint. Keiner dieser Schritte liest eine Dateiendung.

Deshalb ist das Umbenennen einer Datei, bis ein Fehler verschwindet, ein so zuverlässiger Weg, Zeit zu verlieren. Der Import gelingt, die Identität ist weiterhin falsch, und der Fehler taucht im Handshake wieder auf, wo die Meldung weniger hilfreich ist. Deshalb auch importiert ein vor zwei Jahren exportiertes Bündel sauber und wird trotzdem abgelehnt: Das Ablaufdatum reiste im Zertifikat, nicht im Dateinamen.

Eine Reihenfolge, die Nacharbeit vermeidet

Fragen Sie in der Dokumentation des Clients, welche Kodierungen er akzeptiert und welchen Container er für eine Client-Identität erwartet, und schauen Sie dann, was Ihnen übergeben wurde. Will der Client eine einzelne importierbare Identität und Sie haben lose PEM-Dateien, bauen Sie das Bündel einmal mit einem Passwort, das Sie kontrollieren, und behalten Sie die Quellen. Will er PEM, extrahieren Sie Schlüssel und Kette und entfernen die Zwischendateien danach über den Prozess zur Credential-Behandlung, den Ihr Team ohnehin nutzt.

Prüfen Sie nach dem Import die Identität statt den Dialog: Subject, Aussteller, Ablauf und den Namen, den der Client präsentieren wird. Ein freundlicher Name in einer Liste ist ein Etikett, keine verifizierte Identität. Scheitert der Tunnel danach, debuggen Sie Authentifizierung oder Routing statt Verpackung, was ein viel kürzeres Gespräch ist.