PKCS12, PEM nebo DER: co VPN klient skutečně potřebuje

V diskusích o certifikátech kolují dvě tvrzení. První, že .p12 je silná volba a .pem ta volná; druhé, že textový soubor musí být bezpečný k odeslání, protože si ho můžete přečíst. Ani jedno neobstojí ani minutu zkoumání.

PKCS12, PEM a DER popisují, jak se certifikátové objekty balí a kódují. Nerozhodují o tom, kdo je protějšek, zda je vydavatel důvěryhodný nebo zda soubor potřebuje heslo.

Co klient přijme, je otázka kompatibility. Co soubor obsahuje, je otázka identity. Oddělte to a většina chyb při importu přestane být záhadou.

Tři kontejnery, jeden objektový model

Začněte tím, co skutečně máte. Certifikát je podepsané tvrzení o veřejném klíči. Soukromý klíč je samostatný materiál, který dokazuje, že tento klíč ovládáte. Řetěz je množina vydavatelů, kteří spojují váš certifikát s kořenem, kterému klient důvěřuje. Všechny tři existují bez ohledu na balení.

Soubor PKCS12, obvykle .p12 nebo .pfx, je kontejner definovaný v RFC 7292, který může nést soukromý klíč, jeden nebo více certifikátů a řetěz v jediném bloku chráněném heslem, s aliasem, který pojmenovává identitu. Soubor PEM je textové orámování podle RFC 7468: tělo base64 mezi řádky BEGIN a END, a jeden soubor může obsahovat několik bloků za sebou. DER je binární kódování stejných struktur ASN.1 a tělo PEM je doslova DER obalený base64.

Poslední věta stojí za zapamatování. Převod PEM na DER přepisuje orámování, ne obsah, a zpětný převod vrací původní bajty.

Kódování není šifrování

Base64 je přepravní abeceda. Nic neskrývá a kdokoli může blok PEM dekódovat v shellu. Soubor DER je binární a stejně veřejný. Ani jedna vlastnost není ochrana a ani jedna neznamená, že existuje heslo.

Skutečná ochrana je v klíčovém materiálu. Paket PKCS12 může šifrovat svůj obsah klíčem odvozeným z hesla. Soukromý klíč PEM lze zašifrovat starým blokem záhlaví nebo uložit v PKCS#8 EncryptedPrivateKeyInfo. Certifikát sám o sobě nic tajného neuchovává, a proto export, který vydal jen certifikát, nechá klienta bez možnosti autentizace, ať ho zabalíte do jakéhokoli formátu.

Přípona je nápověda, ne smlouva. Soubory končící na .cer a .crt se vyskytují v obou kódováních a zařízení dost často exportují certifikáty DER pod jmény .pem, že hádání podle přípony stojí odpoledne. Čtěte první bajty: soubor PEM začíná řádkem BEGIN, zatímco DER začíná 0x30, protože vnější strukturou je SEQUENCE.

Proč import skutečně selhává

Chybové zprávy klienta slisují několik různých problémů do jedné věty o neplatném certifikátu, proto je rozdělte podle příčiny. Nejčastější je nesoulad kódování: klient, který parsuje PEM, vrátí na souboru DER chybu parsování, a opravou je převod, ne nový certifikát. Druhá je chybějící klíč, kdy je certifikát v pořádku a identitu nelze prokázat. Třetí je řetěz, kdy paket bez zprostředkujícího certifikátu vypadá v dialogu importu správně a selže během handshake.

Parametry šifrování způsobují čtvrtou a vypadá přesně jako špatné heslo. Starší zařízení exportovala soubory PKCS12 s RC2-40 a 3DES, které OpenSSL 3 odmítá, pokud není načten legacy provider. Opětovný export ze zařízení s AES-256-CBC a PBKDF2 je trvalým řešením. Ponechat staré šifry trvale zapnuté na klientském stroji kvůli jednomu souboru je špatný obchod.

Pátá je nejednoznačnost. Kontejner se dvěma klíči a dvěma certifikáty nebo soubor PEM se třemi bloky CERTIFICATE nutí klienta volit a jeho volba je často prostě první položka. Když tunel naskočí se špatnou identitou, bývá to obvykle důvod.

Prohlédněte před převodem

Čtěte strukturu, aniž byste vypisovali tajemství. openssl pkcs12 -in bundle.p12 -info -noout hlásí šifrovací algoritmy a aliasy a potlačuje výstup klíče a certifikátu, a manuál openssl-pkcs12 dokumentuje přepínače. Odebrat -noout a přidat -nodes slouží k vytváření souborů, které hodláte uložit, ne k rychlému pohledu, protože vypisuje soukromý klíč otevřeně.

U certifikátu openssl x509 -in cert.pem -noout -subject -issuer -dates odpovídá na to, co dialog importu neodpoví, a přidání -ext subjectAltName ukáže názvy, pro které je certifikát skutečně platný. Pokud je soubor DER, přidejte -inform DER; tento jediný přepínač vyřeší většinu chyb unable-to-load.

Spárovat klíč s certifikátem je mechanické a vyplatí se to před každým importem:

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

Shodné otisky znamenají, že pár patří k sobě. Různé otisky znamenají, že máte špatný klíč, a žádný převod formátu to nezmění.

Co formát nikdy nezmění

Rozhodnutí o důvěře se odehrávají nad kontejnerem. Klient projde řetěz k kořeni ve svém úložišti, zkontroluje okno platnosti, zkontroluje rozšířené použití klíče pro autentizaci klienta a na straně serveru zkontroluje, že název, který volal, je v certifikátu. Žádný z těchto kroků nečte příponu souboru.

Proto je přejmenování souboru, dokud chyba nezmizí, tak spolehlivý způsob, jak ztrácet čas. Import uspěje, identita je stále špatná a selhání se vrátí během handshake, kde je zpráva méně užitečná. Proto se také paket exportovaný před dvěma lety naimportuje čistě a přesto je odmítnut: datum expirace cestovalo uvnitř certifikátu, ne v názvu souboru.

Pořadí, které se vyhne předělávání

Zeptejte se dokumentace klienta, která kódování přijímá a jaký kontejner očekává pro identitu klienta, a pak se podívejte, co jste dostali. Pokud klient chce jedinou importovatelnou identitu a vy máte volné soubory PEM, sestavte paket jednou s heslem, které ovládáte, a zdroje si ponechte. Pokud chce PEM, extrahujte klíč a řetěz a poté mezisoubory odstraňte procesem nakládání s přihlašovacími údaji, který váš tým už používá.

Po importu ověřte identitu, ne dialog: subjekt, vydavatele, expiraci a název, který klient předloží. Přátelský název v seznamu je štítek, ne ověřená identita. Pokud pak tunel selže, ladíte autentizaci nebo směrování místo balení, což je mnohem kratší rozhovor.