Detalyadong ipinaliwanag ang mga pagkakaiba sa pagitan ng .pfx, .p12, .cer at .crt

Kung narito ka para maghanap ng Mga pagkakaiba sa pagitan ng .pfx, .p12, .cer at .crtMalamang ay nakatagpo ka na ng higit sa isang kakaibang file habang nag-i-install ng digital certificate o SSL sa isang server. Hindi ka nag-iisa: sa pagitan ng mga acronym, extension, at format, madaling malito at hindi alam kung ano ang ginagawa ng bawat file o kung alin ang kailangan mo sa bawat kaso.

Ang magandang balita ay, bagama't maaaring mukhang nakakatakot ang mga pangalan, ang lahat ng ito ay maipapaliwanag nang simple kung mauunawaan natin na ang lahat ng mga file na ito ay wala nang iba pa sertipiko at mga lalagyan ng susi sa iba't ibang format (teksto o binary) at dinisenyo para sa iba't ibang sistema (Windows, Linux(Java, mga browser, atbp.). Susuriin natin ang mga ito isa-isa, nang mahinahon, at iuugnay ang mga ito sa isa't isa upang malaman mo nang eksakto kung ano ang bawat bagay, para saan ito, at kung paano gamitin o i-convert ang mga ito kung kinakailangan.

Ano ang isang digital na sertipiko at paano nagkakaugnay ang .pfx, .p12, .cer at .crt?

Ang isang digital na sertipiko ay wala nang iba pa kundi isang elektronikong dokumento na nilagdaan ng isang Awtoridad sa Sertipikasyon (CA o, ayon sa regulasyon ng eIDAS, isang Kwalipikadong Tagapagbigay ng Serbisyo) na nag-uugnay ng isang pagkakakilanlan sa isang pampublikong susi. Ang pagkakakilanlang iyon ay maaaring isang tao, isang kumpanya, isang web server, isang domain, atbp.

Upang makamit ang koneksyon na ito, ginagamit ang mga sumusunod: pampublikong susi o asimetrikong kriptograpiyaMayroong pares ng mga susi: isang pampublikong susi (na maaaring malaman ng sinuman) at isang pribadong susi (na dapat mayroon lamang ang may-ari). Ang naka-encrypt gamit ang pampublikong susi ay maaari lamang i-decrypt gamit ang pribadong susi, at kabaliktaran, na nagbibigay-daan para sa pagpapatotoo, pag-encrypt, at mga elektronikong lagda.

Sa likod ng lahat ng mga sertipikong ito ay mayroong pampublikong susi na imprastraktura o PKIna kinabibilangan ng awtoridad sa sertipikasyon, mga awtoridad sa pagpaparehistro, mga repositoryo ng sertipiko, mga listahan ng pagpapawalang-bisa ng sertipiko (CRL), at, sa maraming kapaligiran, isang awtoridad sa timestamp (TSA) upang itala kung kailan nilagdaan ang isang bagay.

Ang panloob na istruktura ng karamihan ng mga sertipikong pangkalahatan ay sumusunod sa pamantayan X.509, na tinukoy ng ITU at detalyadong inilarawan sa RFC 5280. Tinutukoy ng pamantayang ito ang mga patlang tulad ng bersyon, serial number, algorithm ng lagda, issuer, panahon ng bisa, paksa, pampublikong susi ng may-ari at mga posibleng karagdagang extension.

Tungkol sa mga algorithm, ang mga sertipiko ay karaniwang gumagamit ng asymmetric cryptography na may RSA, DSA o ECDSAAng RSA at ECDSA ay nagsisilbi para sa parehong paglagda at pag-encrypt, habang ang DSA ay nakatuon sa paglagda at pag-verify ng digital signature.

Mga panloob na format at extension: PEM, DER, CER, CRT at kumpanya

Kapag pinag-uusapan natin ang mga extension tulad ng .cer, .crt, .pem, .der, .pfx, .p12 o .p7bSa katotohanan, pinaghahalo natin ang dalawang konsepto: ang format ng pag-encode ng sertipiko (Base64 text o binary) at ang function na mayroon ang file (sertipiko lamang, sertipiko + pribadong key, kadena ng sertipiko, atbp.).

Sa antas ng panloob na format, ang mga sertipiko ng X.509 ay kinakatawan ng ASN.1 at karaniwang naka-encode gamit ang DER (binary) o ang textual variant nito na PEM (DER na kino-convert sa Base64 at binalot ng mga header tulad ng SIMULAN/WAKASMula roon, iba't ibang sistema at pamantayan ang nagtakda ng mga tiyak na lalagyan tulad ng PKCS#7 (.p7b) o PKCS#12 (.pfx, .p12).

Ang susi sa pag-iwas sa kalituhan ay ang tandaan na ang extension ng file ay kadalasang isa lamang kumbensyon sa pagpapangalanAng isang .cer file o .crt file ay maaaring maglaman ng eksaktong parehong bagay, isa lamang ang mas ginagamit sa Windows at ang isa naman sa mga kapaligirang Unix/Linux, bilang halimbawa.

Sa loob ng pangkalahatang grupong ito, may ilan mga pangunahing format Mahalagang maunawaan nang malinaw ang mga ito, dahil ang mga ito ang palagi mong makakasalubong kapag gumagamit ng SSL/TLS o mga personal na sertipiko.

PEM format: ang "nababasang teksto" ng mga sertipiko

Ang PEM format ang pinakakaraniwan para sa mga SSL/TLS certificate sa mga server tulad ng Apache o Nginx at sa karamihan ng mga security tool. Ang PEM file ay isa lamang... Na-recode ang DER sa Base64 at napapalibutan ng mga text headerna nagbibigay-daan sa iyong buksan at kopyahin ito gamit ang anumang editor (Notepad, nano, vim, atbp.).

Kinikilala ang isang PEM dahil ang nilalaman nito ay pinaghihiwalay ng mga linya tulad ng —–SERTIPIKO NG PAGSIMULA—– y —–SERTIPIKO NG PAGTAPOS—– kapag naglalaman ito ng sertipiko, o —–SIMULA PRIBADONG SUSI—– y —–WAKAS PRIBADONG SUSI—– kapag naglalaman ito ng pribadong susi. Ang lahat ng nasa pagitan ay isang string na Base64 na kumakatawan sa orihinal na binary data.

Sa isang PEM file, maaari kang magkaroon ng sertipiko lamangMaaaring ibigay ang sertipiko kasama ang intermediate CA chain, ang pribadong key nang hiwalay, o kahit ang buong pakete (private key, server certificate, intermediate certificate, at root certificate). Mayroon ding mga kahilingan para sa pagpirma ng sertipiko sa PEM. CSRna wala nang iba kundi mga istrukturang PKCS#10 na muling isinulat sa teksto.

Ang format na ito ay orihinal na binigyang kahulugan sa RFCs 1421-1424 bilang bahagi ng proyektong Privacy-enhanced Electronic Mail, na hindi naging popular para sa email, ngunit nag-iwan ng mahusay na format ng teksto para sa transportasyon ng datos na kriptograpiya sa isang komportable, nababasa, at madaling kopyahin/i-paste na format.

Sa pagsasagawa, ang mga file na may mga extension .pem, .crt, .cer o .key Sa mga sistemang Unix/Linux, kadalasan ang mga ito ay mga PEM file. Kadalasan, ang .key ay naglalaman ng private key, ang .crt o .cer ay naglalaman ng server certificate, at kung minsan ay may karagdagang PEM file na kinabibilangan ng intermediate CA chain.

Format ng DER: ang puro at simpleng binary

Ang DER (Mga Natatanging Panuntunan sa Pag-encode) ay ang format ng binary encoding ng mga istrukturang ASN.1 na naglalarawan ng isang sertipiko ng X.509. Hindi ito teksto, kaya kung bubuksan mo ito gamit ang isang editor, makakakita ka ng mga kakaibang karakter sa halip na ang karaniwang string ng Base64.

Ang isang DER file ay maaaring maglaman ng anumang uri ng sertipiko o pribadong susiKaraniwan itong nakikilala sa pamamagitan ng mga extension na .der o .cer, lalo na sa mga kapaligirang Windows o sa mga platform ng Java. Sa Windows, ang isang .der file ay direktang kinikilala bilang isang certificate file at bubukas kasama ang native viewer kapag na-double click.

Ang praktikal na pagkakaiba sa PEM ay, habang ang PEM ay madaling kopyahin at i-email o i-paste sa mga web form, ang DER ay isang saradong binary blob Dinisenyo para sa direktang pagkonsumo ng mga aplikasyon. Gayunpaman, sa loob, ang impormasyon ay pareho: ang isang PEM ay wala nang iba kundi isang DER na muling naka-encode sa Base64 na teksto.

Ang mga kagamitang tulad ng OpenSSL ay nagbibigay-daan sa iyong lumipat mula sa DER patungong PEM at vice versa gamit ang isang utos lamang, nang hindi binabago ang lohikal na nilalaman ng sertipiko, kundi ang anyo lamang ng representasyon nito.

Mga extension ng .cer at .crt: parehong aso na may ibang kwelyo

Ang mga extension na .cer at .crt ay ginagamit upang italaga mga file na naglalaman ng mga pampublikong sertipiko, kadalasan ay nasa PEM o DER na format, depende sa sistema kung saan binuo o ini-install ang mga ito.

Sa mga pagkakataon, ang isang .crt file sa isang Apache server ay magiging isang sertipikado sa PEM napapalibutan ng mga header na BEGIN/END CERTIFICATE at handa nang i-paste sa isang configuration block. Sa Windows, ang isang .cer file ay maaaring PEM o DER, bagama't kadalasan itong nabibilang sa alinmang kategorya depende sa tool na bumuo nito.

Ang mahalagang maunawaan ay hindi mahigpit na tinutukoy ng extension ang internal na format: ang isang .cer file ay maaaring PEM text o DER binary, at ang isang viewer o utility tulad ng OpenSSL ang magtatakda kung paano ito babasahin. Sa mga browser at Windows system, ang pag-double click ay magbubukas ng... tagatingin ng sertipikokung saan makikita mo ang nag-isyu, paksa, mga petsa ng bisa, paggamit ng susi, atbp.

Kapag nag-export ka ng certificate nang walang private key mula sa isang browser o sa Windows certificate store, karaniwan kang makakakuha ng .cer file, na ginagamit para sa patunayan ang mga lagda, mga kadena ng tiwala, o i-encrypt ang impormasyonngunit huwag kailanman pumirma sa ngalan ng may-ari (para diyan kailangan mo ang pribadong susi, na hiwalay o nasa loob ng isang protektadong lalagyan).

Mga CSR, KEY, CA at mga intermediate na file: ang iba pang mga file na kasama ng sertipiko

Kapag nagproseso ka ng SSL certificate o personal certificate, hindi lang .pfx, .p12, o .cer files ang makikita mo. Kasama rin sa buong proseso ang mga file tulad ng Mga sertipiko ng .csr, .key o CA (ugat at mga intermediate), na pantay na mahalaga para gumana ang lahat.

Ang paghingi ng lagda o CSR (.csr) Ito ay isang file na karaniwan mong binubuo sa server kung saan mai-install ang SSL certificate. Naglalaman ito ng public key, domain name, organisasyon, bansa, at iba pang impormasyon na gagamitin ng certificate authority para mag-isyu ng certificate. Sumusunod ito sa pamantayan ng PKCS#10 at karaniwang naka-encode sa PEM para makopya at ma-paste mo ito sa form ng provider.

Ang pribadong susi o SUSI (.susi) Ito ang file kung saan nakaimbak ang secret key na nauugnay sa sertipiko. Karaniwan itong nasa PEM format, na pinaghihiwalay ng BEGIN PRIVATE KEY at END PRIVATE KEY. Ito ay isang napakasensitibong file na hindi dapat ibahagi o i-upload sa mga pampublikong repository, at sa maraming pagkakataon, ito ay protektado rin ng password.

Ang file ng CA o sertipiko ng awtoridad Naglalaman ito ng pampublikong susi ng entidad na nag-iisyu o namamagitan sa sertipiko. Mga browser at OS May kasama silang default na listahan ng mga pinagkakatiwalaang CA, ngunit kung minsan kailangan mong mag-install ng mga intermediate certificate upang makumpleto ang chain of trust nang sa gayon ay ma-validate ng mga client ang certificate ng iyong server nang walang mga error.

Ang mga intermediate certificate na ito ay maaaring ibigay bilang mga PEM file (.pem, .crt, .cer) o sa loob ng isang container tulad ng .p7bSa mga configuration ng hosting, karaniwan nang hinihingan ang CRT (domain certificate), KEY (private key) at CA o intermediate certificate files para maayos na mai-install ang SSL.

PKCS#7 / P7B: kadena ng sertipiko na walang pribadong susi

PKCS#7, karaniwang kinakatawan ng mga extension .p7b o .p7cIto ay isang format na idinisenyo upang pangkatin ang isa o higit pang mga sertipiko sa isang nakabalangkas na lalagyan, nang hindi isinasama ang pribadong susi. Karaniwan itong ginagamit para sa ipamahagi ang mga kadena ng sertipiko (sertipiko ng server kasama ang mga nasa pagitan) sa mga kapaligirang Windows o Java (Tomcat, keystore, atbp.).

Ang isang .p7b file ay karaniwang naka-encode sa Base64 ASCII, katulad ng isang PEM file, at orihinal na tinukoy sa RFC 2315 bilang bahagi ng mga pamantayan ng public-key cryptography. Sa kasalukuyan, ang kahalili nito ay ang CMS (Cryptographic Message Syntax), ngunit ang pangalang PKCS#7 ay malawakang ginagamit pa rin sa mundo ng SSL certificate.

Ang format na ito ay lubhang kapaki-pakinabang kapag kailangan mo i-install ang buong kadena ng tiwala sa isang server o sa isang sistemang namamahala ng mga sertipiko sa pamamagitan ng isang tindahan (halimbawa, ang Java keystore). Kadalasan, ihahatid ng isang SSL provider ang sertipiko ng server sa isang banda at isang .p7b file na may buong CA chain sa kabilang banda, o isang .p7b file na naglalaman ng lahat.

Kung gusto mong i-convert ang isang .p7b file patungong PEM, ang mga tool tulad ng OpenSSL ay nagbibigay-daan sa iyong i-extract ang mga certificate gamit ang isang command at i-save ang mga ito sa isa o higit pang mga text file. Pagkatapos ay maaari mong paghiwalayin ang mga bloke ng BEGIN/END CERTIFICATE kung kailangan mong i-upload ang mga ito nang hiwalay sa iyong server.

Mahalagang tandaan na ang isang PKCS#7 file hindi kailanman naglalaman ng pribadong susiSamakatuwid, sa ganang sarili nito ay hindi ito kapaki-pakinabang para sa paglagda o pag-decrypt: nagbibigay lamang ito ng pampublikong bahagi ng kadena ng sertipiko upang mapatunayan ang tiwala.

PKCS#12: Ano nga ba ang .pfx at .p12?

Ang pamantayang PKCS#12 ay tumutukoy sa isang binary container na protektado ng password na maaaring magsama ng mga pampublikong sertipiko, kumpletong mga CA chain, at ang pribadong susi kaugnay. Ang mga pinakakaraniwang extension para sa format na ito ay .pfx at .p12, na halos magkapareho.

Sa kasaysayan, ang PKCS#12 ay nagsimula bilang isang format na malapit na nauugnay sa Microsoft, ngunit may oras Ito ay istandardisado sa RFC 7292 at ginagamit ngayon sa lahat ng uri ng sistema, dahil pinapayagan nito ang ligtas na ilipat ang pares ng sertipiko + pribadong susi mula sa isang koponan patungo sa isa pa.

Sa mundo ng Windows, kapag nag-export ka ng sertipiko ng "pribadong key" mula sa tindahan ng sertipiko ng gumagamit o makina, bubuo ang wizard ng isang .pfx (o .p12) na file na kinabibilangan ng lahat ng kailangan mo upang ma-import ito sa ibang sistema: pribadong key, may hawak ng sertipiko, at kadalasan ang intermediate chain.

Habang ginagawa o iniluluwas ang isang PKCS#12 file, hihilingin sa iyo ng system na tukuyin ang isang proteksyon ng passwordKakailanganin ang password na ito mamaya para ma-import ang file sa ibang browser, IIS, email client, o kahit sa ibang operating system. Sa ganitong paraan, kung may magnakaw ng .pfx file, hindi nila ito magagamit nang hindi nalalaman ang password na iyon.

Ang mga tool tulad ng OpenSSL ay nagbibigay-daan sa iyong i-convert ang isang .pfx o .p12 file sa PEM, kaya makakakuha ka ng text file kung saan madali mong mahahanap ang private key block, ang server certificate, at ang mga intermediate certificate, at makokopya ang mga ito kung saan naaangkop (halimbawa, sa isang hosting panel na tumatanggap lamang ng CRT, KEY, at CA nang hiwalay).

Pag-renew, pag-export at pag-import ng mga sertipiko ng .pfx at .p12

Sa larangan ng mga personal na sertipiko (halimbawa, ang mga inisyu ng FNMT o iba pang mga awtoridad para sa mga layunin ng pagkakakilanlan), ang paraan ng pag-backup at pag-renew ng mga ito ay malapit na nauugnay sa paggamit ng mga file na .pfx o .p12, na naglalakbay gamit ang mga cryptographic card, token USB o direkta bilang mga protektadong file sa computer.

Kung ang iyong personal na sertipiko ay hindi pa nag-e-expire, maraming awtoridad ang nagpapahintulot I-renew ito online: ang pag-renew ay pinagana mula sa punto ng pagpaparehistro (propesyonal na asosasyon, kumpanya, tagapagbigay ng serbisyo sa sertipikasyon, atbp.) at makakatanggap ka ng link sa pamamagitan ng email upang makumpleto ang proseso mula sa iyong sariling computer.

Gayunpaman, kung ang sertipiko ay nag-expire na, karaniwan mong kakailanganing dumalo nang personal Pumunta sa parehong registration point gamit ang iyong cryptographic card o device kung saan nakaimbak ang expired na certificate, tukuyin ang iyong sarili at humiling ng bagong issuance, na maaari mong i-export muli sa .pfx o .p12 na format upang i-import saan mo man ito kailanganin.

Sa mga browser tulad ng Gilid o ChromeAng proseso ng pag-angkat ay dumadaan sa Tindahan ng sertipiko ng WindowsMula sa mga setting ng privacy at seguridad, maaari mong buksan ang certificate manager, piliin ang tab na Personal, at mag-import ng .pfx o .p12 file. Hihingin ng wizard ang password ng container at mag-aalok na markahan ang key bilang maaaring i-export para sa mga backup sa hinaharap.

Kung sa halip na .pfx file ay mayroon kang .cer file na walang private key (icon ng certificate na walang key), ang file na iyon ay magagamit lamang para sa i-install ang pampublikong sertipiko (lumilitaw ito sa ilalim ng “Ibang tao”), ngunit hindi para sa pagpirma o pag-authenticate. Sa ganitong kaso, hindi mo makukuha ang private key mula roon, at kung wala kang ibang valid na kopya, ang tanging opsyon ay ang humiling ng bagong certificate.

Paano ginagamit ang mga format na ito sa mga SSL certificate ng server

Sa pang-araw-araw na gawain gamit ang mga web server, VPNGumagamit ka man ng mga proxy o Java application, ang iba't ibang format ng certificate na gagamitin ay nakadepende sa system at sa uri ng installation. Ang pag-set up ng Apache sa Linux ay hindi katulad ng pag-set up ng IIS sa Windows o Tomcat sa Java.

Sa mga kapaligirang Unix/Linux (Apache, Nginx, HAProxy, atbp.) normal lang na gumamit ng Mga file ng PEM magkakahiwalay na mga file: isa para sa private key (.key), isa pa para sa server certificate (.crt o .cer), at minsan ay isa pa na may intermediate CA string. Lahat ng ito ay tinutukoy sa configuration ng server upang maitatag ang TLS.

Sa mga platform ng Windows (IIS, mga serbisyo ng remote desktop, atbp.) karaniwan nang hinihingan ng .pfx o .p12 naglalaman ng parehong sertipiko, pribadong susi, at kadena. Inaasikaso ng import wizard ang paglalagay ng bawat piraso sa kaukulang imbakan nito, kaya hindi mo kailangang mag-alala tungkol sa mga panloob na detalye.

Sa mga kapaligirang Java (Tomcat, mga aplikasyon na may sariling keystore) mga tindahan ng uri JKS o PKCS#12Sa maraming pagkakataon, direktang ini-import ang isang .pfx file, o ginagamit ang mga .p7b certificate upang i-configure ang chain of trust sa loob ng isang keystore, depende sa tool at bersyon ng Java.

Kapag bumili ka ng SSL certificate mula sa isang third-party provider, maaari kang makatanggap ng iba't ibang kombinasyon ng file: isang CRT + CA file sa PEM format, isang .p7b file na naglalaman ng string, o kahit isang pre-prepared na .pfx file. Ang mahalaga ay matukoy ang tamang uri ng file. Nasaan ang pribadong susi? (kung kasama mo ito at hindi ginawa ng server) at kung anong file ang naglalaman ng server certificate at ng intermediate chain.

Sa mga hosting control panel, karaniwan kang hihilingin na punan ang mga field para sa CRT, KEY, at opsyonal, ang CA o intermediate certificate. Kung .pfx file lang ang mayroon ka, maaari mo itong i-convert sa PEM gamit ang OpenSSL at kunin ang bawat block mula roon, maingat na kinokopya mula BEGIN hanggang END ng bawat uri.

Pag-convert sa pagitan ng mga format ng sertipiko gamit ang OpenSSL

Kapag naunawaan mo na kung ano ang bawat file, ang susunod na lohikal na hakbang ay ang malaman paano i-convert ang mga ito Kapag humiling ang server o application ng format na naiiba sa ibinigay ng iyong ISP o CA, ang karaniwang tool para dito ay ang OpenSSL, na available sa karamihan ng mga distribusyon ng Linux at maaari ring i-install sa Windows.

Halimbawa, kung mayroon kang sertipiko sa DER (.der, .cer) At kung kailangan mo itong i-convert sa PEM, sapat na ang isang command na kukuha ng binary na iyon at muling i-encode ito sa Base64 gamit ang mga naaangkop na header. Gayundin, maaari mong i-convert ang isang PEM sa DER kung binary lang ang tinatanggap ng iyong system.

Gamit ang isang PKCS#7 (.p7b) na file, maaari mong gamitin ang OpenSSL para kunin ang mga sertipiko sa PEM format na may simpleng command na nagpi-print ng mga nakapaloob na certificate at nagse-save ng mga ito sa isang text file. Mula doon, paghihiwalayin mo ang iba't ibang BEGIN/END CERTIFICATE blocks kung kailangan mo ng mga indibidwal na file.

Sa kaso ng PKCS#12 (.pfx, .p12), pinapayagan ka ng OpenSSL na i-convert ang container sa isang PEM file na naglalaman ng private key at lahat ng certificate. Sa proseso, hihilingin sa iyo ang password ng container at maaari kang pumili kung iiwan mong naka-encrypt ang private key o nasa plain text sa loob ng PEM file, depende sa nilalayong paggamit nito.

Ang mga ganitong uri ng conversion ay nagbibigay-daan sa mga posibleng senaryo tulad ng pag-upload ng .pfx file sa isang Linux server, pag-convert nito sa PEM, at pagkatapos hiwalay na CRT at KEY para punan ang isang SSL installation form na hindi direktang sumusuporta sa mga PKCS#12 container.

Bukod sa direktang mga conversion na DER↔PEM, PEM↔PKCS#7, PKCS#7↔PKCS#12 at PKCS#12↔PEM, ang parehong utility ay maaaring bumuo ng mga CSR, pamahalaan ang mga key, siyasatin ang mga sertipiko at suriin ang mga petsa ng pag-expire, na ginagawa itong isang pangunahing tool sa anumang kapaligiran na gumagana sa mga sertipiko.

Mga uri ng digital na sertipiko at mga lugar ng paggamit

Bukod sa format ng file, makakatulong din na maging malinaw tungkol sa mga uri ng sertipiko depende sa kanilang paggamit o sa uri ng entity na kanilang kinakatawan, dahil nakakaimpluwensya ito kung paano pinamamahalaan ang kanilang mga backup, pag-renew, at pag-install.

Sa antas ng regulasyon sa Europa (eIDAS Regulation), may pagkakaiba sa pagitan ng "Simple" na mga elektronikong sertipiko at mga kwalipikadong sertipikoAng mga nauna ay nakakatugon sa mga pangunahing kinakailangan sa pagkakakilanlan at pag-isyu, habang ang huli ay humihingi ng mas mahigpit na proseso ng beripikasyon ng pagkakakilanlan at mas mahigpit na teknikal at organisasyonal na mga kondisyon mula sa tagapagbigay. Ang isang malinaw na halimbawa sa Espanya ay ang electronic ID card (DNIe).

Kung titingnan natin kung sino ang may hawak, maaari tayong magkaroon ng mga sertipiko ng natural na tao, legal na tao o entidad na walang legal na personalidadAng bawat isa ay ginagamit upang pumirma o magpatunay sa iba't ibang aspeto: mga personal na pamamaraan, mga pakikitungo sa ngalan ng isang kumpanya, o mga obligasyon sa buwis, ayon sa pagkakabanggit.

Sa mundo ng mga web server, ang pinakakilalang pamilya ng sertipiko ay ang Mga sertipiko ng SSL/TLSAng mga sertipikong ito ay naka-install sa mga server upang i-encrypt ang channel ng komunikasyon sa mga user. Kabilang dito ang mga variant tulad ng single-domain, wildcard, at multi-domain (SAN) na mga sertipiko, na magkakaiba sa bilang ng mga pangalang sakop ng mga ito at sa antas ng kanilang pagpapatunay.

Anuman ang uri, lahat ng mga sertipikong ito ay maaaring maiimbak at maipamahagi sa parehong mga format: .cer, .crt, .pem, .p7b file o .pfx/.p12 container, depende sa sistema kung saan gagamitin ang mga ito at ang paraan na pipiliin upang ilipat o i-back up ang mga ito.

Napakalaki ng kapakinabangan ng mga digital na sertipiko: Tinitiyak nila ang pagiging kompidensiyal at pagiging tunay Sa mga komunikasyon, pinapayagan nito ang mga legal na balidong elektronikong lagda, pinapasimple ang mga pamamaraang administratibo at komersyal, at ginagawang posible para sa maraming serbisyo ng network na gumana nang ligtas nang hindi kinakailangang mag-alala ang gumagamit tungkol sa mga detalyeng kriptograpiko.

Sa puntong ito, malinaw na ang mga extension tulad ng .pfx, .p12, .cer, o .crt ay magkaibang paraan lamang ng pag-iimpake ng iisang bagay: isang X.509 certificate, isang private key, at, kung naaangkop, isang chain of trust, na, depende sa environment, ay kinakatawan bilang Base64 text, DER binary, o PKCS containers upang mapadali ang pag-install at pag-deploy. transportasyon sa pagitan ng mga sistema.