OpenVPN username-as-common-name: hvorfor CN-kontrollen din er tom

Du legger til et client-connect-skript som avviser hver tilkobling der common_name er forskjellig fra username, og det ser ut som en binding mellom et sertifikat og en konto. På en server som kjører username-as-common-name, har den sammenligningen allerede mistet betydningen sin når skriptet kjører. Begge verdiene er den samme strengen, så testen passerer for et sertifikat som er utstedt til en helt annen person.

Kontrollen er ikke feil fordi skriptet er dårlig skrevet. Den er feil fordi verdien den leser ble erstattet tidligere i samme tilkobling.

Hva sammenligningen ser ut til å bevise

Sertifikatautentisering og passordautentisering er separate bevis, og en server kan kreve begge uten å kreve at de tilhører samme person. Gapet er reelt: et gyldig enhetssertifikat pluss en hvilken som helst gyldig konto er en annen påstand enn det sertifikatet pluss én navngitt konto. Et skript som sammenligner common_name med username, leses som det manglende leddet mellom de to. Det ville det være, hvis common_name fortsatt betydde det sertifikatet sa.

Om det er tilfellet avhenger av ett serveralternativ, og det alternativet slås vanligvis på av en urelatert grunn, for eksempel at konfigurasjonsfilene per bruker skal være enklere å navngi.

Hva username-as-common-name gjør med navnet

Med username-as-common-name aktivert erstatter OpenVPN sertifikatets vanlige navn med det autentiserte brukernavnet når brukernavnet og passordet er verifisert. Verifiseringskroken som kjører under den kontrollen mottar fortsatt sertifikatets vanlige navn, fordi erstatningen ennå ikke har skjedd. Alt etterpå, inkludert client-connect, ser brukernavnet. Dermed mottar det senere tilbakekallet én identitet to ganger og kan ikke sammenligne den med sertifikatet som ble presentert.

Følg én illustrerende tilkobling: et sertifikat utstedt for bob-device, en vellykket kataloginnlogging som alice, og alternativet aktivert. Verifiseringsfasen kan fortsatt se to forskjellige strenger. Tilkoblingsfasen ser alice og alice.

Det eksempelet viser hvorfor sammenligningen er tom. Det viser ikke at tilkoblingen ellers ville blitt akseptert, siden sertifikatvalidering og passordverifisering fortsatt kjører for seg selv.

Plasser bindingen der begge identitetene fortsatt finnes

Regelen må håndheves i en fase som ser sertifikatets identitet og kontoen samtidig, noe som i praksis betyr verifiseringskroken for brukernavn og passord eller en plugin som lastes der. En støttet plugin som allerede utfører passordverifisering er vanligvis det riktige stedet å legge til en paringsregel, fordi å erstatte den med en navnesammenligning ville fjerne passordkontrollen helt.

Definer tilordningen før du skriver kode, siden likhet sjelden er den virkelige policyen. Et sertifikat identifiserer ofte en enhet mens innloggingen identifiserer en person, og én enhet kan lovlig betjene flere personer. Lagre forholdet i en form der du kontrollerer utstedelsen, og avgjør hva som skjer ved omdøping, ved nyutstedelse og med domenekvalifiserte navn. Å gjøre om til små bokstaver eller fjerne et domeneprefiks uten å forstå katalogen kan slå sammen to kontoer som skulle holdes atskilt.

Husk at alternativet også endrer hvilken konfigurasjon per klient som gjelder, fordi client-config-dir er nøklet på det vanlige navnet.

Test paringen med to gyldige legitimasjoner

Start med paret policyen din tillater og bekreft at det kobles til. Presenter deretter det samme gyldige sertifikatet med en annen, men ellers gyldig konto: det forsøket må mislykkes, og det må mislykkes på grunn av paringsregelen og ikke på grunn av et feilskrevet passord. Et feil passord beviser at passordkontrollen virker og sier ingenting om regelen mellom sertifikat og konto.

Sjekk også banene med manglende sertifikat og ugyldig sertifikat, og bekreft hvilken identitet serveren bruker for innstillinger per klient. Hvis den eneste måten å få sammenligningen til å virke er å slå av username-as-common-name, prissett den endringen først, fordi den flytter all konfigurasjonsoppslag per klient tilbake til sertifikatets navn.