OpenVPN username-as-common-name: waarom je CN-controle leeg is

Je voegt een client-connect-script toe dat elke verbinding weigert waarin common_name verschilt van username, en het lijkt een koppeling tussen een certificaat en een account. Op een server die username-as-common-name draait, heeft die vergelijking al haar betekenis verloren tegen de tijd dat het script draait. Beide waarden zijn dezelfde tekenreeks, dus de test slaagt voor een certificaat dat aan iemand heel anders is uitgegeven.

De controle is niet fout omdat het script slecht is geschreven. Ze is fout omdat de waarde die het leest eerder in dezelfde verbinding is vervangen.

Wat de vergelijking lijkt te bewijzen

Certificaatauthenticatie en wachtwoordauthenticatie zijn afzonderlijke bewijzen, en een server kan beide eisen zonder te eisen dat ze bij dezelfde persoon horen. De kloof is reëel: een geldig apparaatcertificaat plus elk geldig account is een andere bewering dan dat certificaat plus één genoemd account. Een script dat common_name met username vergelijkt, leest als de ontbrekende schakel tussen beide. Dat zou het zijn, als common_name nog steeds betekende wat het certificaat zei.

Of dat zo is, hangt van één serveroptie af, en die optie wordt meestal om een ongerelateerde reden aangezet, bijvoorbeeld om configuratiebestanden per gebruiker makkelijker te kunnen benoemen.

Wat username-as-common-name met de naam doet

Met username-as-common-name ingeschakeld vervangt OpenVPN de common name van het certificaat door de geauthenticeerde gebruikersnaam zodra de gebruikersnaam en het wachtwoord zijn geverifieerd. De verificatiehook die tijdens die controle draait, ontvangt nog steeds de common name van het certificaat, omdat de vervanging nog niet heeft plaatsgevonden. Alles daarna, inclusief client-connect, ziet de gebruikersnaam. Zo ontvangt de latere callback één identiteit twee keer en kan die niet vergelijken met het certificaat dat is aangeboden.

Volg één illustratieve verbinding: een certificaat uitgegeven voor bob-device, een geslaagde directory-login als alice, en de optie ingeschakeld. De verificatiefase kan nog twee verschillende tekenreeksen zien. De verbindingsfase ziet alice en alice.

Dat voorbeeld laat zien waarom de vergelijking leeg is. Het laat niet zien dat de verbinding anders wel zou worden geaccepteerd, omdat certificaatvalidatie en wachtwoordverificatie nog zelfstandig draaien.

Plaats de koppeling waar beide identiteiten nog bestaan

De regel moet worden afgedwongen in een fase die de identiteit van het certificaat en het account tegelijk ziet, wat in de praktijk de verificatiehook voor gebruikersnaam en wachtwoord betekent of een plug-in die daar wordt geladen. Een ondersteunde plug-in die al wachtwoordverificatie uitvoert, is meestal de juiste plek om een koppelingsregel toe te voegen, omdat het vervangen ervan door een naamvergelijking de wachtwoordcontrole volledig zou weghalen.

Definieer de mapping voordat je code schrijft, want gelijkheid is zelden het echte beleid. Een certificaat identificeert vaak een apparaat terwijl de login een persoon identificeert, en één apparaat kan legaal meerdere personen bedienen. Sla de relatie op in een vorm waarvan je de uitgifte beheert, en beslis wat er gebeurt bij hernoemen, bij heruitgifte en bij met een domein gekwalificeerde namen. Kleine letters gebruiken of een domeinprefix verwijderen zonder de directory te begrijpen kan twee accounts samenvoegen die apart moesten blijven.

Bedenk dat de optie ook verandert welke configuratie per client geldt, omdat client-config-dir op de common name is gesleuteld.

Test de koppeling met twee geldige inloggegevens

Begin met het paar dat je beleid toestaat en bevestig dat het verbindt. Bied daarna hetzelfde geldige certificaat aan met een ander maar verder geldig account: die poging moet mislukken, en ze moet mislukken door de koppelingsregel en niet door een verkeerd getypt wachtwoord. Een fout wachtwoord bewijst dat de wachtwoordcontrole werkt en zegt niets over de regel tussen certificaat en account.

Controleer ook de paden zonder certificaat en met een ongeldig certificaat, en bevestig welke identiteit de server voor instellingen per client gebruikt. Als de enige manier om de vergelijking te laten werken het uitschakelen van username-as-common-name is, begroot die wijziging dan eerst, want ze verplaatst het opzoeken van de configuratie van elke client terug naar de naam van het certificaat.