Zertifikatsformat-Konverter — PEM, DER, PFX, PKCS#8

Weil sie auf der WebCrypto-API des Browsers aufbauen, die AES kennt, aber weder RC2 noch 3DES. Von Windows, IIS und älterem keytool exportierte Bündel sind mit genau diesen beiden Verfahren verschlüsselt, ein reines WebCrypto-Werkzeug kann sie also nicht entschlüsseln und meldet meist ein falsches Passwort. Hier sind diese Verfahren direkt implementiert, eine .pfx von 2018 öffnet sich wie eine von heute Morgen.

Sie enthalten dieselben Daten. DER ist die rohe Binärkodierung; PEM ist genau dieses Binärformat in Base64 mit einer Kopfzeile „-----BEGIN …-----“ darum. Windows- und Java-Werkzeuge erzeugen eher DER mit den Endungen .der oder .cer, Unix-Software will PEM. Die Umwandlung ändert nur die Hülle, nie das Zertifikat.

nginx und Apache lesen beides. PKCS#8 („BEGIN PRIVATE KEY“) ist der moderne Standard und das, was Java, Go und .NET erwarten. PKCS#1 („BEGIN RSA PRIVATE KEY“) ist die ältere, nur für RSA gedachte Form. Lehnt Software Ihren Schlüssel ohne Begründung ab, lohnt sich die Umwandlung zwischen beiden — das ist eine häufige Ursache.

Ja. Werfen Sie fullchain.pem und privkey.pem gemeinsam hinein, wählen Sie PFX und setzen Sie ein Passwort. Für Windows 10 oder Server 2016 und neuer nehmen Sie das moderne Profil; scheitert der Import auf etwas Älterem mit einem Passwortfehler, probieren Sie das kompatible.

Ja. Es gibt eine alte Uneindeutigkeit dabei, wie ein leeres Passwort kodiert wird — OpenSSL und manche Java-Versionen sind sich uneins, und eine nach der einen Konvention geschriebene Datei öffnet sich nach der anderen nicht. Hier werden beide probiert, ein Bündel mit leerem Passwort öffnet sich also in jedem Fall.