PKCS12, PEM või DER: mida VPN-klient tegelikult vajab
Pakend otsustab, kas klient identiteedi impordib, mitte kas see on usaldusväärne. Võrrelge PKCS12, PEM ja DER-i ning seejärel kontrollige.
Sertifikaadiarutelutes ringleb kaks väidet. Esimene on, et .p12 on tugev valik ja .pem lõtv; teine, et tekstifail peab olema saatmiseks turvaline, sest saate seda lugeda. Kumbki ei pea vastu minutitki kontrolli.
PKCS12, PEM ja DER kirjeldavad, kuidas sertifikaadiobjekte pakendatakse ja kodeeritakse. Need ei otsusta, kes on vastaspool, kas väljaandjat usaldatakse või kas fail vajab parooli.
Mida klient aktsepteerib, on ühilduvuse küsimus. Mida fail sisaldab, on identiteedi küsimus. Hoidke need lahus ja enamik impordivigu lakkab olemast mõistatuslik.
Kolm konteinerit, üks objektimudel
Alustage sellest, mis teil tegelikult on. Sertifikaat on allkirjastatud väide avaliku võtme kohta. Privaatvõti on eraldi materjal, mis tõestab, et kontrollite seda võtit. Ahel on väljaandjate kogum, mis seob teie sertifikaadi juurega, mida klient usaldab. Kõik kolm on olemas sõltumata pakendist.
PKCS12-fail, tavaliselt .p12 või .pfx, on RFC 7292-s määratletud konteiner, mis võib kanda privaatvõtit, üht või mitut sertifikaati ja ahelat ühes parooliga kaitstud plokis, koos aliasega, mis nimetab identiteedi. PEM-fail on RFC 7468-s määratletud tekstiraam: base64-keha BEGIN- ja END-ridade vahel, ja üks fail võib hoida mitut plokki järjest. DER on samade ASN.1-struktuuride binaarne kodeering, ja PEM-keha on sõna otseses mõttes base64-sse mähitud DER.
See viimane lause tasub meelde jätta. PEM-i DER-iks teisendamine kirjutab ümber raami, mitte sisu, ja tagasiteisendamine annab algse baitjada.
| Container | Can hold | Does not decide |
|---|---|---|
| PKCS12 (.p12, .pfx) | Key, leaf certificate, chain, alias, password | Which root the client trusts |
| PEM (.pem, .crt, .cer) | Any number of base64 blocks | Whether the private key is present |
| DER (.der, .cer) | One binary structure | The object type, whatever the extension says |
Kodeerimine ei ole krüpteerimine
Base64 on transpordialfabeet. See ei varja midagi ja igaüks saab PEM-ploki shellis dekodeerida. DER-fail on binaarne ja sama avalik. Kumbki omadus ei ole kaitse ja kumbki ei eelda, et parool oleks olemas.
Tegelik kaitse on võtmematerjalis. PKCS12-pakett võib oma sisu krüpteerida paroolist tuletatud võtmega. PEM-privaatvõtit saab krüpteerida vana päiseplokiga või hoida PKCS#8 EncryptedPrivateKeyInfo sees. Sertifikaat üksi ei hoia midagi salajast, seetõttu jätab eksport, mis andis ainult sertifikaadi, kliendi autentida suutmatusse, ükskõik millisesse vormingusse te selle pakite.
Laiend on vihje, mitte leping. Failid, mis lõpevad .cer ja .crt-ga, esinevad mõlemas kodeeringus, ja seadmed ekspordivad DER-sertifikaate .pem-nimede all piisavalt sageli, et sufiksi järgi oletamine maksaks ühe pärastlõuna. Lugege hoopis esimesi baite: PEM-fail algab BEGIN-reaga, samas kui DER algab 0x30-ga, sest välimine struktuur on SEQUENCE.
Miks import tegelikult ebaõnnestub
Kliendi veateated suruvad mitu erinevat probleemi ühte lausesse kehtetu sertifikaadi kohta, seega eraldage need põhjuse järgi. Kõige tavalisem on kodeeringu lahknevus: PEM-i parsiv klient tagastab DER-faili puhul parsinguvea ja parandus on teisendamine, mitte uus sertifikaat. Teine on puuduv võti, kus sertifikaat on korras ja identiteeti ei saa tõestada. Kolmas on ahel, kus ilma vahesertifikaadita pakett näeb impordidialoogis õige välja ja ebaõnnestub käepigistuse ajal.
Krüpteerimisparameetrid põhjustavad neljanda ja see näeb täpselt välja nagu vale parool. Vanemad seadmed eksportisid PKCS12-faile RC2-40 ja 3DES-iga, mida OpenSSL 3 keeldub kasutamast, kui legacy-pakkuja pole laaditud. Seadmest AES-256-CBC ja PBKDF2-ga uuesti eksportimine on püsiv lahendus. Vanade šifrite jäädavalt sisselülitamine kliendimasinas ühe faili pärast on halb tehing.
Viies on mitmetähenduslikkus. Konteiner kahe võtme ja kahe sertifikaadiga või PEM-fail kolme CERTIFICATE-plokiga sunnib kliendi valima ja tema valik on sageli lihtsalt esimene üksus. Kui tunnel tõuseb vale identiteediga, on see tavaliselt põhjus.
Kontrollige enne teisendamist
Lugege struktuuri ilma saladusi trükkimata. openssl pkcs12 -in bundle.p12 -info -noout teatab krüpteerimisalgoritmid ja aliaste nimed, surudes maha võtme- ja sertifikaadiväljundi, ja openssl-pkcs12 käsiraamat dokumenteerib lipud. -noout eemaldamine ja -nodes lisamine on mõeldud failide loomiseks, mida kavatsete hoida, mitte kiireks pilguks, sest see kirjutab privaatvõtme avatult.
Sertifikaadi puhul vastab openssl x509 -in cert.pem -noout -subject -issuer -dates sellele, millele impordidialoog ei vasta, ja -ext subjectAltName lisamine näitab nimesid, mille jaoks sertifikaat tegelikult kehtib. Kui fail on DER, lisage -inform DER; see üks lipp lahendab enamiku unable-to-load-vigadest.
Võtme sobitamine sertifikaadiga on mehaaniline ja tasub teha enne igat importi:
openssl x509 -in cert.pem -noout -pubkey | openssl sha256openssl pkey -in key.pem -pubout | openssl sha256
Identsed räsimused tähendavad, et paar kuulub kokku. Erinevad räsimused tähendavad, et teil on vale võti, ja ükski vormingu teisendus ei muuda seda.
Mida vorming kunagi ei muuda
Usaldusotsused tehakse konteineri kohal. Klient läbib ahela oma hoidla juureni, kontrollib kehtivusakent, kontrollib laiendatud võtmekasutust kliendi autentimiseks ja serveri poolel kontrollib, et helistatud nimi esineb sertifikaadis. Ükski neist sammudest ei loe faililaiendit.
Seetõttu on faili ümbernimetamine kuni vea kadumiseni nii usaldusväärne viis aja raiskamiseks. Import õnnestub, identiteet on endiselt vale ja tõrge ilmub uuesti käepigistuse ajal, kus teade on vähem abistav. Seetõttu ka kaks aastat tagasi eksporditud pakett imporditakse puhtalt ja lükatakse ikkagi tagasi: aegumiskuupäev reisis sertifikaadi sees, mitte failinimes.
Järjekord, mis väldib ümbertegemist
Küsige kliendi dokumentatsioonist, milliseid kodeeringuid see aktsepteerib ja millist konteinerit kliendi identiteedi jaoks ootab, ja vaadake siis, mis teile anti. Kui klient tahab üht imporditavat identiteeti ja teil on lahtised PEM-failid, ehitage pakett üks kord parooliga, mida kontrollite, ja hoidke allikad. Kui ta tahab PEM-i, eraldage võti ja ahel ning eemaldage seejärel vahefailid protsessiga volituste käsitlemiseks, mida teie meeskond juba kasutab.
Pärast importi kontrollige identiteeti, mitte dialoogi: subjekt, väljaandja, aegumine ja nimi, mille klient esitab. Sõbralik nimi loendis on silt, mitte kinnitatud identiteet. Kui tunnel seejärel ebaõnnestub, silute autentimist või marsruutimist pakendi asemel, mis on palju lühem vestlus.