Skillnader mellan .pfx, .p12, .cer och .crt förklaras i detalj

Om du har kommit så här långt och letat efter skillnaderna mellan .pfx, .p12, .cer och .crt har du förmodligen redan stött på mer än en konstig fil när du installerat ett digitalt certifikat eller SSL på en server. Du är inte ensam: mellan akronymer, filtillägg och format är det lätt att bli förvirrad och inte veta vad varje fil gör eller vilken du behöver i varje fall.

Den goda nyheten är att även om namnen kan låta skrämmande, kan allt detta förklaras ganska enkelt om vi förstår att dessa filer inte är något annat än behållare för certifikat och nycklar i olika format (text eller binärt) och utformade för olika system ( Windows , Linux , Java, webbläsare, etc.). Låt oss titta på dem en efter en, lugnt, och sedan relatera dem till varandra så att du vet exakt vad var och en är, vad den är till för och hur du använder eller konverterar dem vid behov.

Vad är ett digitalt certifikat och hur passar .pfx, .p12, .cer och .crt ihop?

Ett digitalt certifikat är helt enkelt ett elektroniskt dokument signerat av en certifieringsutfärdare (CA eller, enligt eIDAS-förordningen, en kvalificerad tjänsteleverantör) som kopplar en identitet till en offentlig nyckel. Den identiteten kan vara en person, ett företag, en webbserver, en domän etc.

För att uppnå denna koppling används kryptografi med offentlig nyckel eller asymmetrisk kryptografi : det finns ett par nycklar, en offentlig nyckel (som vem som helst kan känna till) och en privat nyckel (som bara ägaren ska ha). Det som är krypterat med den offentliga nyckeln kan bara dekrypteras med den privata nyckeln, och vice versa, vilket möjliggör autentisering, kryptering och elektroniska signaturer.

Bakom alla dessa certifikat finns en infrastruktur för offentlig nyckel eller PKI , som inkluderar certifieringsutfärdaren, registreringsutfärdare, certifikatarkiv, certifikatåterkallningslistor (CRL:er) och, i många miljöer, en tidsstämpelutfärdare (TSA) för att registrera när något signerades.

Den interna strukturen för de allra flesta allmänna certifikat följer X.509 -standarden , definierad av ITU och beskriven i detalj i RFC 5280. Denna standard definierar fält som version, serienummer, signaturalgoritm, utfärdare, giltighetsperiod, ämne, innehavarens publika nyckel och eventuella ytterligare tillägg.

När det gäller algoritmer använder certifikat vanligtvis asymmetrisk kryptografi med RSA, DSA eller ECDSA . RSA och ECDSA används för både signering och kryptering, medan DSA fokuserar på digital signatursignering och verifiering.

Interna format och tillägg: PEM, DER, CER, CRT och företag

När vi pratar om filtillägg som .cer, .crt, .pem, .der, .pfx, .p12 eller .p7b , blandar vi egentligen två begrepp: certifikatets kodningsformat (Base64-text eller binär) och filens funktion (endast certifikat, certifikat + privat nyckel, certifikatkedja, etc.).

På intern formatnivå representeras X.509-certifikat med ASN.1 och kodas vanligtvis med DER (binär) eller dess textvariant PEM (DER konverterad till Base64 och omsluten med BEGIN/END -rubriker ). Därifrån har olika system och standarder definierat specifika containrar som PKCS#7 (.p7b) eller PKCS#12 (.pfx, .p12).

Nyckeln till att undvika förvirring är att komma ihåg att filändelsen ofta bara är en namngivningskonvention : en .cer eller en .crt kan innehålla exakt samma sak, bara det ena används mer i Windows och det andra i Unix/Linux-miljöer, för att ge ett exempel.

Inom denna allmänna grupp finns det några viktiga format som du bör vara mycket tydlig med, eftersom det är dessa du kommer att stöta på hela tiden när du arbetar med SSL/TLS eller personliga certifikat.

PEM-format: den "läsbara texten" i certifikat

PEM-formatet är det absolut vanligaste för SSL/TLS-certifikat på servrar som Apache eller Nginx, och i de flesta säkerhetsverktyg. En PEM-fil är helt enkelt en DER-fil som är omkodad i Base64 och omgiven av textrubriker , vilket gör att den kan öppnas och kopieras med vilken textredigerare som helst (Anteckningar, nano, vim, etc.).

En PEM känns igen eftersom dess innehåll avgränsas av rader som —–BEGIN CERTIFICATE—– och —–END CERTIFICATE—– när den innehåller ett certifikat, eller —–BEGIN PRIVATE KEY—– och —–END PRIVATE KEY—– när den innehåller en privat nyckel. Allt däremellan är en Base64-sträng som representerar den ursprungliga binära datan.

En enda PEM-fil kan innehålla bara certifikatet , certifikatet plus den mellanliggande CA-kedjan, den privata nyckeln separat, eller till och med hela paketet (privat nyckel, servercertifikat, mellanliggande certifikat och rotcertifikat). Certifikatsigneringsförfrågningar ( CSR ), som helt enkelt är PKCS#10-strukturer omkodade till text, finns också i PEM-filer.

Detta format definierades ursprungligen i RFC:erna 1421-1424 som en del av projektet Privacy-enhanced Electronic Mail, vilket inte blev populärt för e-post, men lämnade efter sig ett utmärkt textformat för att transportera kryptografisk data på ett bekvämt, läsbart och lättkopierat/klistra-sätt.

I praktiken är filer med filändelser som .pem, .crt, .cer eller .key på Unix/Linux-system vanligtvis PEM-filer. Vanligtvis innehåller .key den privata nyckeln, .crt eller .cer innehåller servercertifikatet, och ibland innehåller en ytterligare PEM-fil den mellanliggande CA-kedjan.

DER-format: den enkla binära filen

DER (Distinguished Encoding Rules) är det binära kodningsformatet för ASN.1-strukturerna som beskriver ett X.509-certifikat. Det är inte text, så om du öppnar det med en editor kommer du att se konstiga tecken istället för den typiska Base64-strängen.

En DER-fil kan innehålla alla typer av certifikat eller privata nycklar och identifieras vanligtvis med filändelserna .der eller .cer, särskilt i Windows-miljöer eller på Java-plattformar. I Windows identifieras en .der-fil direkt som en certifikatfil och öppnas med det inbyggda visningsprogrammet när man dubbelklickar på den.

Den praktiska skillnaden med PEM är att medan PEM enkelt kan kopieras och skickas via e-post eller klistras in i webbformulär, är DER en sluten binär blob avsedd för direkt konsumtion av applikationer. Internt är informationen dock densamma: en PEM är helt enkelt en DER omkodad till Base64-text.

Verktyg som OpenSSL låter dig växla från DER till PEM och vice versa med ett enda kommando, utan att ändra certifikatets logiska innehåll alls, bara dess representationsform.

.cer och .crt filändelser: samma hund med olika halsband

Filtilläggen .cer och .crt används för att beteckna filer som innehåller offentliga certifikat , vanligtvis i PEM- eller DER-format, beroende på vilket system de genereras eller installeras i.

I många fall är en .crt-fil på en Apache-server ett PEM-certifikat omgivet av BEGIN/END CERTIFICATE-rubrikerna och redo att klistras in i ett konfigurationsblock. I Windows kan en .cer-fil vara antingen PEM eller DER, även om den vanligtvis hamnar någonstans mittemellan beroende på vilket verktyg som genererade den.

Det viktiga att förstå är att tillägget inte strikt definierar det interna formatet: en .cer-fil kan vara PEM-text eller DER-binär, och ett visningsprogram eller verktyg som OpenSSL avgör hur den ska läsas. I webbläsare och Windows-system öppnas certifikatvisaren genom att dubbelklicka , där du kan se utfärdare, ämne, giltighetsdatum, nyckelanvändning etc.

När du exporterar ett certifikat utan en privat nyckel från en webbläsare eller från Windows certifikatarkiv får du normalt en .cer-fil, som används för att validera signaturer, förtroendekedjor eller kryptera information , men aldrig för att signera å ägarens vägnar (för det behöver du den privata nyckeln, som är separat eller inuti en skyddad behållare).

CSR-, KEY-, CA- och mellanliggande filer: de andra filerna som medföljer certifikatet

När du bearbetar ett SSL-certifikat eller ett personligt certifikat ser du inte bara .pfx-, .p12- eller .cer-filer. Hela processen involverar även filer som .csr, .key och CA-certifikat (root- och intermediate-certifikat), vilka är lika viktiga för att allt ska fungera.

Certifikatsigneringsbegäran ( CSR) (.csr) är en fil som du vanligtvis genererar på servern där SSL-certifikatet ska installeras. Den innehåller den publika nyckeln, domännamnet, organisationen, landet och annan information som certifikatutfärdaren använder för att utfärda certifikatet. Den följer PKCS#10-standarden och är vanligtvis kodad i PEM-format så att du kan kopiera och klistra in den i leverantörens formulär.

Den privata nyckeln, eller KEY (.key) , är filen där den hemliga nyckeln som är associerad med certifikatet lagras. Den är vanligtvis i PEM-format, avgränsad av BEGIN PRIVATE KEY och END PRIVATE KEY. Det är en extremt känslig fil som inte bör delas eller laddas upp till offentliga databaser, och i många fall är den dessutom lösenordsskyddad.

Certifikatutfärdarens (CA) fil innehåller den offentliga nyckeln för den utfärdande eller mellanliggande enheten. Webbläsare och operativsystem levereras med en inbyggd lista över betrodda certifikatutfärdare, men ibland behöver du installera mellanliggande certifikat för att slutföra förtroendekedjan och låta klienter validera serverns certifikat utan fel.

Dessa mellanliggande certifikat kan levereras som PEM-filer (.pem, .crt, .cer) eller i en container som .p7b . I webbhotellskonfigurationer är det mycket vanligt att bli ombedd att ange CRT (domäncertifikat), KEY (privat nyckel) och CA- eller mellanliggande certifikatfiler för att SSL ska kunna installeras korrekt.

PKCS#7 / P7B: certifikatkedja utan privat nyckel

PKCS#7, vanligtvis representerat av tilläggen .p7b eller .p7c , är ett format utformat för att gruppera ett eller flera certifikat i en strukturerad behållare, utan att inkludera den privata nyckeln. Det används ofta för att distribuera certifikatkedjor (servercertifikat plus mellanliggande certifikat) i Windows- eller Java-miljöer (Tomcat, keystore, etc.).

En .p7b-fil är vanligtvis kodad i Base64 ASCII, ungefär som en PEM-fil, och definierades ursprungligen i RFC 2315 som en del av standarderna för offentlig nyckelkryptografi. Idag är dess efterföljare CMS (Cryptographic Message Syntax), men namnet PKCS#7 används fortfarande flitigt i SSL-certifikatvärlden.

Det här formatet är mycket användbart när du behöver installera hela förtroendekedjan på en server eller ett system som hanterar certifikat via ett arkiv (till exempel Java-nyckelarkivet). Vanligtvis levererar en SSL-leverantör servercertifikatet separat från en .p7b-fil som innehåller hela CA-kedjan, eller en enda .p7b-fil med allt.

Om du vill konvertera en .p7b-fil till PEM kan verktyg som OpenSSL extrahera certifikaten med ett enda kommando och spara dem till en eller flera textfiler. Du kan sedan separera BEGIN/END CERTIFICATE-blocken om du behöver ladda upp dem separat till din server.

Det är viktigt att notera att en PKCS#7-fil aldrig innehåller den privata nyckeln , så den kan inte i sig själv användas för att signera eller dekryptera: den tillhandahåller bara den offentliga delen av certifikatkedjan för att validera förtroende.

PKCS#12: Vad är egentligen .pfx och .p12?

PKCS#12-standarden definierar en lösenordsskyddad binärbehållare som kan innehålla publika certifikat, kompletta CA-kedjor och den tillhörande privata nyckeln. De vanligaste filtilläggen för detta format är .pfx och .p12, vilka är praktiskt taget likvärdiga.

Historiskt sett började PKCS#12 som ett format nära kopplat till Microsoft, men med tiden standardiserades det i RFC 7292 och används nu i alla typer av system, just för att det tillåter att certifikatet + den privata nyckelparet säkert transporteras från en dator till en annan.

I Windows-världen, när du exporterar ett certifikat med "privat nyckel" från användar- eller maskincertifikatarkivet, genererar guiden en .pfx-fil (eller .p12) som innehåller allt du behöver för att importera den till ett annat system: privat nyckel, certifikatinnehavare och vanligtvis den mellanliggande kedjan.

När du skapar eller exporterar en PKCS#12-fil kommer systemet att uppmana dig att ange ett lösenord . Detta lösenord kommer att krävas senare för att importera filen till en annan webbläsare, IIS, en e-postklient eller till och med ett annat operativsystem. På så sätt, om någon stjäl .pfx-filen, kommer de inte att kunna använda den utan att känna till lösenordet.

Verktyg som OpenSSL låter dig konvertera en .pfx- eller .p12-fil till PEM, så att du får en textfil där du enkelt kan hitta det privata nyckelblocket, servercertifikatet och de mellanliggande certifikaten, och kopiera dem där det är lämpligt (till exempel i en webbhotellspanel som bara accepterar CRT, KEY och CA separat).

Förnyelse, export och import av .pfx- och .p12-certifikat

Inom området personliga certifikat (till exempel de som utfärdas av FNMT eller andra myndigheter för att identifiera sig för administrationen) är sättet att säkerhetskopiera och förnya nära kopplat till användningen av .pfx- eller .p12-filer , som sparas på kryptografiska kort, USB- tokens eller direkt som skyddade filer på datorn.

Om ditt personliga certifikat ännu inte har gått ut tillåter många myndigheter dig att förnya det online : förnyelse aktiveras från registreringsplatsen (yrkesförening, företag, certifieringstjänstleverantör etc.) och du får en länk via e-post för att slutföra processen från din egen dator.

Om certifikatet dock redan har gått ut måste du vanligtvis personligen besöka samma registreringsplats med ditt kryptografiska kort eller din enhet där det utgångna certifikatet lagras, identifiera dig och begära en ny utfärdandehandling, som du återigen kan exportera i .pfx- eller .p12-format för att importera var du än behöver det.

I webbläsare som Edge eller Chrome går importprocessen via Windows certifikatarkiv . Från sekretess- och säkerhetsinställningarna kan du öppna certifikathanteraren, välja fliken Personligt och importera en .pfx- eller .p12-fil. Guiden kommer att be om containerlösenordet och erbjuda att markera nyckeln som exporterbar för framtida säkerhetskopior.

Om du istället för en .pfx-fil har en .cer-fil utan en privat nyckel (certifikatikon utan nyckel), kan den filen bara användas för att installera det offentliga certifikatet (det visas under "Andra personer"), men inte för att signera eller autentisera. I så fall kommer du inte att kunna återställa den privata nyckeln därifrån, och om du inte har en annan giltig kopia är det enda alternativet att begära ett nytt certifikat.

Hur dessa format används i SSL-certifikat för servern

I det dagliga arbetet med webbservrar, VPN , proxyservrar eller Java-applikationer beror de olika certifikatformaten som används på systemet och installationstypen. Att installera Apache på Linux är inte detsamma som att installera IIS på Windows eller Tomcat på Java.

I Unix/Linux-miljöer (Apache, Nginx, HAProxy, etc.) är det vanligt att arbeta med separata PEM-filer : en för den privata nyckeln (.key), en annan för servercertifikatet (.crt eller .cer), och ibland en annan med den mellanliggande CA-kedjan. Alla dessa refereras till i serverkonfigurationen för att upprätta TLS.

På Windows-plattformar (IIS, Remote Desktop Services, etc.) är det mycket vanligt att bli ombedd att ange en .pfx- eller .p12 -fil som innehåller certifikatet, den privata nyckeln och nyckelringen. Importguiden tar hand om att placera varje del i motsvarande arkiv, så att du inte behöver oroa dig för de interna detaljerna.

I Java-miljöer (Tomcat, applikationer med egen nyckelbutik) används JKS- eller PKCS#12 -typlager . I många fall importeras en .pfx-fil direkt, eller så används .p7b-certifikat för att konfigurera förtroendekedjan inom ett nyckellager, beroende på verktyg och Java-version.

När du köper ett SSL-certifikat från en tredjepartsleverantör kan du få olika kombinationer av filer: en CRT + CA-fil i PEM-format, en .p7b-fil som innehåller nyckelsträngen, eller till och med en förberedd .pfx-fil. Nyckeln är att identifiera var den privata nyckeln finns (om den medföljer dig och inte genereras av servern) och vilken fil som innehåller servercertifikatet och den mellanliggande nyckelsträngen.

I kontrollpaneler för värdtjänster blir du vanligtvis ombedd att fylla i fält för CRT, KEY och eventuellt CA eller mellanliggande certifikat. Om du bara har en .pfx-fil kan du konvertera den till PEM med OpenSSL och extrahera varje block därifrån, och noggrant kopiera från BEGIN till END för varje typ.

Konvertering mellan certifikatformat med OpenSSL

När du väl förstår vad varje fil är, är nästa logiska steg att veta hur man konverterar dem när servern eller applikationen kräver ett annat format än det som tillhandahålls av din internetleverantör eller certifikatutfärdare. Standardverktyget för detta är OpenSSL, tillgängligt på de flesta Linux-distributioner och även installeras på Windows.

Om du till exempel har ett certifikat i DER-format (.der, .cer) och behöver konvertera det till PEM, räcker det med ett enda kommando som tar den binära filen och kodar om den till Base64 med lämpliga rubriker. På samma sätt kan du konvertera ett PEM-certifikat till DER om ditt system bara accepterar binära filer.

Med hjälp av en PKCS#7-fil (.p7b) kan du använda OpenSSL för att extrahera certifikat i PEM-format med ett enkelt kommando som skriver ut de ingående certifikaten och sparar dem till en textfil. Därifrån kan du separera de enskilda BEGIN/END CERTIFICATE-blocken om du behöver separata filer.

När det gäller PKCS#12 (.pfx, .p12) låter OpenSSL dig konvertera containern till en PEM-fil som innehåller den privata nyckeln och alla certifikat. Under processen kommer du att bli ombedd att ange containerns lösenord och kan välja om du vill lämna den privata nyckeln krypterad eller i klartext i PEM-filen, beroende på dess avsedda användning.

Den här typen av konverteringar möjliggör scenarier som att ladda upp en .pfx-fil till en Linux-server, konvertera den till PEM och sedan separera CRT- och KEY-filer för att fylla i ett SSL-installationsformulär som inte direkt stöder PKCS#12-behållare.

Förutom direkta DER↔PEM-, PEM↔PKCS#7-, PKCS#7↔PKCS#12- och PKCS#12↔PEM-konverteringar kan samma verktyg generera CSR:er, hantera nycklar, inspektera certifikat och kontrollera utgångsdatum, vilket gör det till ett grundläggande verktyg i alla miljöer som arbetar med certifikat.

Typer av digitala certifikat och användningsområden

Utöver filformatet är det också bra att vara tydlig med vilken typ av certifikat det gäller beroende på deras användning eller vilken typ av enhet de representerar, eftersom det påverkar hur deras kopior, förnyelser och installationer hanteras.

På europeisk regelnivå (eIDAS-förordningen) görs en åtskillnad mellan "enkla" elektroniska certifikat och kvalificerade certifikat . De förra uppfyller grundläggande identifierings- och utfärdandekrav, medan kvalificerade certifikat kräver strängare identitetsverifieringsprocesser och mer rigorösa tekniska och organisatoriska villkor från leverantören. Ett tydligt exempel i Spanien skulle vara det elektroniska nationella identitetsdokumentet (DNIe).

Om vi ​​tittar på vem innehavaren är kan vi ha certifikat för individer, juridiska personer eller enheter utan juridisk personlighet . Var och en tjänar till att signera eller autentisera i olika sammanhang: personliga förfaranden, transaktioner för ett företags räkning respektive skatteförpliktelser.

I webbservrarnas värld är den mest kända certifikatfamiljen SSL/TLS-certifikat , vilka installeras på servrar för att kryptera kommunikationskanalen med användare. Inom denna kategori finns variationer som certifikat för en enda domän, jokertecken och flerdomänscertifikat (SAN), vilka skiljer sig åt i antalet domännamn de täcker och deras valideringsnivå.

Oavsett typ kan alla dessa certifikat lagras och distribueras i samma format: .cer, .crt, .pem, .p7b-filer eller .pfx/.p12-behållare, beroende på vilket system de ska användas i och vilken metod som väljs för att transportera eller säkerhetskopiera dem.

Nyttan med digitala certifikat är enorm: de säkerställer kommunikationens sekretess och äkthet , möjliggör juridiskt giltiga elektroniska signaturer, förenklar administrativa och kommersiella förfaranden och gör det möjligt för flera nätverkstjänster att fungera säkert utan att användaren behöver oroa sig för kryptografiska detaljer.

Vid det här laget är det tydligt att tillägg som .pfx, .p12, .cer eller .crt helt enkelt är olika sätt att paketera samma sak: ett X.509-certifikat, en privat nyckel och, i förekommande fall, en förtroendekedja, vilka, beroende på miljön, representeras som Base64-text, DER-binärfil eller PKCS-behållare för att underlätta installation och transport mellan system.