Průchod začíná u seznamu certifikátů klienta, kde záznam ukazuje název, vydavatele a datum vypršení a nic jiného. Exportujte ho, importujte na druhém zařízení a připojení je odmítnuto, protože klient nedokáže prokázat vlastnictví soukromého klíče. Soubor byl zkopírován celý; chyba je očekávat, že certifikát ponese vlastní klíč. Přečtěte si dialog exportu, než zvolíte formát, a potom prozkoumejte soubor, který jste skutečně dostali.

Dvě kliknutí, dva velmi odlišné artefakty.

Čtěte dialog exportu, ne příponu souboru

Export certifikátu DER nebo PEM obsahuje veřejný klíč a podepsaná tvrzení o identitě, což je to, co server potřebuje, aby vám důvěřoval, a co klient potřebuje k ověření serveru. Balík PKCS#12 je kontejner, který může obsahovat certifikát, jeho řetězec a odpovídající soukromý klíč, chráněný heslem, i když ho lze vytvořit i bez klíče.

PEM je jen textové kódování, ne slib o obsahu. Stejná přípona může popisovat jediný certifikát nebo soubor s několika označenými bloky a o tom, který to je, rozhodují volby exportu.

Užitečná otázka tedy nikdy není, jakou příponu jste dostali, ale jaké bloky soubor obsahuje. Balík exportovaný bez klíče je pořád balík. Kontrolujte obsah, ne oblíbenost formátu.

Prozkoumejte, co jste skutečně dostali

Než cokoli importujete, hledejte popisky, potom si přečtěte pole certifikátu a potvrďte, kterou identitu držíte. Proveďte kontroly na souboru, který se skutečně bude importovat. Po každém novém exportu je zopakujte, protože volby se mohou lišit.

grep -E 'BEGIN (CERTIFICATE|PRIVATE KEY|ENCRYPTED PRIVATE KEY)' bundle.pem
openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -text | head -5
openssl pkcs12 -info -in client.p12 -noout

Export pouze s blokem certifikátu je veřejný objekt a nemůže se autentizovat. Blok klíče bez certifikátu vás nechá bez řetězce, který server očekává. Výstup informací PKCS#12 také hlásí, zda je klíč přítomen, což otázku pro tento formát uzavírá. Uvádí také algoritmus a velikost klíče a úplně selže, když klíč chybí.

Nikdy nevkládejte soubor se soukromým klíčem do vlákna podpory, do sledovače problémů ani do chatu, ani když vypadá jako certifikát, který jste už sdíleli. Snímky obrazovky panelu s klíčem si zaslouží stejnou opatrnost.

Klíč může žít tam, odkud ho nezkopírujete

Na spravovaných zařízeních může soukromý klíč sídlit v klíčence operačního systému, v hardwarovém tokenu nebo v bezpečném enklávě, přičemž zásada ho označuje jako neexportovatelný. Správce certifikátů pak ukazuje veřejný objekt, zatímco tajemství zůstává na místě, a žádný příkaz exportu nevytvoří přenosnou kopii. Zápis přes správu mobilních zařízení tak často funguje záměrně.

To je kontrola, ne překážka k obcházení. Rekonstruovat soukromý klíč z veřejného certifikátu není možné a každý nástroj, který to tvrdí, dělá něco jiného.

Zaregistrujte novou identitu místo kopírování

Podporovaná cesta obvykle je zaregistrovat pro nové zařízení samostatnou identitu a starou odvolat, až skončí, aby každé zařízení šlo stáhnout nezávisle. Tam, kde je export s klíčem skutečně schválen, berte výsledný soubor a jeho heslo jako přihlašovací údaje: šifrované v klidu, přenesené důvěryhodným kanálem a smazané, jakmile je registrace hotová.

Ověřujte autentizací s importovanou identitou, ne tím, že import proběhl. Klient, který do svého úložiště přijme veřejný certifikát, o klíči nic neprokázal.

Na závěr potvrďte, že server novou identitu přijímá a že se stará stále chová podle záměru zásady. Tím se průchod uzavírá důkazem, ne souborem, který vypadá správně.

Související články