PKCS12, PEM eða DER: hvað VPN-klient þarf í raun

Í umræðum um skírteini ganga tvær fullyrðingar. Sú fyrri er að .p12 sé sterki valkosturinn og .pem sá lausi; sú seinni að textaskrá verði að vera örugg til sendingar því þú getur lesið hana. Hvorug stenst mínútu af skoðun.

PKCS12, PEM og DER lýsa því hvernig skírteinahlutir eru pakkaðir og kóðaðir. Þau ákvarða ekki hver mótaðilinn er, hvort treyst sé útgefandanum eða hvort skráin þurfi lykilorð.

Það sem klientinn tekur við er spurning um samhæfni. Það sem skráin inniheldur er spurning um auðkenni. Haltu þessu tvennu aðskildu og flestum innflutningsvillum hættir að vera ráðgáta.

Þrír gámar, eitt hlutamódel

Byrjaðu á því sem þú hefur í raun. Skírteini er undirrituð yfirlýsing um opinberan lykil. Einkalykillinn er sérstakt efni sem sannar að þú stjórnar þeim lykli. Keðja er mengi útgefenda sem tengja skírteinið þitt rót sem klientinn treystir. Öll þrjú eru til óháð pökkuninni.

PKCS12-skrá, venjulega .p12 eða .pfx, er gámur skilgreindur í RFC 7292 sem getur borið einkalykil, eitt eða fleiri skírteini og keðjuna í einum lykilorðsvörðum hluta, með dulnefni sem nefnir auðkennið. PEM-skrá er textarammi skilgreindur í RFC 7468: base64-bolur milli BEGIN- og END-lína, og ein skrá getur haldið nokkrum hlutum í röð. DER er tvíundarkóðun sömu ASN.1-gerða, og PEM-bolurinn er bókstaflega DER vafið í base64.

Síðasta setningin er þess virði að muna. Að umbreyta PEM í DER endurskrifar rammann, ekki innihaldið, og afturumbreyting skilar upprunalegu bætunum.

Kóðun er ekki dulkóðun

base64 er flutningsstafróf. Það felur ekkert og hver sem er getur afkóðað PEM-hluta í skel. DER-skrá er tvíundarleg og jafn opinber. Hvorug eiginleikinn er vernd, og hvorugur gefur til kynna að lykilorð sé til.

Raunveruleg vernd er í lyklaefninu. PKCS12-bunki getur dulkóðað innihald sitt með lykli fengnum úr lykilorði. PEM-einkalykil má dulkóða með gömlum hausblokk eða geyma í PKCS#8 EncryptedPrivateKeyInfo. Skírteini eitt og sér geymir ekkert leyndarmál, þess vegna skilur útflutningur sem gaf aðeins skírteini klientinn eftir ófæran um auðkenningu, í hvaða sniði sem þú vefur það.

Viðskeytið er vísbending, ekki samningur. Skrár sem enda á .cer og .crt koma fyrir í báðum kóðunum, og tæki flytja út DER-skírteini undir .pem-nöfnum nógu oft til að gisk á viðskeytinu kosti síðdegi. Lestu fyrstu bætin í staðinn: PEM-skrá opnast með BEGIN-línu, en DER byrjar á 0x30 því ytra formið er SEQUENCE.

Hvers vegna innflutningurinn mistekst í raun

Villuskilaboð klienta þjappa nokkrum mismunandi vandamálum í eina setningu um ógilt skírteini, svo skildu þau eftir orsök. Algengast er kóðunarmisræmi: klient sem þáttar PEM skilar þáttunarvillu á DER-skrá, og lausnin er umbreyting, ekki nýtt skírteini. Annað er vantar lykil, þar sem skírteinið er í lagi og ekki er hægt að sanna auðkennið. Þriðja er keðjan, þar sem bunki án milliskírteinis lítur rétt út í innflutningsglugganum og bregst við handabandið.

Dulkóðunarfæribreytur valda fjórða og þau líta nákvæmlega út eins og rangt lykilorð. Eldri tæki fluttu út PKCS12-skrár með RC2-40 og 3DES, sem OpenSSL 3 hafnar nema legacy-veitandinn sé hlaðinn. Endurútflutningur úr tækinu með AES-256-CBC og PBKDF2 er varanleg lausn. Að láta gömul dulritun vera varanlega virk á klientvél fyrir eina skrá er slæmur skipti.

Fimmta er tvíræðni. Gámur með tveimur lyklum og tveimur skírteinum, eða PEM-skrá með þremur CERTIFICATE-hlutum, neyðir klientinn til að velja, og val hans er oft einfaldlega fyrsta atriðið. Þegar göng kemur upp með ranga auðkennið er það venjulega ástæðan.

Skoðaðu áður en þú umbreytir

Lestu skipulagt án þess að prenta leyndarmál. openssl pkcs12 -in bundle.p12 -info -noout greinir frá dulkóðunarreikniritunum og dulnefnunum og bælir lykil- og skírteinisúttak, og openssl-pkcs12 handbókin skjalfest flöggin. Að sleppa -noout og bæta við -nodes er til að búa til skrár sem þú ætlar að geyma, ekki fyrir fljótlegt augnaráð, því það skrifar einkalykilinn ódulkóðað.

Fyrir skírteini svarar openssl x509 -in cert.pem -noout -subject -issuer -dates því sem innflutningsgluggi svarar ekki, og með -ext subjectAltName bættu sýnir það nöfnin sem skírteinið er í raun gilt fyrir. Ef skráin er DER skaltu bæta við -inform DER; það eitt flagg leysir flest unable-to-load villur.

Að para lykil við skírteini er vélrænt og þess virði fyrir hvern innflutning:

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

Einsleitir hak gera að parinu tilheyra saman. Mismunandi hak gera að þú hefur rangan lykil, og engin sniðumbreyting breytir því.

Það sem sniðið breytir aldrei

Traustákvarðanir eru teknar yfir gáminum. Klientinn gengur keðjuna að rót í geymslu sinni, athugar gildistíma, athugar rýmkaða lyklanotkun fyrir auðkenningu klients og athugar hið meginmál að nafnið sem hringt var í komi fyrir í skírteininu. Ekkert þessara skrefa les skráarviðskeyti.

Þess vegna er að endurskíra skrá þar til villa hverfur svo áreiðanleg leið til að eyða tíma. Innflutningurinn tekst, auðkennið er enn rangt, og bilunin kemur aftur við handabandið þar sem skilaboðin eru minna hjálpsöm. Þess vegna flyst bunki sem fluttur var út fyrir tveimur árum inn hreint og er samt hafnað: lokadagurinn ferðaðist inni í skírteininu, ekki í skráarnafninu.

Röð sem kemur í veg fyrir endurvinnu

Spyrðu skjöl klientins hvaða kóðanir hann tekur við og hvaða gám hann væntir fyrir auðkenni klients, og sjáðu svo hvað þér var afhent. Ef klientinn vill eitt innflutningshæft auðkenni og þú hefur lausar PEM-skrár skaltu byggja bunkann einu sinni með lykilorði sem þú stjórnar og geyma upprunann. Ef hann vill PEM skaltu draga út lykilinn og keðjuna og fjarlægja svo milliskrárnar með því ferli við meðferð skilríkja sem teymið þitt notar þegar.

Eftir innflutning skaltu sannprófa auðkennið frekar en gluggann: viðfang, útgefanda, lok og nafnið sem klientinn mun kynna. Vingjarnlegt nafn á lista er merki, ekki staðfest auðkenni. Ef göngin mistakast svo ertu að kemba auðkenningu eða leiðsögn í stað pökkunar, sem er mun styttra samtal.