OpenVPN username-as-common-name: kvifor CN-kontrollen din er tom
Eit client-connect-skript som samanliknar common_name med username kan samanlikne eit namn med seg sjølv. Bind sertifikatet til kontoen før erstatninga vert køyrd.
Du legg til eit client-connect-skript som avviser kvar tilkobling der common_name er forskjellig frå username, og det ser ut som ei binding mellom eit sertifikat og ein konto. På ein server som køyrer username-as-common-name, har den samanlikninga allereie mista tydinga si når skriptet køyrer. Begge verdiane er den same strengen, så testen går gjennom for eit sertifikat som er utskrive til ein heilt annan person.
Kontrollen er ikkje feil fordi skriptet er dårleg skrive. Han er feil fordi verdien det les vart erstatta tidlegare i same tilkobling.
Kva samanlikninga ser ut til å bevise
Sertifikatautentisering og passordautentisering er separate bevis, og ein server kan krevje begge utan å krevje at dei høyrer til same person. Gapet er reelt: eit gyldig einingarsertifikat pluss kva som helst gyldig konto er eit anna påstand enn det sertifikatet pluss éin namngjeven konto. Eit skript som samanliknar common_name med username, vert lese som den manglande lenkja mellom dei to. Det ville det vere, om common_name framleis tydde det sertifikatet sa.
Om det er tilfellet kjem an på eit serverval, og det valet vert vanlegvis slått på av ein urelatert grunn, til dømes at konfigurasjonsfilene per brukar skal vere enklare å namngje.
Kva username-as-common-name gjer med namnet
Med username-as-common-name slått på erstattar OpenVPN det vanlege namnet på sertifikatet med det autentiserte brukarnamnet når brukarnamnet og passordet er stadfesta. Stadfestingskroken som køyrer under den kontrollen får framleis det vanlege namnet på sertifikatet, fordi erstatninga enno ikkje har skjedd. Alt etterpå, inkludert client-connect, ser brukarnamnet. Dermed får det seinare tilbakekallet éin identitet to gonger og kan ikkje samanlikne han med sertifikatet som vart lagt fram.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
Fylg éi illustrerande tilkobling: eit sertifikat utskrive for bob-device, ei vellukka kataloginnlogging som alice, og valet slått på. Stadfestingsfasen kan framleis sjå to ulike strengar. Tilkoblingsfasen ser alice og alice.
Det dømet viser kvifor samanlikninga er tom. Det viser ikkje at tilkoblinga elles ville vorte godteken, sidan sertifikatvalidering og passordstadfesting framleis køyrer for seg sjølve.
Plasser bindinga der begge identitetane framleis finst
Regelen må handhevast i ein fase som ser identiteten til sertifikatet og kontoen samstundes, noko som i praksis tyder stadfestingskroken for brukarnamn og passord eller ein plugin som vert lasta der. Ein støtta plugin som allereie gjer passordstadfesting er vanlegvis rett stad å leggje til ein paringsregel, fordi å byte han ut med ei namnesamanlikning ville fjerne passordkontrollen heilt.
Definer tilordninga før du skriv kode, sidan likskap sjeldan er den verkelege policyen. Eit sertifikat identifiserer ofte eit apparat medan innlogginga identifiserer ein person, og eitt apparat kan lovleg tene fleire personar. Lagre tilhøvet i ei form der du kontrollerer utgivinga, og avgjer kva som skjer ved omdøyping, ved nyutgiving og med domenekvalifiserte namn. Å gjere om til små bokstavar eller fjerne eit domeneprefiks utan å forstå katalogen kan slå saman to kontoar som skulle haldast åtskilde.
Hugs at valet òg endrar kva konfigurasjon per klient som gjeld, fordi client-config-dir er nøkla på det vanlege namnet.
Test paringa med to gyldige legitimasjonar
Start med paret policyen din tillèt og stadfest at det koplar til. Legg så fram det same gyldige sertifikatet med ein annan, men elles gyldig konto: det forsøket må mislukkast, og det må mislukkast på grunn av paringsregelen og ikkje på grunn av eit feilskrive passord. Eit feil passord beviser at passordkontrollen verkar og seier ingenting om regelen mellom sertifikat og konto.
Sjekk òg banene med manglande sertifikat og ugyldig sertifikat, og stadfest kva identitet serveren brukar for innstillingar per klient. Viss den einaste måten å få samanlikninga til å verke er å slå av username-as-common-name, prisar du den endringa først, fordi ho flyttar alt konfigurasjonsoppslag per klient tilbake til namnet på sertifikatet.