PKCS12, PEM ali DER: kaj VPN-klient zares potrebuje

V razpravah o potrdilih krožita dve trditvi. Prva je, da je .p12 močna možnost in .pem ohlapna; druga, da mora biti besedilna datoteka varna za pošiljanje, ker jo lahko preberete. Nobena ne zdrži minute pregleda.

PKCS12, PEM in DER opisujejo, kako se potrditveni objekti pakirajo in kodirajo. Ne odločajo, kdo je druga stran, ali je izdajatelj zaupanja vreden ali ali datoteka potrebuje geslo.

Kaj klient sprejme, je vprašanje združljivosti. Kaj datoteka vsebuje, je vprašanje identitete. Ločite to dvoje in večina napak pri uvozu ne bo več skrivnostnih.

Trije vsebniki, en model predmetov

Začnite s tem, kar res imate. Potrdilo je podpisana izjava o javnem ključu. Zasebni ključ je ločeno gradivo, ki dokazuje, da ta ključ nadzorujete. Veriga je množica izdajateljev, ki vaše potrdilo povezujejo s korenom, ki mu klient zaupa. Vsi trije obstajajo ne glede na pakiranje.

Datoteka PKCS12, običajno .p12 ali .pfx, je vsebnik, opredeljen v RFC 7292, ki lahko nosi zasebni ključ, eno ali več potrdil in verigo v enem bloku, zaščitenem z geslom, z vzdevkom, ki poimenuje identiteto. Datoteka PEM je besedilni okvir, opredeljen v RFC 7468: telo base64 med vrsticama BEGIN in END, in ena datoteka lahko vsebuje več blokov zaporedoma. DER je binarno kodiranje istih struktur ASN.1, telo PEM pa je dobesedno DER, ovit v base64.

Zadnji stavek si velja zapomniti. Pretvorba PEM v DER prepiše okvir, ne vsebine, povratna pretvorba pa vrne izvirne bajte.

Kodiranje ni šifriranje

base64 je transportna abeceda. Ničesar ne skriva in vsak lahko blok PEM dekodira v lupini. Datoteka DER je binarna in enako javna. Nobena lastnost ni zaščita in nobena ne pomeni, da geslo obstaja.

Prava zaščita je v ključnem gradivu. Paket PKCS12 lahko šifrira svojo vsebino s ključem, izpeljanim iz gesla. Zasebni ključ PEM je mogoče šifrirati s starim blokom glave ali ga hraniti v PKCS#8 EncryptedPrivateKeyInfo. Potrdilo samo po sebi ne hrani ničesar tajnega, zato izvoz, ki je dal samo potrdilo, klienta pusti brez možnosti preverjanja pristnosti, v kateri koli obliki ga zavijete.

Končnica je namig, ne pogodba. Datoteke, ki se končajo z .cer in .crt, se pojavljajo v obeh kodiranjih, naprave pa dovolj pogosto izvažajo potrdila DER pod imeni .pem, da ugibanje po končnici stane popoldne. Berite prve bajte: datoteka PEM se odpre z vrstico BEGIN, medtem ko se DER začne z 0x30, ker je zunanja struktura SEQUENCE.

Zakaj uvoz v resnici ne uspe

Sporočila o napakah klienta stisnejo več različnih težav v en stavek o neveljavnem potrdilu, zato jih ločite po vzroku. Najpogostejša je neujemanje kodiranja: odjemalec, ki razčlenjuje PEM, vrne napako razčlenjevanja pri datoteki DER, rešitev pa je pretvorba, ne novo potrdilo. Druga je manjkajoči ključ, ko je potrdilo v redu in identitete ni mogoče dokazati. Tretja je veriga, ko paket brez vmesnega potrdila izgleda pravilno v pogovornem oknu za uvoz in odpove med rokovanjem.

Parametri šifriranja povzročijo četrto in izgleda natanko kot napačno geslo. Starejše naprave so izvažale datoteke PKCS12 z RC2-40 in 3DES, ki jih OpenSSL 3 zavrne, razen če je naložen ponudnik legacy. Ponovni izvoz iz naprave z AES-256-CBC in PBKDF2 je trajna rešitev. Pustiti stare šifre trajno vključene na odjemalčevem računalniku zaradi ene datoteke je slaba kupčija.

Peta je dvoumnost. Vsebnik z dvema ključema in dvema potrdiloma ali datoteka PEM s tremi bloki CERTIFICATE prisili klienta k izbiri, njegova izbira pa je pogosto preprosto prvi element. Ko se tunel dvigne z napačno identiteto, je to običajno razlog.

Preglejte, preden pretvorite

Berite strukturo, ne da bi tiskali skrivnosti. openssl pkcs12 -in bundle.p12 -info -noout poroča o algoritmih šifriranja in vzdevkih ter zadrži izpis ključa in potrdila, priročnik openssl-pkcs12 pa dokumentira zastavice. Odstraniti -noout in dodati -nodes je za ustvarjanje datotek, ki jih nameravate hraniti, ne za hiter pogled, ker zasebni ključ zapiše odkrito.

Pri potrdilu openssl x509 -in cert.pem -noout -subject -issuer -dates odgovori na tisto, na kar pogovorno okno za uvoz ne bo, dodan -ext subjectAltName pa pokaže imena, za katera je potrdilo res veljavno. Če je datoteka DER, dodajte -inform DER; ta ena zastavica reši večino napak unable-to-load.

Ujemanje ključa s potrdilom je mehansko in se ga splača opraviti pred vsakim uvozom:

openssl x509 -in cert.pem -noout -pubkey | openssl sha256
openssl pkey -in key.pem -pubout | openssl sha256

Enaki povzetki pomenijo, da par spada skupaj. Različni povzetki pomenijo, da imate napačen ključ, in nobena pretvorba oblike tega ne bo spremenila.

Česar oblika nikoli ne spremeni

Odločitve o zaupanju se sprejemajo nad vsebnikom. Klient prehodi verigo do korena v svoji shrambi, preveri okno veljavnosti, preveri razširjeno uporabo ključa za preverjanje pristnosti odjemalca in na strani strežnika preveri, ali se ime, ki ga je klical, pojavi v potrdilu. Noben od teh korakov ne bere končnice datoteke.

Zato je preimenovanje datoteke, dokler napaka ne izgine, tako zanesljiv način zapravljanja časa. Uvoz uspe, identiteta je še vedno napačna, napaka pa se vrne med rokovanjem, kjer je sporočilo manj koristno. Zato se tudi paket, izvožen pred dvema letoma, uvozi čisto in je vseeno zavrnjen: datum poteka je potoval v potrdilu, ne v imenu datoteke.

Vrstni red, ki se izogne predelavi

Vprašajte dokumentacijo klienta, katere kodiranja sprejema in kateri vsebnik pričakuje za identiteto odjemalca, nato poglejte, kaj ste dobili. Če klient želi eno uvozno identiteto, vi pa imate ločene datoteke PEM, zgradite paket enkrat z geslom, ki ga nadzorujete, in obdržite vire. Če želi PEM, izvlecite ključ in verigo, nato pa vmesne datoteke odstranite s postopkom ravnanja s poverilnicami, ki ga vaša ekipa že uporablja.

Po uvozu preverite identiteto, ne pogovornega okna: subjekt, izdajatelja, potek in ime, ki ga bo klient predstavil. Prijazno ime na seznamu je oznaka, ne preverjena identiteta. Če tunel nato odpove, odpravljate preverjanje pristnosti ali usmerjanje namesto pakiranja, kar je veliko krajši pogovor.