PKCS12, PEM alebo DER: čo VPN klient skutočne potrebuje

V diskusiách o certifikátoch kolujú dve tvrdenia. Prvé, že .p12 je silná voľba a .pem tá voľná; druhé, že textový súbor musí byť bezpečný na odoslanie, pretože si ho môžete prečítať. Ani jedno neobstojí ani minútu skúmania.

PKCS12, PEM a DER opisujú, ako sa certifikátové objekty balia a kódujú. Nerozhodujú o tom, kto je protistrana, či je vydavateľ dôveryhodný alebo či súbor potrebuje heslo.

Čo klient prijme, je otázka kompatibility. Čo súbor obsahuje, je otázka identity. Oddeľte to a väčšina chýb pri importe prestane byť záhadou.

Tri kontajnery, jeden objektový model

Začnite tým, čo skutočne máte. Certifikát je podpísané tvrdenie o verejnom kľúči. Súkromný kľúč je samostatný materiál, ktorý dokazuje, že tento kľúč ovládate. Reťaz je množina vydavateľov, ktorí spájajú váš certifikát s koreňom, ktorému klient dôveruje. Všetky tri existujú bez ohľadu na balenie.

Súbor PKCS12, zvyčajne .p12 alebo .pfx, je kontajner definovaný v RFC 7292, ktorý môže niesť súkromný kľúč, jeden alebo viac certifikátov a reťaz v jedinom bloku chránenom heslom, s aliasom, ktorý pomenúva identitu. Súbor PEM je textové orámovanie podľa RFC 7468: telo base64 medzi riadkami BEGIN a END, a jeden súbor môže obsahovať niekoľko blokov za sebou. DER je binárne kódovanie tých istých štruktúr ASN.1 a telo PEM je doslova DER obalený base64.

Posledná veta stojí za zapamätanie. Prevod PEM na DER prepisuje orámovanie, nie obsah, a spätný prevod vracia pôvodné bajty.

Kódovanie nie je šifrovanie

base64 je prepravná abeceda. Nič neskrýva a ktokoľvek môže blok PEM dekódovať v shelli. Súbor DER je binárny a rovnako verejný. Ani jedna vlastnosť nie je ochrana a ani jedna neznamená, že existuje heslo.

Skutočná ochrana je v kľúčovom materiáli. Paket PKCS12 môže šifrovať svoj obsah kľúčom odvodeným z hesla. Súkromný kľúč PEM možno zašifrovať starým blokom hlavičky alebo ho uložiť v PKCS#8 EncryptedPrivateKeyInfo. Certifikát sám o sebe nič tajné neuchováva, preto export, ktorý vydal len certifikát, nechá klienta bez možnosti autentizácie, nech ho zabalíte do akéhokoľvek formátu.

Prípona je nápoveda, nie zmluva. Súbory končiace na .cer a .crt sa vyskytujú v oboch kódovaniach a zariadenia dosť často exportujú certifikáty DER pod menami .pem, že hádanie podľa prípony stojí popoludnie. Čítajte prvé bajty: súbor PEM začína riadkom BEGIN, zatiaľ čo DER začína 0x30, pretože vonkajšou štruktúrou je SEQUENCE.

Prečo import skutočne zlyháva

Chybové hlásenia klienta stláčajú niekoľko rôznych problémov do jednej vety o neplatnom certifikáte, preto ich rozdeľte podľa príčiny. Najčastejšia je nezhoda kódovania: klient, ktorý parsuje PEM, vráti chybu parsovania na súbore DER, a riešením je prevod, nie nový certifikát. Druhá je chýbajúci kľúč, keď je certifikát v poriadku a identitu nemožno preukázať. Tretia je reťaz, keď paket bez sprostredkujúceho certifikátu vyzerá v dialógu importu správne a zlyhá počas handshake.

Parametre šifrovania spôsobujú štvrtú a vyzerá presne ako zlé heslo. Staršie zariadenia exportovali súbory PKCS12 s RC2-40 a 3DES, ktoré OpenSSL 3 odmieta, ak nie je načítaný legacy poskytovateľ. Opätovný export zo zariadenia s AES-256-CBC a PBKDF2 je trvalé riešenie. Ponechať staré šifry natrvalo zapnuté na klientskom stroji pre jeden súbor je zlý obchod.

Piata je nejednoznačnosť. Kontajner s dvoma kľúčmi a dvoma certifikátmi alebo súbor PEM s tromi blokmi CERTIFICATE núti klienta vyberať a jeho voľba je často jednoducho prvý prvok. Keď tunel naskočí s nesprávnou identitou, býva to zvyčajne dôvod.

Prezrite pred prevodom

Čítajte štruktúru bez vypisovania tajomstiev. openssl pkcs12 -in bundle.p12 -info -noout hlási šifrovacie algoritmy a aliasy a potláča výstup kľúča a certifikátu, a manuál openssl-pkcs12 dokumentuje prepínače. Odstrániť -noout a pridať -nodes slúži na vytváranie súborov, ktoré hodláte uložiť, nie na rýchly pohľad, pretože vypisuje súkromný kľúč otvorene.

Pri certifikáte openssl x509 -in cert.pem -noout -subject -issuer -dates odpovedá na to, čo dialóg importu neodpovie, a pridanie -ext subjectAltName ukáže názvy, pre ktoré je certifikát skutočne platný. Ak je súbor DER, pridajte -inform DER; tento jediný prepínač vyrieši väčšinu chýb unable-to-load.

Spárovanie kľúča s certifikátom je mechanické a oplatí sa ho urobiť pred každým importom:

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

Rovnaké odtlačky znamenajú, že pár patrí k sebe. Rôzne odtlačky znamenajú, že máte nesprávny kľúč, a žiadny prevod formátu to nezmení.

Čo formát nikdy nezmení

Rozhodnutia o dôvere sa prijímajú nad kontajnerom. Klient prejde reťaz k koreňu vo svojom úložisku, skontroluje okno platnosti, skontroluje rozšírené použitie kľúča na autentizáciu klienta a na strane servera skontroluje, či sa názov, ktorý volal, nachádza v certifikáte. Žiadny z týchto krokov nečíta príponu súboru.

Preto je premenovanie súboru, kým chyba nezmizne, taký spoľahlivý spôsob strácania času. Import uspeje, identita je stále nesprávna a zlyhanie sa vráti počas handshake, kde je správa menej užitočná. Preto sa aj paket exportovaný pred dvoma rokmi naimportuje čisto a napriek tomu je odmietnutý: dátum expirácie cestoval vnútri certifikátu, nie v názve súboru.

Poradie, ktoré sa vyhne prerábaniu

Spýtajte sa dokumentácie klienta, ktoré kódovania prijíma a aký kontajner očakáva pre identitu klienta, a potom sa pozrite, čo ste dostali. Ak klient chce jednu importovateľnú identitu a vy máte voľné súbory PEM, zostavte paket raz s heslom, ktoré ovládate, a zdroje si ponechajte. Ak chce PEM, extrahujte kľúč a reťaz a potom medzisúbory odstráňte procesom nakladania s prihlasovacími údajmi, ktorý váš tím už používa.

Po importe overte identitu, nie dialóg: subjekt, vydavateľa, expiráciu a názov, ktorý klient predloží. Priateľský názov v zozname je štítok, nie overená identita. Ak potom tunel zlyhá, ladíte autentizáciu alebo smerovanie namiesto balenia, čo je oveľa kratší rozhovor.