OpenVPN username-as-common-name: proč je vaše kontrola CN prázdná

Přidáte client-connect, který odmítne každé spojení, kde se common_name liší od username, a vypadá to jako svázání certifikátu s účtem. Na serveru s username-as-common-name už toto porovnání v okamžiku spuštění skriptu ztratilo smysl. Obě hodnoty jsou stejný řetězec, takže test projde i u certifikátu vydaného úplně jiné osobě.

Kontrola není špatná proto, že je skript špatně napsaný. Je špatná proto, že hodnota, kterou čte, byla nahrazena dřív ve stejném spojení.

Co má porovnání údajně dokazovat

Ověření certifikátem a ověření heslem jsou dva oddělené důkazy a server může žádat oba, aniž by žadoval, že patří stejné osobě. Rozdíl je skutečný: platný certifikát zařízení plus jakýkoli platný účet je jiné tvrzení než tentýž certifikát plus jeden konkrétní účet. Skript, který porovnává common_name s username, zní jako chybějící článek mezi oběma. A byl by jím, kdyby common_name ještě znamenal to, co říkal certifikát.

Zda tomu tak je, závisí na jedné volbě serveru, a ta se obvykle zapíná z nesouvisejícího důvodu, například aby se snadněji pojmenovaly konfigurační soubory pro jednotlivé uživatele.

Co username-as-common-name dělá se jménem

Když je username-as-common-name zapnutý, OpenVPN po ověření uživatelského jména a hesla nahradí společné jméno certifikátu ověřeným uživatelským jménem. Ověřovací hák, který se během této kontroly spouští, stále dostává společné jméno certifikátu, protože nahrazení ještě nenastalo. Všechno další, včetně client-connect, vidí uživatelské jméno. Pozdější volání tak dostane jednu identitu dvakrát a nemůže ji porovnat s předloženým certifikátem.

Projděte si jedno ilustrativní spojení: certifikát vydaný pro bob-device, úspěšné přihlášení do adresáře jako alice a zapnutá volba. Fáze ověření stále může vidět dva různé řetězce. Fáze připojení vidí alice a alice.

Tento příklad ukazuje, proč je porovnání prázdné. Neukazuje, že by spojení jinak bylo přijato, protože ověření certifikátu a ověření hesla stále běží samostatně.

Umístěte svázání tam, kde obě identity ještě existují

Pravidlo se musí vynucovat ve fázi, která vidí identitu z certifikátu a účet současně, což v praxi znamená ověřovací hák pro uživatelské jméno a heslo nebo tam načtený plugin. Podporovaný plugin, který už ověření hesla provádí, je obvykle správné místo pro přidání pravidla párování, protože nahradit ho porovnáním jmen by kontrolu hesla úplně zrušilo.

Definujte mapování dřív, než napíšete kód, protože rovnost je málokdy skutečná politika. Certifikát často identifikuje zařízení, zatímco přihlášení identifikuje osobu, a jedno zařízení může legitimně sloužit několika lidem. Vztah ukládejte ve formě, jejíž vydávání ovládáte, a rozhodněte, co se stane při přejmenování, při opětovném vydání a u jmen kvalifikovaných doménou. Převod doménové předpony na malá písmena nebo její odebrání bez porozumění adresáři může sloučit dva účty, které měly zůstat oddělené.

Nezapomeňte, že volba také mění, která konfigurace pro jednotlivé klienty platí, protože client-config-dir se klíčuje podle společného jména.

Otestujte párování se dvěma platnými údaji

Začněte párem, který vaše politika povoluje, a potvrďte, že se připojí. Pak předložte stejný platný certifikát s jiným, ale jinak platným účtem: ten pokus musí selhat, a musí selhat kvůli pravidlu párování, ne kvůli překlepu v hesle. Špatné heslo dokazuje, že kontrola hesla funguje, a nic neříká o pravidle mezi certifikátem a účtem.

Zkontrolujte také cestu chybějícího a neplatného certifikátu a potvrďte, kterou identitu server používá pro nastavení jednotlivých klientů. Pokud je jediným způsobem, jak porovnání zprovoznit, vypnout username-as-common-name, spočítejte nejdřív cenu této změny, protože vrací hledání konfigurace každého klienta zpět na jméno z certifikátu.