Forskelle mellem .pfx, .p12, .cer og .crt forklaret i detaljer

Hvis du er kommet hertil og leder efter Forskelle mellem .pfx, .p12, .cer og .crtDu er sikkert allerede stødt på mere end én mærkelig fil, når du har installeret et digitalt certifikat eller SSL på en server. Du er ikke alene: mellem akronymer, filtypenavne og formater er det nemt at blive forvirret og ikke vide, hvad hver fil gør, eller hvilken du har brug for i hvert tilfælde.

Den gode nyhed er, at selvom navnene kan virke skræmmende, kan alt dette forklares ret simpelt, hvis vi forstår, at alle disse filer ikke er andet end certifikat- og nøglebeholdere i forskellige formater (tekst eller binær) og designet til forskellige systemer (Windows, Linux(Java, browsere osv.). Vi vil roligt se på dem én efter én og relatere dem til hinanden, så du ved præcis, hvad hver ting er, hvad den bruges til, og hvordan du bruger eller konverterer dem, når det er nødvendigt.

Hvad er et digitalt certifikat, og hvordan passer .pfx, .p12, .cer og .crt sammen?

Et digitalt certifikat er intet andet end et elektronisk dokument underskrevet af en certificeringsmyndighed (CA eller, i henhold til eIDAS-forordningen, en kvalificeret tjenesteudbyder), der forbinder en identitet med en offentlig nøgle. Denne identitet kan være en person, en virksomhed, en webserver, et domæne osv.

For at opnå denne forbindelse anvendes følgende: offentlig nøgle- eller asymmetrisk kryptografiDer er et par nøgler: en offentlig nøgle (som alle kan kende) og en privat nøgle (som kun ejeren må have). Det, der er krypteret med den offentlige nøgle, kan kun dekrypteres med den private nøgle, og omvendt, hvilket muliggør godkendelse, kryptering og elektroniske signaturer.

Bag alle disse certifikater gemmer sig en offentlig nøgleinfrastruktur eller PKIsom omfatter certificeringsmyndigheden, registreringsmyndigheder, certifikatlagre, certifikattilbagekaldelseslister (CRL'er) og i mange miljøer en tidsstempelmyndighed (TSA) til at registrere, hvornår noget blev underskrevet.

Den interne struktur i langt de fleste generelle certifikater følger standarden X.509, defineret af ITU og beskrevet detaljeret i RFC 5280. Denne standard definerer felter som version, serienummer, signaturalgoritme, udsteder, gyldighedsperiode, emne, indehaverens offentlige nøgle og mulige yderligere udvidelser.

Hvad angår algoritmer, bruger certifikater typisk asymmetrisk kryptografi med RSA, DSA eller ECDSARSA og ECDSA tjener til både signering og kryptering, mens DSA fokuserer på digital signatursignering og verifikation.

Interne formater og udvidelser: PEM, DER, CER, CRT og firma

Når vi taler om udvidelser som f.eks. .cer, .crt, .pem, .der, .pfx, .p12 eller .p7bI virkeligheden blander vi to koncepter: certifikatets kodningsformat (Base64-tekst eller binær) og filens funktion (kun certifikat, certifikat + privat nøgle, certifikatkæde osv.).

På det interne formatniveau er X.509-certifikater repræsenteret med ASN.1 og er normalt kodet med DER (binær) eller dens tekstvariant PEM (DER konverteret til Base64 og omsluttet med headere som BEGYNDELSE/SLUT). Derfra har forskellige systemer og standarder defineret specifikke beholdere såsom PKCS#7 (.p7b) eller PKCS#12 (.pfx, .p12).

Nøglen til at undgå forvirring er at huske, at filtypendelsen ofte kun er én navngivningskonventionEn .cer-fil eller en .crt-fil kan indeholde præcis det samme, blot bruges den ene mere i Windows og den anden i Unix/Linux-miljøer, for at give et eksempel.

Inden for denne generelle gruppe er der nogle nøgleformater Det er vigtigt at forstå disse tydeligt, fordi det er dem, du vil støde på hele tiden, når du arbejder med SSL/TLS eller personlige certifikater.

PEM-format: den "læsbare tekst" i certifikater

PEM-formatet er langt det mest almindelige til SSL/TLS-certifikater på servere som Apache eller Nginx og i de fleste sikkerhedsværktøjer. En PEM-fil er simpelthen en DER omkodet i Base64 og omgivet af tekstoverskrifterhvilket giver dig mulighed for at åbne og kopiere den med enhver editor (Notepad, nano, vim osv.).

En PEM genkendes, fordi dens indhold er afgrænset af linjer som —–BEGIN CERTIFIKAT—– y —–END CERTIFIKAT—– når den indeholder et certifikat, eller —–START PRIVAT NØGLE—– y —–SLUT PRIVAT NØGLE—– når den indeholder en privat nøgle. Alt derimellem er en Base64-streng, der repræsenterer de originale binære data.

I en enkelt PEM-fil kan du have kun certifikatetCertifikatet plus den mellemliggende CA-kæde, den private nøgle separat eller endda hele pakken (privat nøgle, servercertifikat, mellemliggende certifikater og rodcertifikat) kan leveres. Anmodninger om certifikatsignering leveres også i PEM. CSRsom ikke er andet end PKCS#10-strukturer omkodet til tekst.

Dette format blev oprindeligt defineret i RFC'er 1421-1424 som en del af projektet Privacy-enhanced Electronic Mail, som ikke blev populært for e-mail, men efterlod et fremragende tekstformat til transport af kryptografiske data i et behageligt, læseligt og let at kopiere/indsætte format.

I praksis filer med filtypenavne .pem, .crt, .cer eller .key I Unix/Linux-systemer er de normalt PEM-filer. Typisk indeholder .key den private nøgle, .crt eller .cer indeholder servercertifikatet, og nogle gange indeholder en ekstra PEM-fil den mellemliggende CA-kæde.

DER-format: den rene og simple binære fil

DER (Distinguished Encoding Rules) er binært kodningsformat af ASN.1-strukturerne, der beskriver et X.509-certifikat. Det er ikke tekst, så hvis du åbner det med en editor, vil du se mærkelige tegn i stedet for den typiske Base64-streng.

En DER-fil kan indeholde enhver type certifikat eller privat nøgleDen identificeres typisk med filtypenavnene .der eller .cer, især i Windows-miljøer eller på Java-platforme. På Windows genkendes en .der-fil direkte som en certifikatfil og åbnes med den indbyggede fremviser, når der dobbeltklikkes på den.

Den praktiske forskel med PEM er, at mens PEM nemt kan kopieres og sendes via e-mail eller indsættes i webformularer, er DER en lukket binær blob Designet til direkte forbrug af applikationer. Internt er informationen dog den samme: en PEM er intet andet end en DER, der er omkodet til Base64-tekst.

Værktøjer som OpenSSL giver dig mulighed for at skifte fra DER til PEM og omvendt med en enkelt kommando, uden at ændre certifikatets logiske indhold overhovedet, kun dets repræsentationsform.

.cer og .crt filtypenavne: samme hund med et forskelligt halsbånd

Filtypenavnene .cer og .crt bruges til at betegne filer, der indeholder offentlige certifikater, normalt i PEM- eller DER-format, afhængigt af det system, hvori de genereres eller installeres.

I tilfælde vil en .crt-fil på en Apache-server være en certificeret i PEM omgivet af BEGIN/END CERTIFICATE-headerne og klar til at blive indsat i en konfigurationsblok. I Windows kan en .cer-fil enten være PEM eller DER, selvom den typisk falder ind under begge kategorier afhængigt af det værktøj, der genererede den.

Det vigtige at forstå er, at filtypen ikke nøje definerer det interne format: en .cer-fil kan være PEM-tekst eller DER-binær, og en fremviser eller et værktøj som OpenSSL bestemmer, hvordan den skal læses. I browsere og Windows-systemer åbnes filen ved at dobbeltklikke... certifikatfremviserhvor du kan se udsteder, emne, gyldighedsdatoer, nøglebrug osv.

Når du eksporterer et certifikat uden en privat nøgle fra en browser eller Windows-certifikatlageret, får du normalt en .cer-fil, som bruges til validere signaturer, tillidskæder eller kryptere oplysningermen aldrig at underskrive på vegne af ejeren (til det skal du bruge den private nøgle, som er separat eller inde i en beskyttet beholder).

CSR-, KEY-, CA- og mellemliggende filer: de andre filer, der følger med certifikatet

Når du behandler et SSL-certifikat eller et personligt certifikat, vil du ikke kun se .pfx-, .p12- eller .cer-filer. Hele processen involverer også filer som f.eks. .csr-, .key- eller CA-certifikater (rod og mellemprodukter), som er lige vigtige for at alt kan fungere.

Anmodning om underskrift eller CSR (.csr) Det er en fil, du typisk genererer på den server, hvor SSL-certifikatet skal installeres. Den indeholder den offentlige nøgle, domænenavnet, organisationen, landet og andre oplysninger, som certifikatmyndigheden bruger til at udstede certifikatet. Den følger PKCS#10-standarden og er normalt kodet i PEM, så du kan kopiere og indsætte den i udbyderens formular.

Den private nøgle eller NØGLE (.key) Dette er filen, hvor den hemmelige nøgle, der er knyttet til certifikatet, er gemt. Den er normalt i PEM-format, afgrænset af BEGIN PRIVATE KEY og END PRIVATE KEY. Det er en ekstremt følsom fil, der ikke bør deles eller uploades til offentlige arkiver, og i mange tilfælde er den desuden adgangskodebeskyttet.

Filen af CA eller autorisationscertifikat Den indeholder den offentlige nøgle for den enhed, der udsteder eller formidler certifikatet. Browsere og OS De leveres med en standardliste over betroede CA'er, men nogle gange skal du installere mellemliggende certifikater for at fuldføre tillidskæden, så klienter kan validere din servers certifikat uden fejl.

Disse mellemliggende certifikater kan leveres som PEM-filer (.pem, .crt, .cer) eller i en container som f.eks. .p7bI hostingkonfigurationer er det meget almindeligt at blive bedt om CRT (domænecertifikat), KEY (privat nøgle) og CA eller mellemliggende certifikatfiler for at installere SSL korrekt.

PKCS#7 / P7B: certifikatkæde uden privat nøgle

PKCS#7, normalt repræsenteret med udvidelser .p7b eller .p7cDet er et format designet til at gruppere et eller flere certifikater i en struktureret container uden at inkludere den private nøgle. Det bruges almindeligvis til distribuer certifikatkæder (servercertifikat plus mellemliggende certifikater) i Windows- eller Java-miljøer (Tomcat, keystore osv.).

En .p7b-fil er typisk kodet i Base64 ASCII, svarende til en PEM-fil, og blev oprindeligt defineret i RFC 2315 som en del af standarderne for offentlig nøglekryptografi. I dag er dens efterfølger CMS (Cryptographic Message Syntax), men navnet PKCS#7 bruges stadig meget i SSL-certifikatverdenen.

Dette format er meget nyttigt, når du har brug for det installer hele tillidskæden på en server eller i et system, der administrerer certifikater via et lager (f.eks. Java-nøglelageret). Typisk leverer en SSL-udbyder servercertifikatet på den ene side og en .p7b-fil med hele CA-kæden på den anden side, eller en enkelt .p7b-fil, der indeholder alt.

Hvis du vil konvertere en .p7b-fil til PEM, giver værktøjer som OpenSSL dig mulighed for at udtrække certifikaterne med en enkelt kommando og gemme dem i en eller flere tekstfiler. Du kan derefter adskille BEGIN/END CERTIFICATE-blokkene, hvis du har brug for at uploade dem separat til din server.

Det er vigtigt at bemærke, at en PKCS#7-fil Den indeholder aldrig den private nøgleDerfor er det i sig selv ikke nyttigt til signering eller dekryptering: det leverer kun den offentlige del af certifikatkæden til at validere tillid.

PKCS#12: Hvad er .pfx og .p12 præcist?

PKCS#12-standarden definerer en adgangskodebeskyttet binær container, der kan indeholde offentlige certifikater, komplette CA-kæder og den private nøgle tilknyttet. De mest almindelige filtypenavne for dette format er .pfx og .p12, som praktisk talt er ækvivalente.

Historisk set startede PKCS#12 som et format tæt knyttet til Microsoft, men med El tiempo Det blev standardiseret i RFC 7292 og bruges i dag i alle typer systemer, netop fordi det tillader transporter certifikatet + det private nøglepar sikkert fra et hold til et andet.

I Windows-verdenen genererer guiden en .pfx-fil (eller .p12-fil), når du eksporterer et "privat nøgle"-certifikat fra bruger- eller maskinens certifikatlager, der indeholder alt, hvad du behøver for at importere det til et andet system: privat nøgle, certifikatindehaver og normalt den mellemliggende kæde.

Under oprettelsen eller eksporten af ​​en PKCS#12-fil vil systemet bede dig om at angive en adgangskodebeskyttelseDenne adgangskode skal senere bruges til at importere filen til en anden browser, IIS, en e-mailklient eller endda et andet operativsystem. På denne måde kan nogen, hvis de stjæler .pfx-filen, ikke bruge den uden at kende adgangskoden.

Værktøjer som OpenSSL giver dig mulighed for at konvertere en .pfx- eller .p12-fil til PEM, så du får en tekstfil, hvor du nemt kan finde den private nøgleblok, servercertifikatet og de mellemliggende certifikater og kopiere dem, hvor det er relevant (for eksempel i et hostingpanel, der kun accepterer CRT, KEY og CA separat).

Fornyelse, eksport og import af .pfx- og .p12-certifikater

Inden for personlige certifikater (f.eks. dem udstedt af FNMT eller andre myndigheder til identifikationsformål) er måden at sikkerhedskopiere og forny dem på tæt forbundet med brugen af .pfx- eller .p12-filer, som rejser på kryptografiske kort, tokens USB eller direkte som beskyttede filer på computeren.

Hvis dit personlige certifikat endnu ikke er udløbet, tillader mange myndigheder det Forny det onlineFornyelse aktiveres fra registreringsstedet (faglig forening, virksomhed, certificeringsudbyder osv.), og du modtager et link via e-mail for at fuldføre processen fra din egen computer.

Hvis certifikatet dog allerede er udløbet, skal du normalt deltage personligt Gå til det samme registreringssted med dit kryptografiske kort eller din enhed, hvor det udløbne certifikat er gemt, identificer dig selv og anmod om en ny udstedelse, som du igen kan eksportere i .pfx- eller .p12-format for at importere det, hvor du har brug for det.

I browsere som f.eks. Edge eller ChromeImportprocessen går gennem Windows-certifikatlagerFra indstillingerne for beskyttelse af personlige oplysninger og sikkerhed kan du åbne certifikatadministratoren, vælge fanen Personlig og importere en .pfx- eller .p12-fil. Guiden vil bede om containerens adgangskode og tilbyde at markere nøglen som eksporterbar til fremtidige sikkerhedskopier.

Hvis du i stedet for en .pfx-fil har en .cer-fil uden en privat nøgle (certifikatikon uden en nøgle), er den fil kun nyttig til installer det offentlige certifikat (den vises under "Andre personer"), men ikke til underskrift eller godkendelse. I så fald vil du ikke kunne hente den private nøgle derfra, og hvis du ikke har en anden gyldig kopi, vil den eneste mulighed være at anmode om et nyt certifikat.

Hvordan disse formater bruges i server-SSL-certifikater

I det daglige arbejde med webservere, VPNUanset om der bruges proxyer eller Java-applikationer, afhænger de forskellige certifikatformater af systemet og installationstypen. Opsætning af Apache på Linux er ikke det samme som opsætning af IIS på Windows eller Tomcat på Java.

I Unix/Linux-miljøer (Apache, Nginx, HAProxy osv.) er det normalt at arbejde med PEM-filer separate filer: en til den private nøgle (.key), en anden til servercertifikatet (.crt eller .cer), og nogle gange endnu en med den mellemliggende CA-streng. Alle disse refereres til i serverkonfigurationen for at etablere TLS.

På Windows-platforme (IIS, fjernskrivebordstjenester osv.) er det meget almindeligt at blive bedt om en .pfx eller .p12 indeholder både certifikatet, den private nøgle og kæden. Importguiden sørger for at placere hvert element i dets tilhørende lager, så du ikke behøver at bekymre dig om de interne detaljer.

I Java-miljøer (Tomcat, applikationer med deres eget nøglelager) lagre af typen JKS eller PKCS#12I mange tilfælde importeres en .pfx-fil direkte, eller .p7b-certifikater bruges til at konfigurere tillidskæden i et nøglelager, afhængigt af værktøjet og Java-versionen.

Når du køber et SSL-certifikat fra en tredjepartsudbyder, kan du modtage forskellige filkombinationer: en CRT + CA-fil i PEM-format, en .p7b-fil, der indeholder strengen, eller endda en præforberedt .pfx-fil. Nøglen er at identificere den korrekte filtype. Hvor er den private nøgle? (hvis den følger med dig og ikke genereres af serveren) og hvilken fil der indeholder servercertifikatet og den mellemliggende kæde.

I kontrolpaneler til hosting vil du typisk blive bedt om at udfylde felter for CRT, KEY og eventuelt CA eller mellemliggende certifikat. Hvis du kun har en .pfx-fil, kan du konvertere den til PEM ved hjælp af OpenSSL og udtrække hver blok derfra, og omhyggeligt kopiere fra BEGIN til END for hver type.

Konvertering mellem certifikatformater med OpenSSL

Når du forstår, hvad hver fil er, er det næste logiske skridt at vide det hvordan man konverterer dem Når serveren eller applikationen anmoder om et andet format end det, som din internetudbyder eller CA leverer, er standardværktøjet til dette OpenSSL, som er tilgængeligt i de fleste Linux-distributioner og også kan installeres på Windows.

Hvis du for eksempel har et certifikat i DER (.der, .cer) Og hvis du har brug for at konvertere den til PEM, vil en enkelt kommando, der tager den binære fil og omkoder den til Base64 med de relevante headere, være tilstrækkelig. På samme måde kan du transformere en PEM til DER, hvis dit system kun accepterer binær fil.

Med en PKCS#7 (.p7b) fil kan du bruge OpenSSL til at udtræk certifikaterne i PEM-format med en simpel kommando, der udskriver de indeholdte certifikater og gemmer dem i en tekstfil. Derfra adskiller du de forskellige BEGIN/SLUT CERTIFICATE-blokke, hvis du har brug for individuelle filer.

I tilfælde af PKCS#12 (.pfx, .p12) giver OpenSSL dig mulighed for at konvertere containeren til en PEM-fil, der indeholder den private nøgle og alle certifikater. Under processen vil du blive bedt om containerens adgangskode, og du kan vælge, om du vil lade den private nøgle være krypteret eller i almindelig tekst i PEM-filen, afhængigt af dens tilsigtede anvendelse.

Disse typer konverteringer muliggør scenarier som f.eks. at uploade en .pfx-fil til en Linux-server, konvertere den til PEM og derefter separat CRT og NØGLE at udfylde en SSL-installationsformular, der ikke direkte understøtter PKCS#12-containere.

Ud over direkte DER↔PEM, PEM↔PKCS#7, PKCS#7↔PKCS#12 og PKCS#12↔PEM konverteringer, kan det samme værktøj generere CSR'er, administrere nøgler, inspicere certifikater og kontrollere udløbsdatoer, hvilket gør det til et grundlæggende værktøj i ethvert miljø, der arbejder med certifikater.

Typer af digitale certifikater og anvendelsesområder

Ud over filformatet er det også nyttigt at være klar over typer af certifikater afhængigt af deres anvendelse eller den type enhed, de repræsenterer, da det påvirker, hvordan deres sikkerhedskopier, fornyelser og installationer administreres.

På europæisk reguleringsniveau (eIDAS-forordningen) skelnes der mellem "Enkle" elektroniske certifikater og kvalificerede certifikaterFørstnævnte opfylder grundlæggende identifikations- og udstedelseskrav, mens sidstnævnte kræver strengere identitetsbekræftelsesprocesser og mere stringente tekniske og organisatoriske betingelser fra udbyderen. Et klart eksempel i Spanien ville være det elektroniske ID-kort (DNIe).

Hvis vi ser på, hvem indehaveren er, kan vi have certifikater for fysisk person, juridisk person eller enhed uden juridisk statusHver enkelt bruges til at underskrive eller godkende på forskellige områder: henholdsvis personlige procedurer, handler på vegne af en virksomhed eller skatteforpligtelser.

I webserververdenen er den mest kendte certifikatfamilie den af SSL/TLS certifikaterDisse certifikater installeres på servere for at kryptere kommunikationskanalen med brugerne. De omfatter varianter såsom enkeltdomæne-, wildcard- og multidomæne- (SAN) certifikater, som adskiller sig i antallet af navne, de dækker, og deres valideringsniveau.

Uanset typen kan alle disse certifikater ende med at blive gemt og distribueret i de samme formater: .cer, .crt, .pem, .p7b-filer eller .pfx/.p12-containere, afhængigt af det system, hvor de skal bruges, og den valgte metode til at transportere eller sikkerhedskopiere dem.

Nytten af ​​digitale certifikater er enorm: De sikrer fortrolighed og ægthed af kommunikation, de tillader juridisk gyldige elektroniske signaturer, forenkler administrative og kommercielle procedurer og gør det muligt for flere netværkstjenester at fungere sikkert uden at brugeren behøver at bekymre sig om kryptografiske detaljer.

På nuværende tidspunkt er det tydeligt, at udvidelser som .pfx, .p12, .cer eller .crt blot er forskellige måder at pakke den samme ting på: et X.509-certifikat, en privat nøgle og, hvor det er relevant, en tillidskæde, som, afhængigt af miljøet, repræsenteres som Base64-tekst, DER-binær eller PKCS-containere for at lette installation og implementering. transport mellem systemer.