PKCS12, PEM apo DER: çfarë i nevojitet vërtet një klienti VPN

Në diskutimet për certifikatat qarkullojnë dy pretendime. I pari është se .p12 është opsioni i fortë dhe .pem ai i lirshëm; i dyti, se një skedar teksti duhet të jetë i sigurt për t'u dërguar sepse mund ta lexoni. Asnjëri nuk i qëndron një minute inspektimi.

PKCS12, PEM dhe DER përshkruajnë se si objektet e certifikatës paketohen dhe kodohen. Ato nuk vendosin kush është pala tjetër, nëse lëshuesi është i besueshëm apo nëse skedari kërkon fjalëkalim.

Çfarë pranon klienti është çështje përputhshmërie. Çfarë përmban skedari është çështje identiteti. Mbajini të ndara dhe shumica e gabimeve të importimit nuk do të jenë më misterioze.

Tre kontejnerë, një model objekti

Filloni me atë që keni vërtet. Një certifikatë është një deklaratë e nënshkruar për një çelës publik. Çelësi privat është material i veçantë që dëshmon se ju kontrolloni atë çelës. Një zinxhir është grupi i lëshuesve që lidhin certifikatën tuaj me një rrënjë të cilës klienti i beson. Të tre ekzistojnë pavarësisht nga paketimi.

Një skedar PKCS12, zakonisht .p12 ose .pfx, është një kontejner i përcaktuar në RFC 7292 që mund të mbajë një çelës privat, një ose më shumë certifikata dhe zinxhirin në një bllok të vetëm të mbrojtur me fjalëkalim, me një alias që emërton identitetin. Një skedar PEM është një kornizë teksti e përcaktuar në RFC 7468: një trup base64 midis rreshtave BEGIN dhe END, dhe një skedar mund të mbajë disa blloqe me radhë. DER është kodimi binar i të njëjtave struktura ASN.1, dhe trupi PEM është fjalë për fjalë DER i mbështjellë me base64.

Ajo fjalia e fundit ia vlen të mbahet mend. Konvertimi i PEM në DER rishkruan kornizën, jo përmbajtjen, dhe konvertimi i kthimit jep bajtët origjinalë.

Kodimi nuk është kriptim

base64 është një alfabet transporti. Nuk fsheh asgjë, dhe kushdo mund të dekodojë një bllok PEM në një shell. Një skedar DER është binar dhe po aq publik. Asnjëra veti nuk është mbrojtje dhe asnjëra nuk nënkupton se ekziston një fjalëkalim.

Mbrojtja e vërtetë është në materialin e çelësit. Një paketë PKCS12 mund të kriptojë përmbajtjen e saj me një çelës të nxjerrë nga një fjalëkalim. Një çelës privat PEM mund të kriptohet me një bllok të vjetër kreu ose të mbahet në PKCS#8 EncryptedPrivateKeyInfo. Një certifikatë e vetme nuk mban asgjë të fshehtë, prandaj një eksport që prodhoi vetëm një certifikatë e lë klientin të paaftë për të vërtetuar identitetin, në çfarëdo formati që e mbështjellni.

Zgjatja është një aluzion, jo një kontratë. Skedarët që mbarojnë me .cer dhe .crt shfaqen në të dyja kodimet, dhe pajisjet eksportojnë certifikata DER me emra .pem mjaft shpesh sa që hamendja nga prapashtesa kushton një pasdite. Lexoni bajtët e parë në vend të kësaj: një skedar PEM hapet me një rresht BEGIN, ndërsa DER fillon me 0x30 sepse struktura e jashtme është një SEQUENCE.

Pse importimi dështon vërtet

Mesazhet e gabimit të klientit shtypin disa probleme të ndryshme në një fjali për një certifikatë të pavlefshme, ndaj ndajini sipas shkakut. Më i zakonshmi është mospërputhja e kodimit: një klient që analizon PEM kthen një gabim analize në një skedar DER, dhe zgjidhja është një konvertim, jo një certifikatë e re. I dyti është një çelës që mungon, ku certifikata është në rregull dhe identiteti nuk mund të provohet. I treti është zinxhiri, ku një paketë pa certifikatën e ndërmjetme duket e saktë në dialogun e importimit dhe dështon gjatë shtrëngimit të duarve.

Parametrat e kriptimit shkaktojnë një të katërt, dhe ai duket saktësisht si një fjalëkalim i gabuar. Pajisjet më të vjetra eksportonin skedarë PKCS12 me RC2-40 dhe 3DES, të cilat OpenSSL 3 i refuzon nëse ofruesi legacy nuk është i ngarkuar. Rieksportimi nga pajisja me AES-256-CBC dhe PBKDF2 është rregullimi i qëndrueshëm. Të lësh cifrat e vjetra përgjithmonë të aktivizuara në një makinë klienti për një skedar të vetëm është një marrëveshje e keqe.

I pesti është paqartësia. Një kontejner me dy çelësa dhe dy certifikata, ose një skedar PEM me tre blloqe CERTIFICATE, e detyron klientin të zgjedhë, dhe zgjedhja e tij shpesh është thjesht elementi i parë. Kur një tunel ngrihet me identitetin e gabuar, zakonisht kjo është arsyeja.

Inspektoni përpara se të konvertoni

Lexoni strukturën pa shtypur sekrete. openssl pkcs12 -in bundle.p12 -info -noout raporton algoritmet e kriptimit dhe aliaset duke shtypur daljen e çelësit dhe certifikatës, dhe manuali i openssl-pkcs12 dokumenton flamujt. Heqja e -noout dhe shtimi i -nodes është për të prodhuar skedarë që synoni t'i mbani, jo për një vështrim të shpejtë, sepse e shkruan çelësin privat hapur.

Për një certifikatë, openssl x509 -in cert.pem -noout -subject -issuer -dates përgjigjet asaj që një dialog importimi nuk do të përgjigjet, dhe shtimi i -ext subjectAltName tregon emrat për të cilët certifikata është vërtet e vlefshme. Nëse skedari është DER, shtoni -inform DER; ai flamur i vetëm zgjidh shumicën e gabimeve unable-to-load.

Përputhja e një çelësi me një certifikatë është mekanike, dhe ia vlen të bëhet përpara çdo importimi:

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

Digestet identike nënkuptojnë se çifti shkon bashkë. Digestet e ndryshme nënkuptojnë se keni çelësin e gabuar, dhe asnjë konvertim formati nuk e ndryshon këtë.

Çfarë nuk ndryshon kurrë formati

Vendimet e besimit merren mbi kontejnerin. Klienti ecën zinxhirin deri në një rrënjë në depon e tij, kontrollon dritaren e vlefshmërisë, kontrollon përdorimin e zgjeruar të çelësit për vërtetimin e klientit dhe në anën e serverit kontrollon që emri që thirri shfaqet në certifikatë. Asnjë prej këtyre hapave nuk lexon një zgjatje skedari.

Prandaj riemërtimi i një skedari derisa një gabim të zhduket është një mënyrë kaq e besueshme për të humbur kohë. Importimi ka sukses, identiteti është ende i gabuar, dhe dështimi rishfaqet gjatë shtrëngimit të duarve ku mesazhi është më pak i dobishëm. Prandaj edhe një paketë e eksportuar dy vjet më parë importohet pastër dhe refuzohet gjithsesi: data e skadimit udhëtoi brenda certifikatës, jo në emrin e skedarit.

Një rend që shmang ripunimin

Pyetni dokumentacionin e klientit cilat kodime pranon dhe çfarë kontejneri pret për një identitet klienti, pastaj shikoni çfarë ju është dhënë. Nëse klienti dëshiron një identitet të vetëm të importueshëm dhe ju keni skedarë PEM të veçantë, ndërtoni paketën një herë me një fjalëkalim që ju kontrolloni dhe mbani burimet. Nëse dëshiron PEM, nxirrni çelësin dhe zinxhirin, pastaj hiqni skedarët e ndërmjetëm përmes procesit të trajtimit të kredencialeve që ekipi juaj tashmë përdor.

Pas importimit, verifikoni identitetin, jo dialogun: subjekti, lëshuesi, skadimi dhe emri që klienti do të paraqesë. Një emër miqësor në një listë është etiketë, jo identitet i verifikuar. Nëse më pas tuneli dështon, ju po korrigjoni vërtetimin ose rrugëtimin në vend të paketimit, që është një bisedë shumë më e shkurtër.