Wie kann das Format digitaler Zertifikate nahtlos geändert werden?

Wichtige Erkenntnisse

• PEM, DER, PFX/PKCS#12 und P7B/PKCS#7 sind die vier Zertifikatsformate, zwischen denen Sie am häufigsten konvertieren werden, und jedes ist einer bestimmten Serverplattform zugeordnet.
• OpenSSL bewältigt alle gängigen Konvertierungspfade mit einem einzigen Befehl; das Umbenennen einer Dateierweiterung funktioniert nur innerhalb der PEM-Familie (.pem, .crt, .cer, .key).
• Sichern Sie die Originaldateien und notieren Sie eine Prüfsumme, bevor Sie Dateien konvertieren, die einen privaten Schlüssel enthalten.
• Vor der Bereitstellung sollte jedes konvertierte Zertifikat mit OpenSSL validiert und der Rollback-Pfad bereitgehalten werden.
• Die manuelle Konvertierung ist bei mehr als einer Handvoll Zertifikaten nicht praktikabel; CertSecure Manager automatisiert die Formatkonvertierung und den Export als Teil des Zertifikatslebenszyklus.

Veröffentlicht: Juli 2021. Aktualisiert: August 2026. Geprüft vom PKI-Operations-Team von Encryption Consulting.

Welche digitalen Zertifikatsformate gibt es und was bedeutet jedes einzelne?

Ein digitales Zertifikat basiert unabhängig von der Speicherart auf derselben X.509-Datenstruktur; das Format ändert lediglich die Art der Datenkodierung auf der Festplatte und die zugehörigen Daten. Jeder PKI-Betreiber in Unternehmen stößt regelmäßig auf vier Formate:

• PEM (Datenschutz-optimierte E-Mail): PEM ist ein Base64-ASCII-kodiertes Textformat, das durch die Zeilen „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE—–“ begrenzt wird. Eine PEM-Datei kann nacheinander ein Zertifikat, einen privaten Schlüssel oder eine vollständige Zertifikatskette enthalten. Gängige Dateiendungen sind .pem, .crt, .cer, .key und .ca-bundle. PEM wird von Apache, Nginx und den meisten OpenSSL-basierten Anwendungen verwendet.
• DER (Distinguished Encoding Rules): Die Binärkodierung derselben X.509-Daten, jedoch ohne BEGIN/END-Headerzeilen. Da es sich um Binärdaten handelt, können DER-Dateien nicht sicher in einem Texteditor bearbeitet oder zusammengeführt werden. Gängige Dateiendungen: .der, .cer. Wird von Java-Keystores und einigen Windows-Binärimportvorgängen verwendet.
• PFX/PKCS#12: Ein passwortgeschütztes Binärarchiv (PFX ist die Windows-Bezeichnung für eine PKCS#12-Datei), das Serverzertifikat, Zwischenzertifikatskette und privaten Schlüssel in einer Datei bündelt. Gängige Dateiendungen: .pfx, .p12. Wird von Windows, IIS und Exchange für den Import und Export verwendet.
• P7B/PKCS#7: Ein Base64-kodiertes Zertifikatskettenformat, begrenzt durch die Zeilen „—–BEGIN PKCS7—–“ und „—–END PKCS7—–“. Es kann keinen privaten Schlüssel speichern, sondern nur Zertifikate und eine Zertifikatssperrliste (CRL). Gängige Dateiendungen: .p7b, .p7c. Wird von Java Tomcat und Windows-Workflows zum Importieren von Zertifikatsketten verwendet.

Kein Format ist sicherer oder korrekter als ein anderes; der kryptografische Inhalt des Zertifikats ist in allen Formaten identisch. Das benötigte Format hängt ausschließlich von den Anforderungen der Zielplattform ab. Daher ist die Formatkonvertierung eine routinemäßige Betriebsaufgabe und keine Sicherheitsentscheidung.

Was benötigen Sie vor der Konvertierung eines Zertifikatsformats?

Bitte überprüfen Sie diese fünf Punkte, bevor Sie einen Konvertierungsbefehl für ein Zertifikat ausführen, das auf einem Produktivsystem aktiv ist.

• OpenSSL wurde installiert und die Version bestätigt. Führen Sie openssl version Zunächst einmal: OpenSSL 3.x hat die ältere PKCS#12-Verschlüsselung (RC2, 3DES) in einen Legacy-Provider ausgelagert, sodass eine vor Jahren exportierte PFX-Datei möglicherweise die Unterstützung von OpenSSL benötigt. -legacy Dem Befehl wurde ein Flag hinzugefügt.
• Zugriff auf den privaten Schlüssel bei der Umstellung auf oder von PFX/PKCS#12 und Bestätigung, wer zur Bearbeitung berechtigt ist.
• Eine verifizierte Sicherungskopie der Originalzertifikats- und Schlüsseldateien, wird vor der Ausführung eines Befehls an einen separaten Ort kopiert, zuzüglich einer aufgezeichneten Prüfsumme (siehe Abschnitt Protokollierung weiter unten).
• das exakte erforderliche Format des Zielsystems, bestätigt anhand der Entscheidungstabelle weiter unten auf dieser Seite und nicht nur angenommen.
• Eine Testumgebung oder ein Wartungsfenster um die konvertierte Datei zu testen, bevor sie das Zertifikat auf einem Produktivsystem ersetzt.

Wie konvertiert man Zertifikatsformate mit OpenSSL?

Jede der folgenden Konvertierungen entspricht einem einzelnen OpenSSL-Befehl. Führen Sie jeden Befehl mit Ihrer Sicherungskopie aus, nicht mit der Datei, die aktuell von einem laufenden Dienst verwendet wird.

Schritt für Schritt: Umwandlung von PEM in DER

1. Kopieren certificate.pem in ein Arbeitsverzeichnis wechseln und überprüfen, ob es als lesbarer Base64-Text geöffnet werden kann.
2. Run: openssl x509 -outform der -in certificate.pem -out certificate.der
3. Schichtannahme certificate.der wurde erstellt und ist binär (es lässt sich nicht problemlos als Text öffnen).

Schritt für Schritt: DER in PEM umwandeln

1. Vergewissern Sie sich vor Ausführung des Befehls, dass die Quelldatei tatsächlich DER-kodierte Binärdatei ist; eine .cer-Erweiterung kann entweder PEM oder DER sein.
2. Run: openssl x509 -inform der -in certificate.der -out certificate.pem
3. Öffne certificate.pem in einem Texteditor überprüfen Sie, ob nun „—–BEGIN CERTIFICATE—–“ angezeigt wird.

Schritt für Schritt: PEM in PFX (PKCS#12) konvertieren

1. Bestätigen Sie, dass Sie das Zertifikat besitzen (certificate.crt), dem dazugehörigen privaten Schlüssel (privateKey.key), und, falls verfügbar, die CA-Kettendatei (CAcert.crt).
2. Run: openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CAcert.crt
3. Geben Sie bei Aufforderung ein sicheres Exportpasswort ein. -certfile CAcert.crt Das Flag ist optional; verwenden Sie es, um die Zwischenkette in die PFX einzubinden, sodass das Zielsystem sie nicht separat benötigt.

Schritt für Schritt: PFX in PEM konvertieren

1. Vergewissern Sie sich, dass Sie die PFX-Datei und das zugehörige Exportpasswort besitzen.
2. Run: openssl pkcs12 -in certificate.pfx -out certificate.pem -nodes
3. OpenSSL fordert das PFX-Passwort an und speichert anschließend Zertifikat, Zertifikatskette und unverschlüsselten privaten Schlüssel in einer einzigen PEM-Datei. Öffnen Sie diese in einem Texteditor und teilen Sie sie in separate Zertifikats- und Schlüsseldateien auf, falls die Zielplattform dies erfordert. Dabei müssen die Blöcke „—–BEGIN—–“/”—–END—–“ erhalten bleiben.
4. Drop -nodes wenn Sie möchten, dass der extrahierte private Schlüssel mit einer Passphrase innerhalb der PEM-Ausgabe verschlüsselt bleibt.

Für das P7B/PKCS#7-Kettenformat: PEM in P7B konvertieren mit openssl crl2pkcs7 -nocrl -certfile certificate.cer -certfile CAcert.cer -out certificate.p7b (der zweite -certfile ist optional und dient dazu, ein zusätzliches Kettenzertifikat zu bündeln), und Zertifikate aus einem P7B zurück in PEM zu extrahieren mit openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cerDa P7B keinen privaten Schlüssel speichern kann, ist die Konvertierung von P7B in PFX ein zweistufiger Prozess: Extrahieren Sie die Zertifikate mit dem oben genannten Befehl und führen Sie anschließend den Befehl aus. openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CAcert.cer unter Verwendung des privaten Schlüssels, den Sie bereits besitzen.

Eine Abkürzung ist sicher: Das Umbenennen einer Datei zwischen .pem, .crt, .cer und .key ändert nichts an der zugrundeliegenden Base64-Kodierung. Innerhalb dieser Dateitypenfamilie funktioniert eine einfache Umbenennung also. Sie funktioniert jedoch nicht familienübergreifend. Das Umbenennen einer PEM-Datei in .der macht sie nicht zu einer binären DER-Datei, und das Umbenennen einer Zertifikatsdatei in .pfx fügt keinen privaten Schlüssel hinzu. Wenn die Kodierung oder der Inhalt der Datei tatsächlich geändert werden muss, führen Sie stattdessen den entsprechenden OpenSSL-Befehl oben aus.

Wie validiert man ein konvertiertes Zertifikat?

Prüfen Sie die Ausgabe, bevor sie in den Produktivbetrieb gelangt. Führen Sie die folgenden Prüfungen an der konvertierten Datei durch:

• Bestätigen Sie die Zertifikatsanalyse und überprüfen Sie die Details: openssl x509 -in certificate.pem -text -noout (benutzen -inform der (für eine DER-Datei). Überprüfen Sie Betreff, Aussteller, Gültigkeitsdaten und alternative Betreffnamen anhand Ihrer Erwartungen.
• Überprüfen Sie die Vertrauenskette: openssl verify -CAfile ca-bundle.pem certificate.pem sollte zurückkehren certificate.pem: OK.
• Prüfen Sie, ob Zertifikat und privater Schlüssel zusammengehören. durch Vergleich ihrer Moduli: openssl x509 -noout -modulus -in certificate.pem | openssl md5 und openssl rsa -noout -modulus -in privateKey.key | openssl md5 müssen identische Ergebnisse liefern.
• Untersuchen Sie ein PFX-Bundle ohne den Inhalt zu exportieren: openssl pkcs12 -info -in certificate.pfx -nooutÜberprüfen Sie anschließend, ob Zertifikat, Zertifikatskette und Schlüssel vorhanden sind.

Die konvertierte Datei sollte erst dann bereitgestellt werden, wenn alle oben genannten Prüfungen erfolgreich bestanden wurden. Auch dann sollte die Bereitstellung in einem Wartungsfenster erfolgen, in dem die Möglichkeit besteht, den vorherigen Zustand sofort wiederherzustellen.

Wie sieht das Rollback-Verfahren aus, wenn eine Konvertierung etwas beschädigt?

Bewahren Sie die Originalzertifikats- und Schlüsseldateien während des gesamten Änderungszeitraums unberührt in einem separaten, zugriffsgeschützten Sicherungsverzeichnis auf und überschreiben oder löschen Sie diese erst, nachdem die konvertierte Datei in der Produktionsumgebung über einen definierten Beobachtungszeitraum (üblicherweise 24 bis 72 Stunden) getestet und verifiziert wurde. Falls ein Dienst nicht startet, ein Kettenfehler auftritt oder ein Client das neue Zertifikat ablehnt, führen Sie ein Rollback durch, indem Sie die Originaldatei im ursprünglichen Pfad wiederherstellen, alle Konfigurationsänderungen, die auf das neue Format verweisen, rückgängig machen und den betroffenen Dienst neu starten. Führen Sie anschließend die oben genannten Validierungsprüfungen mit dem wiederhergestellten Original erneut durch, bevor Sie den Vorfall abschließen. Versuchen Sie niemals, eine fehlgeschlagene Bereitstellung durch einen zweiten Live-Konvertierungsversuch zu „reparieren“. Führen Sie stattdessen zuerst ein Rollback durch, analysieren Sie das Problem anhand der Sicherungskopie und versuchen Sie es im nächsten Wartungsfenster erneut.

Was sollte bei einer Änderung des Zertifikatsformats protokolliert werden?

Behandeln Sie jede Änderung des Zertifikatsformats als prüfbares Ereignis und nicht als einmaligen Befehl. Protokollieren Sie für jede Konvertierung, ob manuell oder automatisiert, Folgendes:

• Zeitstempel, Bedieneridentität und die Wechselgeld- oder Ticketnummer, die die Arbeit autorisiert.
• Quellformat, Zielformat und der exakte ausgeführte OpenSSL-Befehl (wobei etwaige Passwörter aus dem Protokoll entfernt wurden).
• Eine Prüfsumme (zum Beispiel, sha256sum certificate.pem) sowohl der Originaldatei als auch der konvertierten Datei, sodass nachgewiesen werden kann, dass die Konvertierung die Identität des Zertifikats nicht verändert hat.
• Das Zielsystem und der Dienst, auf dem das konvertierte Zertifikat bereitgestellt wurde, sowie das Ergebnis jeder Validierungsprüfung.
• Bestätigung, dass die Originaldatei für Rollback-Zwecke aufbewahrt wurde und wo sie sich befindet.

Dieses Protokoll ist das, was ein Auditor gemäß ISO/IEC 27001:2022 oder SOC 2 Änderungsmanagementkontrollen verlangt, und es ist der Unterschied zwischen einer vertretbaren betrieblichen Änderung und einem unerklärten Zertifikatsaustausch in einem Produktionssystem.

Was sind die häufigsten Fehler bei der Zertifikatskonvertierung und wie lassen sie sich beheben?

Fehler oder Symptom	Wahrscheinliche Ursache	Fixieren
OpenSSL fordert wiederholt ein Passwort an, das Sie nicht haben.	Der private Schlüssel im Quell-PFX- oder PEM-Format ist passwortgeschützt, und das Passphrase wurde nicht angegeben oder ist unbekannt.	Ermitteln Sie die ursprüngliche Passphrase des Zertifikatsausstellers. Sollte diese tatsächlich unwiederbringlich verloren sein, stellen Sie das Zertifikat neu aus, anstatt zu versuchen, das Passwort zu umgehen.
Fehler „Zertifikat konnte nicht geladen werden“ oder „Keine Startlinie“	Die Datei ist eigentlich keine PEM-Datei (oft eine DER-Datei mit der Endung .cer oder .pem oder ein fehlerhafter Download).	Bestätigen Sie die tatsächliche Kodierung mit einer Hex-/Textprüfung und verwenden Sie dann die passende Kodierung. -inform der or -inform pem Flagge statt raten
„Konnte kein lokales Ausstellerzertifikat erhalten“ während openssl verify	Das Zwischenzertifikat der Zertifizierungsstelle fehlt im übergebenen Zertifikatspaket. -CAfile	Erstellen Sie das CA-Bundle mit den korrekten Zwischen- und Stammzertifikaten in der richtigen Reihenfolge neu und führen Sie die Überprüfung erneut aus.
Der PKCS#12-Export oder -Import schlägt unter OpenSSL 3.x für eine ältere PFX-Datei fehl.	Die PFX-Datei wurde mit RC2 oder 3DES verschlüsselt, was OpenSSL 3.x in einen Legacy-Provider ausgelagert hat.	Fügen Sie -legacy Fahne zum openssl pkcs12 Befehl ausführen oder die PFX-Datei mit einem aktuellen Verschlüsselungsalgorithmus neu exportieren, sobald Sie sie entschlüsseln können.
Die Modulowerte von Zertifikat und privatem Schlüssel stimmen nach der Konvertierung nicht überein.	Es wurde die falsche Schlüsseldatei verwendet oder das falsche Zertifikat konvertiert.	Führen Sie die Konvertierung mit dem bestätigten korrekten Schlüssel-/Zertifikatspaar aus der Sicherung erneut durch und überprüfen Sie den Modulusvergleich erneut.
Die Zielplattform lehnt das konvertierte Zertifikat weiterhin ab.	Das Format stimmte überein, aber die erforderliche Zertifikatskette (Zwischenzertifikate) war nicht in der Ausgabe enthalten.	Führen Sie den Export erneut aus mit -certfile auf die vollständige Zwischenkette zeigen und bestätigen mit openssl pkcs12 -info or openssl x509 -text dass die Kette vorhanden ist

Welche operativen Ergebnisse können Sie von einem gut durchgeführten Konvertierungsprozess erwarten?

Eine Änderung des Zertifikatsformats, die die oben genannten Voraussetzungen, Validierungs-, Rücksetzungs- und Protokollierungsschritte befolgt, sollte messbare Ergebnisse liefern und nicht nur die Meldung „Es hat funktioniert“:

• Keine ungeplanten Ausfallzeiten auf dem Zieldienst, da das konvertierte Zertifikat vor der Bereitstellung und nicht erst danach anhand der Plattformanforderungen validiert wurde.
• Eine 100-prozentige Validierungserfolgsquote Bevor ein konvertiertes Zertifikat in die Produktion gelangt, wird es mit dem openssl verify und die oben genannten Modulo-Übereinstimmungsprüfungen.
• Ein vollständiges, nachvollziehbares Änderungsprotokoll Bei jeder Umstellung werden die Anforderungen an den Änderungsmanagementnachweis ohne zusätzlichen Umbauaufwand erfüllt.
• Eine dokumentierte mittlere Zeit bis zum Rollback im Rahmen des für die Änderung definierten Beobachtungszeitraums, anstatt im Falle eines Fehlers ad hoc zu reagieren.

Welches Zertifikatsformat benötigt jede Plattform?

Format	Codierung	Typischer Anwendungsfall	Gemeinsame Systeme
PEM (.pem, .crt, .cer, .key)	Base64-ASCII-Text	Separate Zertifikats-, Ketten- und Schlüsseldateien werden direkt vom Webserver bereitgestellt.	Apache, Nginx, die meisten Linux/Unix-Dienste, OpenSSL-basierte Anwendungen
DER (.der, .cer)	Binär	Anwendungen, die die rohe binäre X.509-Struktur ohne Headerzeilen benötigen	Java-Keystores (über keytool), einige eingebettete Systeme und IoT-Systeme, bestimmte Windows-Binärimportvorgänge
PFX/PKCS#12 (.pfx, .p12)	Binäres, passwortgeschütztes Paket	Übertragung von Zertifikat, Zertifikatskette und privatem Schlüssel in einer einzigen Datei	Windows Server, IIS, Exchange, macOS Keychain-Import, Kubernetes TLS-Secrets aus einem Bundle erstellt
P7B/PKCS#7 (.p7b, .p7c)	Base64-ASCII-Text, kein privater Schlüssel	Verteilung einer Zertifikatskette ohne Offenlegung von Schlüsselmaterial	Windows- und IIS-Kettenimport, Java Tomcat-Truststore-Import

Welche Einschränkungen gibt es bei der manuellen Zertifikatsformatkonvertierung?

Das oben beschriebene OpenSSL-Runbook ist für ein einzelnes Zertifikat oder eine kleine, geplante Charge zuverlässig, stößt aber bei größeren Datenmengen an seine Grenzen. Private Schlüssel werden über Shell-Befehle und, bei unvorsichtiger Handhabung, über Shell-Verlauf und Skriptprotokolle übertragen, was ein unnötiges Datenleck darstellt. Das Verhalten von OpenSSL ändert sich zwischen den Hauptversionen, beispielsweise die 3.x-Abhängigkeitsanforderung für ältere PKCS#12-Dateien durch Legacy-Provider. Ein für eine Version geschriebenes Skript kann daher bei einer anderen Version unbemerkt fehlschlagen. Die manuelle Konvertierung bietet keine integrierte Protokollierung; die oben beschriebene Protokollierungsdisziplin muss vom Bediener jedes Mal manuell durchgesetzt werden und wird unter Zeitdruck oft vernachlässigt. All dies ist nicht skalierbar für die Tausenden von Zertifikaten, die ein mittelständisches Unternehmen typischerweise auf mehreren Plattformen und in Cloud-Umgebungen verwaltet.

Was würde Encryption Consulting empfehlen?

Für einige wenige Zertifikate sind die oben genannten OpenSSL-Befehle das richtige Werkzeug. Darüber hinaus stellt die manuelle Formatkonvertierung das operative Risiko dar, das dieses Handbuch minimieren soll: manuelle Verwaltung privater Schlüssel, Validierungsschritte, deren Ausführung von einer Person abhängt, und keine zentrale Informationsquelle darüber, welches Zertifikat in welchem ​​Format auf welchem ​​Server vorliegt.

CertSecure Manager eliminiert den manuellen Schritt vollständig: Er stellt Zertifikate aus, erneuert sie und exportiert sie direkt im Format, das die Zielplattform benötigt – sei es ein PEM-Bundle für Nginx oder ein passwortgeschütztes PFX-Format für IIS. Dabei muss kein Bediener jemals einen privaten Schlüssel über die Kommandozeile bearbeiten. Jeder Export wird automatisch protokolliert, die Zertifikatsketten werden automatisch gebündelt und Formatabweichungen werden vor der Bereitstellung erkannt, anstatt erst bei einem Produktionsausfall. Werden Zertifikate über eine verwaltete Zertifizierungsstelle (CA) anstatt einer lokalen CA ausgestellt, erweitert PKI-as-a-Service dasselbe automatisierte Ausstellungs- und Exportmodell, ohne dass Sie die CA-Infrastruktur selbst betreiben müssen. Wenn Sie den Inhalt eines Zertifikats vor oder nach einer Konvertierung überprüfen möchten, ohne etwas installieren zu müssen, können Sie die kostenlosen Tools von EC – OpenSSL CSR and Certificate Decoder und ASN.1 CSR and Certificate Decoder – verwenden, um Zertifikatsfelder direkt im Browser zu analysieren und anzuzeigen. Encryption Consulting ist nach ISO/IEC 27001:2022 und SOC 2 zertifiziert, daher ist der gleiche Audit-Trail, den Sie in diesem Runbook manuell erstellen sollen, eine integrierte Funktion der Zertifikatslebenszyklusprotokolle von CertSecure Manager.

Eine praxisnahe Anleitung zur Verwendung dieser OpenSSL-Befehle bei einer Zertifikatserneuerung finden Sie unter „ Zertifikatserneuerung auf Apache mit CertSecure Manager“ . Eine detailliertere Anleitung zur Konvertierung von PFX in PEM finden Sie unter „ Nahtlose Konvertierung einer PFX-kodierten Zertifikatsdatei in das PEM-Format mit OpenSSL“.

Fazit

Die Änderung des Formats eines digitalen Zertifikats wird zur Routineaufgabe, wenn man sie als Ablaufplan statt als einmaligen Befehl behandelt: Die tatsächlichen Anforderungen der Zielplattform prüfen, die Originale sichern, den korrekten OpenSSL-Befehl ausführen, die Ausgabe validieren und die Änderungen protokollieren. Diese Vorgehensweise verhindert, dass eine Zertifikatsmigration zu einem Ausfall führt. Steigt die Anzahl der verwalteten Zertifikate über den Rahmen, den ein einzelner Mitarbeiter manuell bewältigen kann, gewährleistet die Automatisierung der Ausstellung und des Exports im korrekten Format für jede Plattform – mit CertSecure Manager oder einer vergleichbaren PKI-as-a-Service-Plattform – die Zuverlässigkeit dieses Prozesses auch bei großem Umfang.

Häufig gestellte Fragen

Was ist der Unterschied zwischen den Zertifikatsformaten PEM und DER? PEM (Privacy-Enhanced Mail) ist ein Base64-ASCII-kodiertes Format, das durch die Zeilen „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE—–“ begrenzt wird und häufig von Apache, Nginx und OpenSSL-basierten Anwendungen verwendet wird. DER (Distinguished Encoding Rules) ist die Binärform derselben X.509-Daten ohne Headerzeilen und wird häufig von Java-Keystores und einigen Windows-Binärimporten benötigt. Die Konvertierung zwischen den Formaten ist mit einem einzigen OpenSSL-Befehl möglich.

Kann ich ein Zertifikatsformat ohne OpenSSL konvertieren? Bei Formaten der PEM-Familie (.pem, .crt, .cer, .key) funktioniert das Umbenennen der Dateiendung, da die zugrundeliegende Base64-Kodierung unverändert bleibt. Eine Konvertierung zu oder von einer wirklich anderen Kodierung, wie z. B. von PEM zu DER oder PFX, ist durch bloßes Umbenennen nicht möglich, da diese Formate eine andere Byte-Kodierung verwenden oder zusätzliche Daten wie einen privaten Schlüssel enthalten. Für eine echte Formatkonvertierung ist OpenSSL oder eine vergleichbare Bibliothek erforderlich.

Ist es sicher, eine PFX-Datei mit einem privaten Schlüssel zu konvertieren? Ja, sofern Sie den privaten Schlüssel mit der gleichen Sorgfalt behandeln wie die Originaldatei. Speichern Sie das PFX-Passwort und alle exportierten PEM-Schlüssel nicht in der Shell-Historie oder der Versionskontrolle, beschränken Sie die Dateiberechtigungen auf das Konto, das sie benötigt, und löschen Sie entschlüsselte Zwischendateien nach Abschluss der Konvertierung und Validierung.

Welches Zertifikatsformat benötigen IIS oder Windows im Vergleich zu Apache oder Nginx? Windows Server, IIS und Exchange benötigen üblicherweise eine PFX-Datei (PKCS#12), da diese das Zertifikat, die Zertifikatskette und den privaten Schlüssel in einer passwortgeschützten Datei bündelt. Apache und Nginx erwarten separate, PEM-kodierte Dateien für Zertifikat, Kette und privaten Schlüssel. Die Konvertierung zwischen den beiden Formaten ist eine der häufigsten Änderungen, die Betriebsteams bei einer Servermigration vornehmen.

Was tun, wenn OpenSSL während der Konvertierung nach einem Passwort fragt, das ich nicht kenne? Diese Aufforderung bedeutet, dass die Quelldatei verschlüsselt ist, typischerweise eine PFX-Datei oder ein PEM-Schlüssel mit einer Passphrase. Wenn das Passwort tatsächlich unbekannt ist, kann die Datei mit OpenSSL nicht entschlüsselt werden. Sie müssen das Zertifikat dann bei der Zertifizierungsstelle oder dem System, das es ursprünglich ausgestellt hat, neu ausstellen lassen. Versuchen Sie niemals, das Passwort eines Produktivschlüssels per Brute-Force-Angriff zu knacken oder zu umgehen.

Referenzen

• OpenSSL, OpenSSL-Dokumentation
• IETF, RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• IETF, RFC 7292: PKCS #12: Syntax für den persönlichen Informationsaustausch v1.1