PEM vs. DER: dasselbe Zertifikat als Text oder binär

Bei PEM vs. DER wählst du nicht zwischen unterschiedlichen Daten: Ein Zertifikat, ein Schlüssel, ein CSR oder eine CRL ist immer als DER-kodiertes ASN.1 definiert, und PEM ist eine Textverpackung um genau diese Bytes. Die Frage ist, welche Darstellung ein Tool, ein Protokoll oder eine Plattform erwartet und wie du beide erkennst und konvertierst.

Auf einen Blick

Was die beiden Formate sind

DER ist die kanonische binäre Kodierung von ASN.1-Daten: Jeder Wert besteht aus einem Tag, einer Länge und dem Inhalt, und für jeden Wert gibt es genau eine gültige Kodierung. Diese Eindeutigkeit ist der Grund, warum Signaturen funktionieren: Die Signatur eines Zertifikats deckt die DER-Bytes seines tbsCertificate ab, und Verifizierer kodieren nichts neu.

PEM (benannt nach dem Standard Privacy-Enhanced Mail von 1993 und für PKIX-Objekte in RFC 7468 spezifiziert) verpackt diese Bytes in Standard-base64, üblicherweise mit 64 Zeichen pro Zeile, zwischen einer Zeile BEGIN und einer Zeile END, die die Struktur benennen: CERTIFICATE, X509 CRL, CERTIFICATE REQUEST, PUBLIC KEY, PRIVATE KEY, ENCRYPTED PRIVATE KEY sowie die älteren OpenSSL-Formen RSA PRIVATE KEY und EC PRIVATE KEY. Text vor, zwischen oder nach den Blöcken wird ignoriert; darauf beruhen Bundles mit Kommentaren und die Ausgabe von openssl x509 -text.

Konvertieren und prüfen

Das folgende Skript, ausgeführt mit OpenSSL 3.6.5, erzeugt ein Wegwerf-Zertifikat und zeigt, dass beide Kodierungen dasselbe Objekt enthalten.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
openssl req -new -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes -keyout key.pem \
  -subj "/CN=example.com" -days 30 -out cert.pem 2>/dev/null
openssl x509 -in cert.pem -outform DER -out cert.der
printf 'cert.pem %s bytes, cert.der %s bytes\n' "$(wc -c < cert.pem | tr -d ' ')" "$(wc -c < cert.der | tr -d ' ')"
head -1 cert.pem
openssl x509 -in cert.der -inform DER -noout -fingerprint -sha256 | cut -c1-40
openssl x509 -in cert.pem -noout -fingerprint -sha256 | cut -c1-40
cd / && rm -rf "$dir"

cert.pem 583 bytes, cert.der 389 bytes
-----BEGIN CERTIFICATE-----
sha256 Fingerprint=FE:8B:DC:19:30:EE:A8:
sha256 Fingerprint=FE:8B:DC:19:30:EE:A8:

Dasselbe Muster gilt für Schlüssel (openssl pkey -in key.pem -outform DER), CSRs (openssl req -outform DER) und CRLs (openssl crl -outform DER). So erkennst du das Format einer unbekannten Datei: Beginnt sie mit -----BEGIN, ist es PEM; zeigt xxd file | head -1 nahe am Anfang 3082, ist es fast sicher DER.

Typische Fehler

• no start line / Expecting: TRUSTED CERTIFICATE von OpenSSL: Das Tool hat PEM erwartet und DER bekommen oder einen PEM-Block mit einem anderen Label. Ergänze -inform DER oder prüfe das Label.
• header too long / wrong tag: Das Tool hat DER erwartet und PEM-Text oder eine abgeschnittene Datei bekommen.
• Windows-Zeilenenden oder verirrte Leerzeichen in einem PEM-Block, der in ein Webformular oder in YAML eingefügt wurde; strikte Parser lehnen sie ab. Kodiere den Block neu, statt ihn von Hand zu bearbeiten.
• Ein PEM-Bundle, wo ein einzelnes Zertifikat erwartet wurde: Viele Tools lesen nur den ersten Block, deshalb kommt es auf die Reihenfolge an (bei Servern das Leaf-Zertifikat zuerst).
• Base64url statt base64: PEM verwendet das Standardalphabet mit +, / und Padding; JOSE und WebAuthn verwenden base64url. Ein Zertifikat, das aus dem Parameter x5c eines JWK kopiert wurde, ist DER in Standard-base64, und mit PEM-Zeilen umschlossen wird daraus eine gültige PEM-Datei.

Der ASN.1-Explorer akzeptiert beide Kodierungen und zeigt die Struktur, und der PEM-Bundle-Splitter zerlegt Dateien mit mehreren Zertifikaten.

Bundles und Ketten

Weil DER genau ein Objekt enthält, nutzt alles, was mehrere Objekte in einer Datei braucht, aneinandergehängte PEM-Blöcke oder ein Containerformat. Die fullchain.pem eines Servers ist das Leaf-Zertifikat, gefolgt von den Zwischenzertifikaten; ein CA-Bundle wie /etc/ssl/certs/ca-certificates.crt besteht aus Hunderten von Root-Zertifikaten in einer einzigen PEM-Datei. Die DER-basierten Alternativen sind Zertifikatsbundles nach PKCS #7 (.p7b, eine CMS-Struktur SignedData ohne Inhalt, nur mit Zertifikaten, unter Windows verbreitet) und PKCS #12 (.pfx), wenn ein privater Schlüssel mit der Kette mitreist. Ein .p7b konvertierst du mit openssl pkcs7 -print_certs -in bundle.p7b in PEM; der Befehl schreibt jedes Zertifikat als eigenen PEM-Block.

Reihenfolge und Vollständigkeit zählen mehr als die Kodierung: Ein Server muss zuerst sein Leaf-Zertifikat senden und danach jedes Zwischenzertifikat, das nötig ist, um ein Root-Zertifikat zu erreichen, dem die Clients vertrauen. Fehlt ein Zwischenzertifikat, scheitern Clients, die es nicht selbst nachladen, unabhängig vom Dateiformat.

Wann welches Format passt

• Webserver, Reverse Proxys, ACME-Clients: PEM (fullchain.pem, privkey.pem).
• Java (keytool -importcert, CertificateFactory): beides, aber DER ist die kanonische Eingabe; Keystores verwenden PKCS #12 für Schlüssel plus Kette.
• Zertifikatsimport unter Windows: eine .cer in DER oder eine PEM-kodierte .cer; Schlüssel plus Zertifikat kommen in eine .pfx.
• Einbetten in Quellcode, Umgebungsvariablen, Kubernetes-Secrets: PEM-Text (oder DER in base64, wenn ein Feld es verlangt).
• Netzwerkprotokolle und binäre Container: immer DER; TLS, CMS, OCSP und X.509-Erweiterungen transportieren nie PEM.
• Archivierung und Audit: DER für bytegenaue Speicherung; PEM, wenn Menschen die Dateien einsehen müssen.

Hinweise zur Migration

Im kryptografischen Sinn gibt es nichts zu migrieren; ein Wechsel der Kodierung ist ein Detail der Bereitstellung.

1. Vereinheitliche die Dateinamen: .pem für PEM, .der für DER, und vermeide in deinen eigenen Tools die mehrdeutigen Endungen .crt und .cer.
2. Konvertiere bei der Bereitstellung und halte eine einzige maßgebliche Quelle (meist PEM) in deinem Repository oder Secret Store.
3. Prüfe die Fingerabdrücke nach der Konvertierung mit openssl x509 -noout -fingerprint -sha256; sie müssen übereinstimmen.
4. Lass private Schlüssel verschlüsselt: openssl pkey -outform DER schreibt einen unverschlüsselten Schlüssel, sofern du kein Verschlüsselungsverfahren angibst, und Tools geben bei DER-Schlüsseln oft weniger Warnungen aus.
5. Dokumentiere die erwarteten Formate in der Konfiguration (ssl_certificate erwartet PEM; Java-Truststores erwarten DER oder PKCS #12), denn die meisten Formatfehler entstehen durch Raten.

Quellen

• RFC 7468, Textkodierungen von PKIX-, PKCS- und CMS-Strukturen
• ITU-T X.690, BER, CER und DER
• RFC 5280 §4.1, Aufbau des Zertifikats
• RFC 4648 §4 und §5, base64 und base64url
• OpenSSL, Handbuchseite zu openssl-x509