Než to převedete: SSH klíč versus certifikát OpenVPN

Import selhává s chybou certifikátu, takže zjevný krok vypadá jako převod. Ten instinkt vede lidi cestou, na které se změní přípona souboru a odmítnutí zůstane přesně stejné. Řádek ssh-ed25519 v authorized_keys a klientský certifikát OpenVPN jsou oddělené objekty pověření s různými vydavateli, různým kódováním a různými cestami odvolání. Když tyto kontroly projdete popořadě, do minuty zjistíte, zda převod vůbec může pomoci.

Jaký objekt vlastně máte?

Lidé nazývají klíčem pět věcí a jen jedna z nich je to, co chce profil TLS. Veřejný klíč SSH je jeden řádek textu s prefixem typu a daty base64. Certifikát OpenSSH je tento klíč plus podpis, principálové a volby, které vytváří ssh-keygen vystupující jako vlastní malá CA. Certifikát X.509 je úplně jiná struktura: nese subjekt, okno platnosti, rozšíření a podpis od certifikační autority. Soukromý klíč je tajná polovina a vydaný balík je obvykle certifikát plus jeho řetěz plus soukromý klíč v jednom souboru.

První test stojí jeden příkaz. Namiřte openssl na soubor a požádejte ho o rozbor struktury certifikátu:

openssl x509 -in client.crt -noout -subject -issuer

Pokud to selže s chybou nelze načíst nebo chybou PEM, soubor není certifikát X.509, ať už jste ho pojmenovali jakkoli. Přejmenování nepřepíše ASN.1 uvnitř a nezabere ani obalení řádku veřejného klíče do textu hlavičky PEM.

Žádá profil vůbec certifikát?

Klientské certifikáty jsou jedna metoda autentizace z několika a řada funkčních profilů TLS je nikdy nevyžaduje. Server může autentizovat uživatele pomocí pluginu, uživatelského jména a hesla nebo tokenového backendu, a přitom stále vyžadovat, aby klient ověřil identitu serveru. Pokud profil neobsahuje direktivu klientského certifikátu, žádný certifikát nikdy nebude vyžádán a žádný převod nepřiměje bránu, aby ho vyžádala.

Starší konfigurace se statickým klíčem jsou třetí případ. Předcházejí handshaku TLS a očekávají soubor předem sdíleného tajemství, a proto ani vložení veřejného klíče do toho pole nemůže fungovat. Přečtěte si, co profil skutečně žádá, než rozhodnete, že je pověření špatné.

Co překódování umí a co ne

Soukromé klíče mají legitimní alternativní kontejnery. Stejný klíč RSA nebo EC lze zapsat jako tradiční PEM, jako PKCS#8 nebo do balíku PKCS#12 a nástroje mezi nimi rády převádějí. Veřejné klíče mají podobný příběh: ssh-keygen umí vypsat podobu RFC 4716 klíče SSH a OpenSSH rozumí i vlastnímu formátu certifikátu. To vše je reprezentace a reprezentace není důvěra.

Co převod neumí, je vytvořit podpis od certifikační autority, která váš klíč nikdy neviděla. Certifikát je tvrzení vydavatele, že určitý veřejný klíč patří určitému subjektu pro určitý účel. Překódování zachová bajty klíče a tvrzení ponechá nepřítomné, takže brána nemá co ověřit proti svému úložišti důvěry.

To je krok, na kterém většina pokusů tiše selže: soubor nyní končí na .crt, klient ho čte bez stížností a handshake přesto selže, protože protistrana nedokáže sestavit řetěz k důvěryhodnému vydavateli.

Kde do hry vstupuje certifikační autorita

Skutečná registrace začíná párem klíčů, který ovládáte, a žádostí o podpis certifikátu, která nese subjekt očekávaný operátorem. Operátor ověří oprávnění, podepíše žádost klíčem CA a vrátí vydaný certifikát spolu s jakýmkoli zprostředkujícím řetězem, který klient musí předložit. Klient pak potřebuje certifikát CA, který ho podepsal, protože právě ten mu umožní potvrdit, že server, se kterým mluví, patří ke stejnému nasazení.

Ten poslední soubor se snadno zapomene a nelze ho nahradit. Samotný podpisový klíč CA nikdy nepatří do klientské konfigurace a sebevětší místní převod nevytvoří řetěz, který jste měli obdržet.

Co vás stojí opětovné použití SSH klíče

Předpokládejme, že převod přece jen vytvořil něco přijatelného. Opětovné použití jednoho páru klíčů pro SSH přístup a autentizaci VPN stále spojuje dvě nezávislá bezpečnostní rozhodnutí. Odebrání záznamu z authorized_keys zastaví SSH přihlášení a certifikátu, který CA VPN už pro stejný veřejný klíč vydala, neudělá nic. Strana VPN se odvolává vlastním mechanismem, tedy seznamem odvolaných certifikátů nebo záznamem o registraci u operátora.

Kontrolní seznam proto končí zastavovací podmínkou, nikoli trikem. Pokud openssl soubor nerozpozná jako certifikát, přestaňte převádět a popište, co máte: SSH klíč, SSH certifikát, certifikát X.509, soukromý klíč nebo balík. Pokud profil klientský certifikát nežádá, zastavte se a zeptejte se, jakou metodu autentizace server očekává. Teprve když obě odpovědi ukazují na X.509, stává se registrace dalším krokem, a ten rozhovor je mnohem rychlejší se správným podstatným jménem v první větě.