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

Om du har kommit hit och letat efter Skillnader mellan .pfx, .p12, .cer och .crtDu har 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, filändelser 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 enskilt fall.

Den goda nyheten är att även om namnen kan verka skrämmande, kan allt detta förklaras ganska enkelt om vi förstår att alla dessa filer inte är något mer än certifikat- och nyckelbehållare i olika format (text eller binärt) och utformade för olika system (Windows, Linux(Java, webbläsare, etc.). Vi kommer att titta på dem en efter en, lugnt, och relatera dem till varandra så att du vet exakt vad varje sak ä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 inget annat än ett elektroniskt dokument undertecknat av en certifieringsmyndighet (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 följande: offentlig nyckel- eller asymmetrisk kryptografiDet 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 offentlig nyckelinfrastruktur eller PKIvilket 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 standarden X.509, 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 ECDSARSA och ECDSA fungerar för både signering och kryptering, medan DSA fokuserar på signering och verifiering av digitala signaturer.

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

När vi pratar om tillägg som .cer, .crt, .pem, .der, .pfx, .p12 eller .p7bI verkligheten blandar vi två koncept: 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 normalt med DER (binär) eller dess textvariant PEM (DER konverterad till Base64 och omsluten med rubriker som BÖRJAN/SLUT). Därifrån har olika system och standarder definierats specifika behållare så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 namngivningskonventionEn .cer-fil eller en .crt-fil kan innehålla exakt samma sak, bara att den ena används mer i Windows och den andra i Unix/Linux-miljöer, för att ge ett exempel.

Inom denna allmänna grupp finns det några nyckelformat Dessa är viktiga att förstå tydligt, eftersom det är de 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 omkodad i Base64 och omgiven av textrubrikervilket låter dig öppna och kopiera den med valfri editor (Anteckningar, nano, vim, etc.).

En PEM känns igen eftersom dess innehåll avgränsas av linjer som —–BEGINCERTIFIKAT—– y —– SÄND CERTIFIKAT—– när det innehåller ett intyg, eller —–BEGIN PRIVAT NYCKEL—– y —–SLUT PRIVAT NYCKEL—– när den innehåller en privat nyckel. Allt däremellan är en Base64-sträng som representerar den ursprungliga binära datan.

I en enda PEM-fil kan du ha bara certifikatetCertifikatet plus den mellanliggande CA-kedjan, den privata nyckeln separat, eller till och med hela paketet (privat nyckel, servercertifikat, mellanliggande certifikat och rotcertifikat) kan tillhandahållas. Certifikatsigneringsförfrågningar tillhandahålls också i PEM. CSRvilka inte är något annat än PKCS#10-strukturer omkodade till text.

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 transportera kryptografiska data i ett bekvämt, läsligt och lättkopierat/klistrat format.

I praktiken filer med tillägg .pem, .crt, .cer eller .key I Unix/Linux-system är de 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 binärt kodningsformat av 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 vilken typ av certifikat eller privat nyckel som helstDen 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 stängd binär blob Utformad för direkt konsumtion av applikationer. Internt är informationen dock densamma: en PEM är inget annat än 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 vissa fall kommer en .crt-fil på en Apache-server att vara en certifierad i PEM omgiven 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 faller in i endera kategorin beroende på vilket verktyg som genererade den.

Det viktiga att förstå är att filändelsen 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 filen genom att dubbelklicka... certifikatvisaredä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 Windows certifikatarkiv får du normalt en .cer-fil, som används för validera signaturer, förtroendekedjor eller kryptera informationmen aldrig 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- eller CA-certifikat (rot och mellanprodukter), vilka är lika viktiga för att allt ska fungera.

Begäran om underskrift eller CSR (.csr) Det ä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 så att du kan kopiera och klistra in den i leverantörens formulär.

Den privata nyckeln eller NYCKEL (.key) Det här är filen där den hemliga nyckeln som är kopplad till 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.

Filen av CA eller auktoritetsintyg Den innehåller den offentliga nyckeln för den enhet som utfärdar eller förmedlar certifikatet. Webbläsare och OS De levereras med en standardlista över betrodda certifikatutfärdare, men ibland behöver du installera mellanliggande certifikat för att slutföra förtroendekedjan så att klienter kan validera serverns certifikat utan fel.

Dessa mellanliggande certifikat kan levereras som PEM-filer (.pem, .crt, .cer) eller i en behållare som t.ex. .p7bI webbhotellskonfigurationer är det mycket vanligt att man blir 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 representerad med tillägg .p7b eller .p7cDet ä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 vanligtvis för 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 i ett system som hanterar certifikat via ett arkiv (till exempel Java-nyckelarkivet). Vanligtvis levererar en SSL-leverantör servercertifikatet på ena sidan och en .p7b-fil med hela CA-kedjan på den andra, eller en enda .p7b-fil som innehåller 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 Den innehåller aldrig den privata nyckelnDärför är den i sig inte användbar för signering eller dekryptering: 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 offentliga certifikat, kompletta CA-kedjor och den privata nyckeln associerad. De vanligaste filändelserna 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 el tiempo Den standardiserades i RFC 7292 och används idag i alla typer av system, just för att den tillåter transportera certifikatet + det privata nyckelparet säkert från ett lag till ett annat.

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.

Under skapandet eller exporten av en PKCS#12-fil kommer systemet att be dig ange en lösenordsskyddDetta 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

När det gäller personliga certifikat (till exempel de som utfärdats av FNMT eller andra myndigheter för identifieringsändamål) är sättet att säkerhetskopiera och förnya dem nära kopplat till användningen av .pfx- eller .p12-filer, som färdas på kryptografiska kort, tokens USB eller direkt som skyddade filer på datorn.

Om ditt personliga certifikat ännu inte har gått ut tillåter många myndigheter Förnya det onlineFö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 normalt närvara personligen Gå till samma registreringspunkt med ditt kryptografiska kort eller din enhet där det utgångna certifikatet lagras, identifiera dig själv och begär en ny utfärdande, 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 ChromeImportprocessen går igenom Windows-certifikatarkivFrå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), är den filen bara användbar för installera det offentliga certifikatet (den visas under ”Andra personer”), men inte för signering eller autentisering. I så fall kommer du inte att kunna hämta 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, VPNOavsett om man använder proxyservrar eller Java-applikationer beror de olika certifikatformaten på systemet och installationstypen. Att konfigurera Apache på Linux är inte detsamma som att konfigurera IIS på Windows eller Tomcat på Java.

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

På Windows-plattformar (IIS, fjärrskrivbordstjänster etc.) är det mycket vanligt att bli ombedd att ange en .pfx eller .p12 som innehåller både certifikatet, den privata nyckeln och kedjan. 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) finns det arkiv av typen JKS eller PKCS#12I många fall importeras en .pfx-fil direkt, eller så används .p7b-certifikat för att konfigurera förtroendekedjan inom en nyckelbutik, beroende på verktyg och Java-version.

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

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 begär ett annat format än det som tillhandahålls av din internetleverantör eller certifikatutfärdare är standardverktyget för detta OpenSSL, tillgängligt i de flesta Linuxdistributioner och även installerabart på Windows.

Om du till exempel har ett certifikat i DER (.der, .cer) Och om du behöver konvertera den 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 en PEM till DER om ditt system bara accepterar binär.

Med en PKCS#7-fil (.p7b) kan du använda OpenSSL för att extrahera certifikaten i PEM-format med ett enkelt kommando som skriver ut de ingående certifikaten och sparar dem till en textfil. Därifrån separerar du de olika BEGIN/SLUT-CERTIFIKAT-blocken om du behöver individuella 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 separat CRT och nyckel att fylla i ett SSL-installationsformulär som inte direkt stöder PKCS#12-containrar.

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 typer av certifikat beroende på deras användning eller vilken typ av enhet de representerar, eftersom det påverkar hur deras säkerhetskopior, förnyelser och installationer hanteras.

På europeisk regelnivå (eIDAS-förordningen) görs en åtskillnad mellan "Enkla" elektroniska certifikat och kvalificerade certifikatDe förra uppfyller grundläggande krav på identifiering och utfärdande, medan de senare 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 ID-kortet (DNIe).

Om vi ​​tittar på vem innehavaren är kan vi ha intyg om fysisk person, juridisk person eller enhet utan juridisk personlighetVar och en används för att signera eller autentisera inom olika områden: personliga förfaranden, affärer för ett företags räkning respektive skatteskyldigheter.

I webbservrarnas värld är den mest kända certifikatfamiljen den för SSL/TLS-certifikatDessa certifikat installeras på servrar för att kryptera kommunikationskanalen med användarna. De inkluderar varianter som SAN-certifikat (single-domain), jokerteckenscertifikat och certifikat för flera domäner, vilka skiljer sig åt i antalet namn 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 sekretess och äkthet av kommunikation möjliggör de rättsligt 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 distribution. transport mellan system.