Samopodepsaný versus veřejný CA pro VPN: co se skutečně mění

Dostanete se na stránku certifikátů v nastavení VPN, uvidíte bezplatnou samopodepsanou možnost vedle placeného veřejného CA a otázka zní jako volba zabezpečení. Ve skutečnosti je to volba publika. Obě možnosti šifrují tunel stejnými primitivy a obě jsou bezcenné, pokud unikne soukromý klíč. Odlišuje je to, kdo tvrzení o identitě serveru vyslovuje a kdo je v pozici toto tvrzení ověřit.

Certifikát dělá dvě věci, které se pletou

Certifikát spojuje veřejný klíč s názvem a klíč vykonává práci šifrování a podpisu. Podpis na certifikátu je samostatné prohlášení: nějaká autorita ověřila, že název patří tomuto držiteli klíče. Samopodepsaný certifikát toto prohlášení vydává sám o sobě, což není žádné tvrzení třetí strany.

Veřejné weby potřebují verzi od třetí strany, protože návštěvníci přicházejí bez předchozího vztahu a spoléhají na úložiště důvěry prohlížeče. Klient VPN není cizinec. Dáte mu certifikát CA nebo připnete certifikát serveru uvnitř profilu, který instaluje, takže ověření probíhá přesně proti autoritě, kterou jste zvolili. Aby toto ověření mělo smysl, nemusí být zapojen žádný komerční CA.

Síla výsledné relace pochází z velikosti klíče a šifrovací sady, ne od podepisujícího. Proto je nazývat samopodepsaný certifikát "méně šifrovaným" prostě špatné; je méně široce ručen, což je jiná vlastnost.

Kde si veřejný CA vydělá svůj poplatek

Nejjasnějším případem je administrační stránka. Pokud kolegové, dodavatelé nebo kdokoli jiný bez připraveného profilu musí otevřít webové rozhraní serveru VPN bez varování prohlížeče, veřejně důvěryhodný certifikát toto tření odstraní. Prohlížeč už podepisujícímu důvěřuje, takže není co importovat a co vysvětlovat.

Tato výhoda má náklady, které stojí za to pojmenovat před nákupem. Obnova musí být automatizovaná, jinak se web podle plánu rozbije, veřejné certifikáty vystavují název hostitele v protokolech transparentnosti certifikátů a limity rychlosti vydávání trestají skript, který příliš horlivě opakuje pokus. Nic z toho není důvod se veřejnému CA vyhýbat, ale je to provozní práce, kterou soukromý CA přesouvá jinam.

Co veřejný certifikát nedělá, je ověřování vašich uživatelů. Identita klienta je samostatné rozhodnutí, učiněné klientskými certifikáty, hesly nebo druhým faktorem, a CA, který podepisuje server, neříká nic o tom, kdo se k němu smí připojit.

Kde se soukromý CA hodí pro VPN

Pro soukromou VPN se známou sadou klientů je provozování vlastního CA obvyklou volbou. CA vytvoříte jednou, podepíšete certifikát serveru názvem, který klienti budou používat, a certifikát CA distribuujete v každém profilu. Potom každý klient ověřuje server proti vaší autoritě a žádná vnější strana se nedozví název hostitele.

Náklady jsou skutečné, ale omezené. Prohlížeče varují, když někdo otevře administrační stránku přímo, protože prohlížeč nemá důvod vašemu CA důvěřovat. Distribuce profilů se stává součástí onboardingu a rotace CA znamená dotknout se každého klienta. To jsou přijatelné ceny pro službu s deseti nebo padesáti známými uživateli a bolestné pro veřejný koncový bod s tisíci.

Celé uspořádání platí pod jednou podmínkou: ověření se musí odehrát. Klient nastavený ignorovat chyby certifikátů přijme jakýkoli server, který předloží jakýkoli certifikát, takže záruka identity zmizí, zatímco šifrování zůstává. Toto nastavení je skutečná slabina ve většině příběhů "samopodepsané je nezabezpečené".

Soukromý klíč CA rozhoduje, co můžete později dělat

Překvapení obvykle dorazí o měsíce později, když chcete přidat zařízení. Vydání klientského certifikátu vyžaduje soukromý klíč CA, stejně jako vytvoření seznamu odvolání. Pokud jste zdědili server, který má soubory certifikátu a klíče, ale ne klíč CA, nemůžete nic nového podepsat. Vaše možnosti jsou přestavět PKI a dát každému klientovi nový certifikát CA, nebo přejít na ověřování heslem, což je jiný model zabezpečení a neobnoví ztracené.

Dvě menší pasti žijí ve stejném území. Skripty easy-rsa předpokládají, že stojíte v adresáři, který je obsahuje, takže chyba chybějícího souboru obvykle znamená špatné umístění, nikoli poškozenou instalaci. A návrh jen s certifikáty je zcela legitimní: můžete vyžadovat klientské certifikáty bez předem sdíleného klíče, pokud každý klient nějaký má a server ověřuje řetěz.

Vydávejte jeden certifikát na zařízení místo jednoho sdíleného klientského certifikátu pro celý tým. Ztracený notebook vás pak stojí jedno odvolání místo nového vydání pro všechny.

Zkontrolujte, co jste zdědili

Než začnete plánovat jakoukoli změnu, přečtěte si certifikát, který už máte:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

Pokud se vydavatel rovná subjektu, certifikát je samopodepsaný, což je volba návrhu, nikoli vada. Data vám řeknou, kdy se obnova stane něčím problémem, a úspěšné ověření proti CA, kterou hodláte nasadit, potvrdí, že řetěz funguje dřív, než ho vyzkouší jediný klient.

Potom vybírejte podle publika a distribuce: veřejný CA, když neznámé prohlížeče musí důvěřovat administrační stránce, soukromý CA, když každý klient dostane profil, který ovládáte. Ani jedna odpověď není více šifrovaná než druhá.