Hur ändrar man formatet på digitala certifikat sömlöst?

Key Takeaways

• PEM, DER, PFX/PKCS#12 och P7B/PKCS#7 är de fyra certifikatformat du oftast konverterar mellan, och vart och ett mappas till specifika serverplattformar.
• OpenSSL hanterar alla vanliga konverteringsvägar med ett enda kommando; att byta namn på en filändelse fungerar bara inom PEM-familjen (.pem, .crt, .cer, .key).
• Säkerhetskopiera originalfilerna och registrera en kontrollsumma innan du konverterar något som innehåller en privat nyckel.
• Validera varje konverterat certifikat med OpenSSL innan du distribuerar det och håll återställningssökvägen redo.
• Manuell konvertering skalar inte bortom ett fåtal certifikat; CertSecure Manager automatiserar formatkonvertering och export som en del av certifikatlivscykeln.

Publicerad: juli 2021. Uppdaterad: augusti 2026. Granskad av Encryption Consultings PKI Operations-team.

Vilka digitala certifikatformat finns det, och vad betyder vart och ett?

Ett digitalt certifikat är samma underliggande X.509-datastruktur oavsett hur det lagras; formatet ändrar bara hur informationen kodas på disken och vad den paketeras med. Varje företags-PKI-operatör använder fyra format regelbundet:

• PEM (sekretessförbättrad e-post): Ett Base64 ASCII-kodat textformat avgränsat av raderna “—–BEGIN CERTIFICATE—–” och “—–END CERTIFICATE—–”. En PEM-fil kan innehålla ett certifikat, en privat nyckel eller en hel kedja, en efter en. Vanliga filändelser: .pem, .crt, .cer, .key, .ca-bundle. Används av Apache, Nginx och de flesta OpenSSL-baserade applikationer.
• DER (Distinguished Encoding Rules): den binära kodningen av samma X.509-data, utan BEGIN/END-rubrikrader. Eftersom den är binär kan du inte säkert redigera eller sammanfoga en DER-fil i en textredigerare. Vanliga filtillägg: .der, .cer. Används av Java-nyckellager och vissa Windows-importflöden för binärfiler.
• PFX/PKCS#12: ett lösenordsskyddat binärarkiv (PFX är Windows-namnet för en PKCS#12-fil) som samlar servercertifikatet, den mellanliggande kedjan och den privata nyckeln i en fil. Vanliga filändelser: .pfx, .p12. Används av Windows, IIS och Exchange för import och export.
• P7B/PKCS#7: Ett Base64-kodat certifikatkedjeformat begränsat av raderna “—–BEGIN PKCS7—–” och “—–END PKCS7—–”. Den kan inte lagra en privat nyckel, endast certifikat och en certifikatåterkallningslista (CRL). Vanliga tillägg: .p7b, .p7c. Används av Java Tomcat och Windows kedjeimportarbetsflöden.

Inget format är säkrare eller mer korrekt än ett annat; certifikatets kryptografiska innehåll är identiskt i alla. Vilket format du behöver dikteras helt av vad destinationsplattformen förväntar sig, vilket är anledningen till att formatkonvertering är en rutinmässig operativ uppgift snarare än ett säkerhetsbeslut.

Vad behöver du innan du konverterar ett certifikatformat?

Bekräfta dessa fem punkter innan du kör ett konverteringskommando mot ett certifikat som är live på ett produktionssystem.

• OpenSSL installerat och dess version bekräftad. Körning openssl version först. OpenSSL 3.x flyttade äldre PKCS#12-kryptering (RC2, 3DES) till en äldre leverantör, så en PFX som exporterades för flera år sedan kan behöva -legacy flagga tillagd till kommandot.
• Åtkomst till den privata nyckeln vid konvertering till eller från PFX/PKCS#12, och bekräftelse av vem som är behörig att hantera det.
• En verifierad säkerhetskopia av originalcertifikatet och nyckelfilerna, kopierad till en separat plats innan något kommando körs, plus en inspelad kontrollsumma (se loggningsavsnittet nedan).
• Destinationssystemets exakta obligatoriska format, bekräftad mot beslutstabellen längre ner på denna sida snarare än antagen.
• En mellanlagringsmiljö eller ett underhållsfönster för att testa den konverterade filen innan den ersätter certifikatet på en produktionstjänst.

Hur konverterar man mellan certifikatformat med OpenSSL?

Varje konvertering nedan är ett enda OpenSSL-kommando. Kör varje kommando mot din säkerhetskopia, inte mot filen som för närvarande används av en aktiv tjänst.

Steg för steg: Konvertera PEM till DER

1. Kopiera certificate.pem till en arbetskatalog och bekräfta att den öppnas som läsbar Base64-text.
2. Springa: openssl x509 -outform der -in certificate.pem -out certificate.der
3. Bekräfta certificate.der skapades och är binär (den öppnas inte felfritt som text).

Steg för steg: Konvertera DER till PEM

1. Bekräfta att källfilen verkligen är en DER-kodad binärfil innan du kör kommandot; filändelsen .cer kan vara antingen PEM eller DER.
2. Springa: openssl x509 -inform der -in certificate.der -out certificate.pem
3. Öppet certificate.pem i en textredigerare och bekräfta att den nu visar “—–BEGIN CERTIFICATE—–”.

Steg för steg: Konvertera PEM till PFX (PKCS#12)

1. Bekräfta att du har certifikatet (certificate.crt), dess matchande privata nyckel (privateKey.key), och, om tillgänglig, CA-kedjefilen (CAcert.crt).
2. Springa: openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CAcert.crt
3. Ange ett starkt exportlösenord när du uppmanas. -certfile CAcert.crt flaggan är valfri; använd den för att paketera mellankedjan i PFX så att destinationssystemet inte behöver den separat.

Steg för steg: Konvertera PFX till PEM

1. Bekräfta att du har PFX-filen och dess exportlösenord.
2. Springa: openssl pkcs12 -in certificate.pfx -out certificate.pem -nodes
3. OpenSSL kommer att be om PFX-lösenordet och sedan skriva certifikatet, kedjan och den okrypterade privata nyckeln till en enda PEM-fil. Öppna den i en textredigerare och dela upp den i separata certifikat- och nyckelfiler om destinationsplattformen kräver det, och behåll varje "—–BEGIN—–"/"—–END—–"-block intakt.
4. Drop -nodes om du vill att den extraherade privata nyckeln ska förbli krypterad med en lösenfras i PEM-utdata.

För P7B/PKCS#7-kedjeformatet: konvertera PEM till P7B med openssl crl2pkcs7 -nocrl -certfile certificate.cer -certfile CAcert.cer -out certificate.p7b (den andra -certfile är valfritt, används för att paketera ett ytterligare kedjecertifikat) och extrahera certifikat från en P7B tillbaka till PEM med openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cerEftersom P7B inte kan inneha en privat nyckel är konverteringen av P7B till PFX en tvåstegsprocess: extrahera certifikaten med kommandot ovan och kör sedan openssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CAcert.cer med hjälp av den privata nyckel du redan har till hands.

En genväg är säker att använda: att byta namn på en fil mellan .pem, .crt, .cer och .key ändrar ingenting i den underliggande Base64-kodningen, så ett enkelt namnbyte fungerar inom den familjen. Det fungerar inte mellan familjer. Att byta namn på en PEM-fil till .der gör den inte till en binär DER, och att byta namn på en certifikatfil till .pfx paketerar inte in en privat nyckel. Överallt där kodningen eller filens innehåll verkligen behöver ändras, kör istället matchande OpenSSL-kommando ovan.

Hur validerar man ett konverterat certifikat?

Validera utdata innan den når en produktionstjänst. Kör dessa kontroller mot den konverterade filen:

• Bekräfta certifikatparsningarna och kontrollera dess detaljer: openssl x509 -in certificate.pem -text -noout (använda sig av -inform der (för en DER-fil). Granska ämne, utfärdare, giltighetsdatum och alternativa ämnesnamn mot vad du förväntar dig.
• Verifiera förtroendekedjan: openssl verify -CAfile ca-bundle.pem certificate.pem bör återvända certificate.pem: OK.
• Bekräfta att certifikatet och den privata nyckeln är ett matchande par genom att jämföra deras moduler: openssl x509 -noout -modulus -in certificate.pem | openssl md5 och openssl rsa -noout -modulus -in privateKey.key | openssl md5 måste producera identisk utdata.
• Inspektera ett PFX-paket utan att exportera dess innehåll: openssl pkcs12 -info -in certificate.pfx -nooutoch bekräfta sedan att certifikatet, kedjan och nyckeln finns.

Först efter att varje kontroll ovan har godkänts bör den konverterade filen driftsättas, och även då, driftsätta den i ett underhållsfönster med möjlighet att omedelbart återställa.

Vad är återställningsproceduren om en konvertering förstör något?

Förvara originalcertifikatet och nyckelfilerna orörda på en separat, åtkomstkontrollerad säkerhetskopia under hela ändringsfönstret och skriv inte över eller radera dem förrän den konverterade filen har varit live och verifierad i produktion under en definierad observationsperiod (vanligtvis 24 till 72 timmar). Om en tjänst misslyckas med att starta, visar ett kedjefel eller en klient avvisar det nya certifikatet, återställ originalfilen till dess ursprungliga sökväg, återställ eventuella konfigurationsändringar som pekade mot det nya formatet och starta om den berörda tjänsten. Kör sedan valideringskontrollerna ovan mot det återställda originalet innan du stänger incidenten. Försök aldrig ett andra livekonverteringsförsök för att "fixa" en misslyckad distribution. Återställ först, diagnostisera mot säkerhetskopian och försök igen i nästa underhållsfönster.

Vad ska du logga vid en ändring av certifikatformat?

Behandla varje ändring av certifikatformat som en granskningsbar händelse, inte ett engångskommando. Registrera följande för varje konvertering, oavsett om den görs manuellt eller automatiserat:

• Tidsstämpel, operatörsidentitet och ändrings- eller ärendenummer som godkänner arbetet.
• Källformat, målformat och exakt vilket OpenSSL-kommando som kördes (och redigerade lösenord från loggen).
• En kontrollsumma (till exempel sha256sum certificate.pem) av både originalfilen och den konverterade filen, så att det kan bevisas att konverteringen inte har ändrat certifikatets identitet.
• Målsystemet och tjänsten som det konverterade certifikatet distribuerades till, och resultatet av varje valideringskontroll.
• Bekräftelse av att originalfilen behölls och var, för återställningsändamål.

Denna logg är vad en revisor begär enligt ISO/IEC 27001:2022 eller SOC 2 ändringshanteringskontroller, och det är skillnaden mellan en försvarbar driftsförändring och ett oförklarat certifikatutbyte i ett produktionssystem.

Vilka är de vanligaste felen vid certifikatkonvertering, och hur åtgärdar man dem?

Fel eller symptom	Troligtvis orsak	Fast
OpenSSL frågar upprepade gånger efter ett lösenord du inte har	Den privata nyckeln för käll-PFX eller PEM är lösenfrasskyddad och lösenfrasen angavs inte eller är okänd	Leta reda på den ursprungliga lösenfrasen från den som utfärdade certifikatet; om den verkligen är oåterkallelig, utfärda certifikatet på nytt istället för att försöka kringgå lösenordet.
Felmeddelandet ”Det gick inte att ladda certifikatet” eller ”Ingen startrad”	Filen är egentligen inte PEM (ofta en DER-fil med filändelsen .cer eller .pem, eller en skadad nedladdning)	Bekräfta den riktiga kodningen med en hex/text-kontroll och använd sedan matchningen. -inform der or -inform pem flagga istället för att gissa
"Det gick inte att hämta lokalt utfärdarcertifikat" under openssl verify	Det mellanliggande CA-certifikatet saknas i kedjepaketet som skickades till -CAfile	Återuppbygg CA-paketet med rätt mellanliggande certifikat och rotcertifikat, i ordning, och kör verifieringen igen.
PKCS#12-export eller -import misslyckas på OpenSSL 3.x för en äldre PFX-fil	PFX krypterades med RC2 eller 3DES, vilket OpenSSL 3.x flyttade till en äldre leverantör.	Lägg till -legacy flagga till openssl pkcs12 kommandot, eller exportera PFX igen med en aktuell chiffer när du kan dekryptera den
Certifikat- och privatnyckelmodulvärden matchar inte efter konvertering	Fel nyckelfil användes, eller så konverterades fel certifikat	Kör om konverteringen med det bekräftade korrekta nyckel-/certifikatparet från säkerhetskopian och kontrollera moduljämförelsen igen.
Destinationsplattformen avvisar fortfarande det konverterade certifikatet	Formatet matchade men den erforderliga kedjan (mellanliggande certifikat) inkluderades inte i utdata.	Kör exporten igen med -certfile pekar mot hela mellankedjan och bekräftar med openssl pkcs12 -info or openssl x509 -text att kedjan finns

Vilka operativa resultat bör du förvänta dig av en väl genomförd konverteringsprocess?

En ändring av certifikatformatet som följer stegen för förutsättningar, validering, återställning och loggning ovan bör ge mätbara resultat, inte bara "det fungerade":

• Noll oplanerad driftstopp på måltjänsten, eftersom det konverterade certifikatet validerades mot plattformens krav före distributionen, inte efter.
• 100 procents godkänd valideringsgrad innan något konverterat certifikat når produktionsstatus, verifierat med openssl verify och modulmatchningskontroller ovan.
• En komplett, granskbar ändringslogg för varje konvertering, vilket uppfyller begäranden om bevis för ändringshantering utan extra rekonstruktionsarbete.
• En dokumenterad genomsnittlig tid till återställning under det observationsfönster som definierats för ändringen, snarare än en ad hoc-förvrängning om något går sönder.

Vilket certifikatformat kräver varje plattform?

Format	kodning	Typiskt användningsfall	Vanliga system
PEM (.pem, .crt, .cer, .key)	Base64 ASCII-text	Separata certifikat-, kedje- och nyckelfiler som hanteras direkt av webbservern	Apache, Nginx, de flesta Linux/Unix-tjänster, OpenSSL-baserade applikationer
DER (.der, .cer)	Binary	Applikationer som kräver den råa binära X.509-strukturen utan rubrikrader	Java-nyckellager (via keytool), vissa inbäddade system och IoT-system, vissa importflöden för binär Windows-filer
PFX/PKCS#12 (.pfx, .p12)	Binärt, lösenordsskyddat paket	Överföring av certifikat, kedja och privat nyckel i en enda fil	Windows Server, IIS, Exchange, import av macOS-nyckelring, Kubernetes TLS-hemligheter byggda från ett paket
P7B/PKCS#7 (.p7b, .p7c)	Base64 ASCII-text, ingen privat nyckel	Distribuera en certifikatkedja utan att exponera något nyckelmaterial	Import av Windows- och IIS-kedjor, import av Java Tomcat-förtroendelager

Vilka är begränsningarna med manuell konvertering av certifikatformat?

OpenSSL-runbooken ovan är tillförlitlig för ett certifikat eller en liten, planerad batch, men den har verkliga begränsningar i stor skala. Privat nyckelmaterial passerar genom shell-kommandon och, om man inte är försiktig, shell-historik och skriptloggar, vilket är en onödig exponeringsrisk. OpenSSLs eget beteende ändras mellan större versioner, till exempel kravet på 3.x-leverantörer för äldre PKCS#12-filer, och ett skript som skrivs mot en version kan misslyckas tyst mot en annan. Manuell konvertering har ingen inbyggd revisionslogg; loggningsdisciplinen ovan måste upprätthållas av operatören varje gång, och det är det första som hoppas över under deadlinepress. Inget av detta skalas till de tusentals certifikat som ett medelstort företag vanligtvis hanterar över flera plattformar och molnmiljöer.

Vad skulle krypteringskonsulter rekommendera?

För en handfull certifikat är OpenSSL-kommandona ovan rätt verktyg. Utöver det blir manuell formatkonvertering den operativa risk som denna runbook finns för att kontrollera: privata nycklar som hanteras manuellt, valideringssteg som är beroende av att en individ kommer ihåg att köra dem, och ingen enskild sanningskälla för vilket certifikat som är i vilket format på vilken server.

CertSecure Manager tar bort det manuella steget helt: det utfärdar, förnyar och exporterar certifikat direkt i det format som målplattformen kräver, oavsett om det är ett PEM-paket för Nginx eller en lösenordsskyddad PFX för IIS, utan att en operatör någonsin rör en privat nyckel på kommandoraden. Varje export loggas automatiskt, kedjepaketering hanteras åt dig och formatavvikelser upptäcks före distribution snarare än att upptäckas som ett produktionsavbrott. Där certifikat utfärdas via en hanterad CA snarare än en lokal, utökar PKI-as-a-Service samma automatiserade utfärdande- och exportmodell utan att du själv behöver använda CA-infrastrukturen. Om du vill kontrollera ett certifikats innehåll före eller efter en konvertering utan att installera något, kan EC:s kostnadsfria verktyg OpenSSL CSR and Certificate Decoder och ASN.1 CSR and Certificate Decoder analysera och visa certifikatfält direkt i webbläsaren. Encryption Consulting är ISO/IEC 27001:2022- och SOC 2-certifierat, så samma revisionslogg som den här runbooken ber dig att bygga för hand är en inbyggd funktion i CertSecure Managers certifikatlivscykelloggar.

För en relaterad, verklighetstrogen genomgång som använder samma OpenSSL-kommandon under en certifikatförnyelse, se Förnya certifikat på Apache med CertSecure Manager . För en djupare genomgång med en enda konvertering specifikt av PFX-till-PEM-sökvägen, se Så här konverterar du sömlöst PFX-kodad certifikatfil till PEM-format med OpenSSL.

Slutsats

Att ändra formatet på ett digitalt certifikat är en rutinmässig operativ uppgift när du behandlar det som en runbook istället för ett engångskommando: bekräfta destinationsplattformens verkliga krav, säkerhetskopiera originalen, kör rätt OpenSSL-kommando, validera utdata och logga vad som ändrats. Den disciplinen är det som hindrar en certifikatmigrering från att bli ett avbrott. När antalet certifikat du hanterar växer bortom vad en operatör säkert kan spåra manuellt, är automatisering av utfärdande och export i rätt format för varje plattform, med CertSecure Manager eller en motsvarande PKI-as-a-Service-plattform, det som gör att processen är tillförlitlig i stor skala.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan PEM- och DER-certifikatformat? PEM (Privacy-Enhanced Mail) är ett Base64 ASCII-kodat format som begränsas av raderna "—–BEGIN CERTIFICATE—–" och "—–END CERTIFICATE—–", och används vanligtvis av Apache-, Nginx- och OpenSSL-baserade applikationer. DER (Distinguished Encoding Rules) är den binära formen av samma X.509-data utan rubrikrader, vilket vanligtvis krävs av Java-nyckellager och vissa Windows-binärimporter. Du kan konvertera mellan dem med ett enda OpenSSL-kommando i endera riktningen.

Kan jag konvertera ett certifikatformat utan OpenSSL? För PEM-familjeformat (.pem, .crt, .cer, .key) fungerar det att byta namn på filändelsen eftersom den underliggande Base64-kodningen inte ändras. Du kan inte konvertera till eller från en helt annan kodning, till exempel PEM till DER eller PEM till PFX, genom att enbart byta namn, eftersom dessa format använder olika bytenivåkodningar eller paketerar ytterligare data som en privat nyckel. OpenSSL, eller ett motsvarande bibliotek, krävs för en verklig formatkonvertering.

Är det säkert att konvertera en PFX-fil som innehåller en privat nyckel? Ja, om du hanterar den privata nyckeln med samma försiktighet som du skulle ge originalfilen. Håll PFX-lösenordet och alla exporterade privata PEM-nycklar borta från skalhistorik och versionshantering, begränsa filbehörigheter till det konto som behöver dem och radera dekrypterade mellanliggande filer när konverteringen och valideringen är klar.

Vilket certifikatformat behöver IIS eller Windows jämfört med Apache eller Nginx? Windows Server, IIS och Exchange kräver vanligtvis en PFX-fil (PKCS#12) eftersom den paketerar certifikatet, dess kedja och den privata nyckeln i en lösenordsskyddad fil. Apache och Nginx förväntar sig separata PEM-kodade filer för certifikatet, kedjan och den privata nyckeln. Konvertering mellan de två är en av de vanligaste ändringarna i certifikatformat som driftteam utför under en servermigrering.

Vad ska jag göra om OpenSSL frågar efter ett lösenord jag inte har under konverteringen? Frågan betyder att källfilen är krypterad, vanligtvis en PFX-fil eller en privat PEM-nyckel med en lösenfras. Om lösenordet verkligen är okänt kan du inte dekryptera filen med OpenSSL, och du måste utfärda certifikatet på nytt från certifikatutfärdaren eller systemet som ursprungligen genererade det. Försök aldrig att brute-force eller kringgå lösenordet på en produktionsnyckel.

Referensprojekt

• OpenSSL, OpenSSL-dokumentation
• IETF, RFC 5280: Internet X.509 Public Key Infrastructure Certificate och CRL-profil
• IETF, RFC 7292: PKCS #12: Syntax för utbyte av personlig information v1.1