Forskjellene mellom .pfx, .p12, .cer og .crt forklart i detalj

Hvis du har kommet hit på jakt etter Forskjeller mellom .pfx, .p12, .cer og .crtDu har sannsynligvis allerede støtt på mer enn én merkelig fil når du har installert et digitalt sertifikat eller SSL på en server. Du er ikke alene: mellom akronymer, utvidelser og formater er det lett å bli forvirret og ikke vite hva hver fil gjør eller hvilken du trenger i hvert tilfelle.

Den gode nyheten er at selv om navnene kan virke skremmende, kan alt dette forklares ganske enkelt hvis vi forstår at alle disse filene ikke er noe mer enn sertifikat- og nøkkelbeholdere i forskjellige formater (tekst eller binært) og designet for forskjellige systemer (Windows, Linux(Java, nettlesere osv.). Vi skal se på dem én etter én, rolig, og relatere dem til hverandre, slik at du vet nøyaktig hva hver ting er, hva den er til for, og hvordan du bruker eller konverterer dem når det er nødvendig.

Hva er et digitalt sertifikat, og hvordan passer .pfx, .p12, .cer og .crt sammen?

Et digitalt sertifikat er ikke noe mer enn et elektronisk dokument signert av en sertifiseringsinstans (CA eller, i henhold til eIDAS-forskriften, en kvalifisert tjenesteleverandør) som knytter en identitet til en offentlig nøkkel. Denne identiteten kan være en person, et selskap, en webserver, et domene osv.

For å oppnå denne forbindelsen brukes følgende: offentlig nøkkel eller asymmetrisk kryptografiDet finnes et par nøkler: en offentlig nøkkel (som alle kan kjenne) og en privat nøkkel (som bare eieren skal ha). Det som er kryptert med den offentlige nøkkelen kan bare dekrypteres med den private nøkkelen, og omvendt, noe som muliggjør autentisering, kryptering og elektroniske signaturer.

Bak alle disse sertifikatene er det en offentlig nøkkelinfrastruktur eller PKIsom inkluderer sertifiseringsinstansen, registreringsmyndigheter, sertifikatlagre, sertifikattilbakekallingslister (CRL-er), og i mange miljøer en tidsstempelinstans (TSA) for å registrere når noe ble signert.

Den interne strukturen til de aller fleste generelle sertifikater følger standarden X.509, definert av ITU og beskrevet i detalj i RFC 5280. Denne standarden definerer felt som versjon, serienummer, signaturalgoritme, utsteder, gyldighetsperiode, emne, innehaverens offentlige nøkkel og mulige tilleggsutvidelser.

Når det gjelder algoritmer, bruker sertifikater vanligvis asymmetrisk kryptografi med RSA, DSA eller ECDSARSA og ECDSA brukes til både signering og kryptering, mens DSA fokuserer på signering og verifisering av digitale signaturer.

Interne formater og utvidelser: PEM, DER, CER, CRT og selskap

Når vi snakker om utvidelser som .cer, .crt, .pem, .der, .pfx, .p12 eller .p7bI virkeligheten blander vi to konsepter: sertifikatets kodingsformat (Base64-tekst eller binær) og funksjonen filen har (kun sertifikat, sertifikat + privat nøkkel, sertifikatkjede osv.).

På internt formatnivå er X.509-sertifikater representert med ASN.1 og er vanligvis kodet med DER (binær) eller dens tekstvariant PEM (DER konvertert til Base64 og pakket inn med overskrifter som BEGYNN/SLUTT). Derfra har ulike systemer og standarder definert spesifikke beholdere som for eksempel PKCS#7 (.p7b) eller PKCS#12 (.pfx, .p12).

Nøkkelen til å unngå forvirring er å huske at filtypen ofte bare er én navnekonvensjonEn .cer-fil eller en .crt-fil kan inneholde nøyaktig det samme, bare at den ene brukes mer i Windows og den andre i Unix/Linux-miljøer, for å gi et eksempel.

Innenfor denne generelle gruppen finnes det noen nøkkelformater Disse er viktige å forstå tydelig, fordi det er disse du vil støte på hele tiden når du jobber med SSL/TLS eller personlige sertifikater.

PEM-format: den «lesbare teksten» i sertifikater

PEM-formatet er det klart vanligste for SSL/TLS-sertifikater på servere som Apache eller Nginx og i de fleste sikkerhetsverktøy. En PEM-fil er rett og slett en DER omkodet i Base64 og omgitt av tekstoverskriftersom lar deg åpne og kopiere den med hvilken som helst editor (Notisblokk, nano, vim, osv.).

En PEM gjenkjennes fordi innholdet er avgrenset av linjer som —–BEGIN SERTIFICATE—– y —–END SERTIFIKAT—– når den inneholder et sertifikat, eller —–START PRIVAT NØKKEL—– y —–SLUTT PRIVAT NØKKEL—– når den inneholder en privat nøkkel. Alt i mellom er en Base64-streng som representerer de opprinnelige binære dataene.

I én enkelt PEM-fil kan du ha bare sertifikatetSertifikatet pluss den mellomliggende CA-kjeden, den private nøkkelen separat, eller til og med hele pakken (privat nøkkel, serversertifikat, mellomliggende sertifikater og rotsertifikat) kan leveres. Forespørsler om sertifikatsignering tilbys også i PEM. CSRsom ikke er noe mer enn PKCS#10-strukturer omkodet til tekst.

Dette formatet ble opprinnelig definert i RFC 1421–1424 som en del av prosjektet Privacy-enhanced Electronic Mail, som ikke ble populært for e-post, men etterlot seg et utmerket tekstformat for transportere kryptografiske data i et komfortabelt, lesbart og lett kopierbart/lime-format.

I praksis filer med utvidelser .pem, .crt, .cer eller .key I Unix/Linux-systemer er de vanligvis PEM-filer. Vanligvis inneholder .key den private nøkkelen, .crt eller .cer inneholder serversertifikatet, og noen ganger inneholder en ekstra PEM-fil den mellomliggende CA-kjeden.

DER-format: den rene og enkle binærfilen

DER (Distinguished Encoding Rules) er binært kodingsformat av ASN.1-strukturene som beskriver et X.509-sertifikat. Det er ikke tekst, så hvis du åpner det med et redigeringsprogram, vil du se merkelige tegn i stedet for den typiske Base64-strengen.

En DER-fil kan inneholde alle typer sertifikater eller privatnøklerDen identifiseres vanligvis med filtypene .der eller .cer, spesielt i Windows-miljøer eller på Java-plattformer. På Windows gjenkjennes en .der-fil direkte som en sertifikatfil og åpnes med det innebygde visningsprogrammet når du dobbeltklikker på den.

Den praktiske forskjellen med PEM er at mens PEM enkelt kan kopieres og sendes via e-post eller limes inn i nettskjemaer, er DER en lukket binær blob Utviklet for direkte forbruk av applikasjoner. Internt er imidlertid informasjonen den samme: en PEM er ikke noe mer enn en DER omkodet til Base64-tekst.

Verktøy som OpenSSL lar deg bytte fra DER til PEM og omvendt med én enkelt kommando, uten å endre det logiske innholdet i sertifikatet i det hele tatt, bare representasjonsformen.

.cer og .crt filtypene: samme hund med et annet halsbånd

Filtypene .cer og .crt brukes til å betegne filer som inneholder offentlige sertifikater, vanligvis i PEM- eller DER-format, avhengig av systemet de genereres eller installeres i.

I tilfeller vil en .crt-fil på en Apache-server være en sertifisert i PEM omgitt av BEGIN/END CERTIFICATE-overskriftene og klar til å limes inn i en konfigurasjonsblokk. I Windows kan en .cer-fil enten være PEM eller DER, selv om den vanligvis faller inn i begge kategoriene avhengig av verktøyet som genererte den.

Det viktige å forstå er at filtypen ikke definerer det interne formatet strengt: en .cer-fil kan være PEM-tekst eller DER-binær, og et visningsprogram eller verktøy som OpenSSL vil bestemme hvordan den skal leses. I nettlesere og Windows-systemer vil dobbeltklikking åpne... sertifikatviserhvor du kan se utsteder, emne, gyldighetsdatoer, nøkkelbruk osv.

Når du eksporterer et sertifikat uten en privat nøkkel fra en nettleser eller Windows-sertifikatlageret, vil du vanligvis få en .cer-fil, som brukes til validere signaturer, tillitskjeder eller kryptere informasjonmen aldri å signere på vegne av eieren (til det trenger du den private nøkkelen, som er separat eller inne i en beskyttet beholder).

CSR-, KEY-, CA- og mellomliggende filer: de andre filene som følger med sertifikatet

Når du behandler et SSL-sertifikat eller et personlig sertifikat, vil du ikke bare se .pfx-, .p12- eller .cer-filer. Hele prosessen involverer også filer som .csr-, .key- eller CA-sertifikater (rot og mellomprodukter), som er like viktige for at alt skal fungere.

Forespørselen om signatur eller CSR (.csr) Det er en fil du vanligvis genererer på serveren der SSL-sertifikatet skal installeres. Den inneholder den offentlige nøkkelen, domenenavnet, organisasjonen, landet og annen informasjon som sertifiseringsinstansen bruker til å utstede sertifikatet. Den følger PKCS#10-standarden og er vanligvis kodet i PEM, slik at du kan kopiere og lime den inn i leverandørens skjema.

Den private nøkkelen eller NØKKEL (.key) Dette er filen der den hemmelige nøkkelen som er knyttet til sertifikatet, er lagret. Den er vanligvis i PEM-format, avgrenset av BEGIN PRIVATE KEY og END PRIVATE KEY. Det er en ekstremt sensitiv fil som ikke bør deles eller lastes opp til offentlige arkiver, og i mange tilfeller er den i tillegg passordbeskyttet.

Filen av CA eller autorisasjonsbevis Den inneholder den offentlige nøkkelen til enheten som utsteder eller formidler sertifikatet. Nettlesere og OS De leveres med en standardliste over klarerte CA-er, men noen ganger må du installere mellomliggende sertifikater for å fullføre tillitskjeden slik at klienter kan validere serverens sertifikat uten feil.

Disse mellomliggende sertifikatene kan leveres som PEM-filer (.pem, .crt, .cer) eller i en beholder som f.eks. .p7bI hostingkonfigurasjoner er det veldig vanlig å bli bedt om CRT (domenesertifikat), KEY (privat nøkkel) og CA eller mellomliggende sertifikatfiler for å installere SSL riktig.

PKCS#7 / P7B: sertifikatkjede uten privat nøkkel

PKCS#7, vanligvis representert med utvidelser .p7b eller .p7cDet er et format som er utformet for å gruppere ett eller flere sertifikater i en strukturert beholder, uten å inkludere den private nøkkelen. Det brukes ofte til distribuere sertifikatkjeder (serversertifikat pluss mellomliggende sertifikater) i Windows- eller Java-miljøer (Tomcat, keystore osv.).

En .p7b-fil er vanligvis kodet i Base64 ASCII, på samme måte som en PEM-fil, og ble opprinnelig definert i RFC 2315 som en del av standardene for offentlig nøkkelkryptografi. I dag er etterfølgeren CMS (Cryptographic Message Syntax), men navnet PKCS#7 er fortsatt mye brukt i SSL-sertifikatverdenen.

Dette formatet er veldig nyttig når du trenger det installer hele tillitskjeden på en server eller i et system som administrerer sertifikater gjennom et lager (for eksempel Java-nøkkellageret). Vanligvis vil en SSL-leverandør levere serversertifikatet på den ene siden og en .p7b-fil med hele CA-kjeden på den andre, eller en enkelt .p7b-fil som inneholder alt.

Hvis du vil konvertere en .p7b-fil til PEM, lar verktøy som OpenSSL deg pakke ut sertifikatene med én kommando og lagre dem i én eller flere tekstfiler. Du kan deretter skille BEGIN/END CERTIFICATE-blokkene hvis du trenger å laste dem opp separat til serveren din.

Det er viktig å merke seg at en PKCS#7-fil Den inneholder aldri den private nøkkelenDerfor er den ikke i seg selv nyttig for signering eller dekryptering: den tilbyr bare den offentlige delen av sertifikatkjeden for å validere tillit.

PKCS#12: Hva er egentlig .pfx og .p12?

PKCS#12-standarden definerer en passordbeskyttet binærbeholder som kan inneholde offentlige sertifikater, komplette CA-kjeder og den private nøkkelen tilknyttet. De vanligste filtypene for dette formatet er .pfx og .p12, som praktisk talt er likeverdige.

Historisk sett startet PKCS#12 som et format nært knyttet til Microsoft, men med tiden Den ble standardisert i RFC 7292 og brukes i dag i alle typer systemer, nettopp fordi den tillater transporter sertifikatet + det private nøkkelparet sikkert fra ett lag til et annet.

I Windows-verdenen, når du eksporterer et "privatnøkkel"-sertifikat fra bruker- eller maskinens sertifikatlager, genererer veiviseren en .pfx-fil (eller .p12) som inneholder alt du trenger for å importere den til et annet system: privatnøkkel, sertifikatinnehaver og vanligvis mellomkjeden.

Under oppretting eller eksport av en PKCS#12-fil vil systemet be deg om å angi en passordbeskyttelseDette passordet vil bli nødvendig senere for å importere filen til en annen nettleser, IIS, en e-postklient eller til og med et annet operativsystem. På denne måten, hvis noen stjeler .pfx-filen, vil de ikke kunne bruke den uten å vite passordet.

Verktøy som OpenSSL lar deg konvertere en .pfx- eller .p12-fil til PEM, slik at du får en tekstfil der du enkelt kan finne den private nøkkelblokken, serversertifikatet og de mellomliggende sertifikatene, og kopiere dem der det er passende (for eksempel i et hostingpanel som bare godtar CRT, KEY og CA separat).

Fornyelse, eksport og import av .pfx- og .p12-sertifikater

Når det gjelder personlige sertifikater (for eksempel de som er utstedt av FNMT eller andre myndigheter for identifikasjonsformål), er måten å sikkerhetskopiere og fornye dem på nært knyttet til bruken av .pfx- eller .p12-filer, som reiser på kryptografiske kort, tokens USB eller direkte som beskyttede filer på datamaskinen.

Hvis ditt personlige sertifikat ikke er utløpt ennå, tillater mange myndigheter det Forny det på nettFornyelse aktiveres fra registreringsstedet (bransjeforening, selskap, sertifiseringstjenesteleverandør osv.), og du mottar en lenke på e-post for å fullføre prosessen fra din egen datamaskin.

Men hvis sertifikatet allerede er utløpt, må du vanligvis møte opp personlig Gå til det samme registreringspunktet med kryptografikortet eller enheten din der det utløpte sertifikatet er lagret, identifiser deg selv og be om en ny utstedelse, som du igjen kan eksportere i .pfx- eller .p12-format for å importere det der du trenger.

I nettlesere som Edge eller ChromeImportprosessen går gjennom Windows-sertifikatlagerFra personvern- og sikkerhetsinnstillingene kan du åpne sertifikatbehandleren, velge Personlig-fanen og importere en .pfx- eller .p12-fil. Veiviseren vil be om beholderpassordet og tilby å merke nøkkelen som eksporterbar for fremtidige sikkerhetskopier.

Hvis du i stedet for en .pfx-fil har en .cer-fil uten privat nøkkel (sertifikatikon uten nøkkel), er den filen bare nyttig for installer det offentlige sertifikatet (den vises under «Andre personer»), men ikke for signering eller autentisering. I så fall vil du ikke kunne hente den private nøkkelen derfra, og hvis du ikke har en annen gyldig kopi, vil det eneste alternativet være å be om et nytt sertifikat.

Hvordan disse formatene brukes i SSL-sertifikater for servere

I det daglige arbeidet med webservere, VPNEnten du bruker proxyer eller Java-applikasjoner, avhenger de ulike sertifikatformatene som brukes av systemet og installasjonstypen. Å sette opp Apache på Linux er ikke det samme som å sette opp IIS på Windows eller Tomcat på Java.

I Unix/Linux-miljøer (Apache, Nginx, HAProxy osv.) er det normalt å jobbe med PEM-filer separate filer: én for den private nøkkelen (.key), en annen for serversertifikatet (.crt eller .cer), og noen ganger enda en med den mellomliggende CA-strengen. Alle disse refereres til i serverkonfigurasjonen for å etablere TLS.

På Windows-plattformer (IIS, eksterne skrivebordstjenester osv.) er det veldig vanlig å bli bedt om en .pfx eller .p12 som inneholder både sertifikatet, den private nøkkelen og kjeden. Importveiviseren sørger for å plassere hver del i det tilhørende lageret, slik at du ikke trenger å bekymre deg for de interne detaljene.

I Java-miljøer (Tomcat, applikasjoner med eget nøkkellager) lagrer av typen JKS eller PKCS#12I mange tilfeller importeres en .pfx-fil direkte, eller .p7b-sertifikater brukes til å konfigurere tillitskjeden i et nøkkellager, avhengig av verktøyet og Java-versjonen.

Når du kjøper et SSL-sertifikat fra en tredjepartsleverandør, kan du motta forskjellige filkombinasjoner: en CRT + CA-fil i PEM-format, en .p7b-fil som inneholder strengen, eller til og med en ferdiglaget .pfx-fil. Nøkkelen er å identifisere riktig filtype. Hvor er den private nøkkelen? (hvis den følger med deg og ikke genereres av serveren) og hvilken fil som inneholder serversertifikatet og mellomkjeden.

I kontrollpaneler for hosting blir du vanligvis bedt om å fylle ut felt for CRT, KEY og eventuelt CA eller mellomliggende sertifikat. Hvis du bare har en .pfx-fil, kan du konvertere den til PEM ved hjelp av OpenSSL og trekke ut hver blokk derfra, og kopiere nøye fra BEGIN til END for hver type.

Konvertering mellom sertifikatformater med OpenSSL

Når du forstår hva hver fil er, er det neste logiske trinnet å vite hvordan konvertere dem Når serveren eller applikasjonen ber om et annet format enn det som er oppgitt av internettleverandøren eller sertifiseringsinstansen din, er standardverktøyet for dette OpenSSL, som er tilgjengelig i de fleste Linux-distribusjoner og også kan installeres på Windows.

Hvis du for eksempel har et sertifikat i DER (.der, .cer) Og hvis du trenger å konvertere den til PEM, vil en enkelt kommando som tar den binærfilen og omkoder den til Base64 med de riktige overskriftene være tilstrekkelig. På samme måte kan du transformere en PEM til DER hvis systemet ditt bare godtar binærfil.

Med en PKCS#7 (.p7b)-fil kan du bruke OpenSSL til å trekke ut sertifikatene i PEM-format med en enkel kommando som skriver ut de inneholdte sertifikatene og lagrer dem i en tekstfil. Derfra skiller du de forskjellige BEGIN/SLUTTSERTIFIKAT-blokkene hvis du trenger individuelle filer.

Når det gjelder PKCS#12 (.pfx, .p12), lar OpenSSL deg konvertere containeren til en PEM-fil som inneholder den private nøkkelen og alle sertifikater. Underveis vil du bli bedt om å oppgi containerpassordet, og du kan velge om du vil la den private nøkkelen være kryptert eller i ren tekst i PEM-filen, avhengig av den tiltenkte bruken.

Disse typene konverteringer muliggjør scenarioer som å laste opp en .pfx-fil til en Linux-server, konvertere den til PEM, og deretter separat CRT og KEY å fylle ut et SSL-installasjonsskjema som ikke direkte støtter PKCS#12-containere.

I tillegg til direkte DER↔PEM-, PEM↔PKCS#7-, PKCS#7↔PKCS#12- og PKCS#12↔PEM-konverteringer, kan det samme verktøyet generere CSR-er, administrere nøkler, inspisere sertifikater og sjekke utløpsdatoer, noe som gjør det til et grunnleggende verktøy i ethvert miljø som fungerer med sertifikater.

Typer digitale sertifikater og bruksområder

Utover filformatet er det også nyttig å være tydelig på typer sertifikater avhengig av bruken deres eller typen enhet de representerer, da det påvirker hvordan sikkerhetskopier, fornyelser og installasjoner administreres.

På europeisk regulatorisk nivå (eIDAS-forordningen) skilles det mellom "Enkle" elektroniske sertifikater og kvalifiserte sertifikaterFørstnevnte oppfyller grunnleggende krav til identifikasjon og utstedelse, mens sistnevnte krever strengere identitetsverifiseringsprosesser og strengere tekniske og organisatoriske betingelser fra leverandøren. Et tydelig eksempel i Spania ville være det elektroniske ID-kortet (DNIe).

Hvis vi ser på hvem innehaveren er, kan vi ha sertifikater fra fysisk person, juridisk person eller enhet uten juridisk personlighetHver av dem brukes til å signere eller autentisere på forskjellige områder: henholdsvis personlige prosedyrer, avtaler på vegne av et selskap eller skatteforpliktelser.

I webserververdenen er den mest kjente sertifikatfamilien den til SSL/TLS-sertifikaterDisse sertifikatene installeres på servere for å kryptere kommunikasjonskanalen med brukere. De inkluderer varianter som enkeltdomene-, jokertegn- og flerdomene-sertifikater (SAN), som varierer i antall navn de dekker og valideringsnivået.

Uansett type kan alle disse sertifikatene ende opp med å bli lagret og distribuert i samme formater: .cer, .crt, .pem, .p7b-filer eller .pfx/.p12-containere, avhengig av systemet der de skal brukes og metoden som velges for å transportere eller sikkerhetskopiere dem.

Nytten av digitale sertifikater er enorm: De sikrer konfidensialitet og autentisitet av kommunikasjon, tillater de juridisk gyldige elektroniske signaturer, forenkler administrative og kommersielle prosedyrer, og gjør det mulig for flere nettverkstjenester å fungere sikkert uten at brukeren trenger å bekymre seg for kryptografiske detaljer.

På dette tidspunktet er det tydelig at utvidelser som .pfx, .p12, .cer eller .crt rett og slett er forskjellige måter å pakke det samme på: et X.509-sertifikat, en privat nøkkel og, der det er aktuelt, en tillitskjede, som, avhengig av miljøet, er representert som Base64-tekst, DER-binær eller PKCS-containere for å forenkle installasjon og distribusjon. transport mellom systemer.