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

Du tilføjer et client-connect-script, der afviser enhver forbindelse, hvor common_name afviger fra username, og det ligner en kobling mellem et certifikat og en konto. På en server, der kører username-as-common-name, har den sammenligning allerede mistet sin betydning, når scriptet kører. Begge værdier er den samme streng, så testen består for et certifikat, der er udstedt til en helt anden person.

Kontrollen er ikke forkert, fordi scriptet er dårligt skrevet. Den er forkert, fordi den værdi, den læser, blev erstattet tidligere i samme forbindelse.

Hvad sammenligningen ser ud til at bevise

Certifikatautentificering og adgangskodeautentificering er to separate beviser, og en server kan kræve begge uden at kræve, at de tilhører samme person. Forskellen er reel: et gyldigt enhedscertifikat plus enhver gyldig konto er en anden påstand end det samme certifikat plus én navngivet konto. Et script, der sammenligner common_name med username, lyder som det manglende led mellem de to. Og det ville det være, hvis common_name stadig betød det, certifikatet sagde.

Om det er tilfældet afhænger af én serverindstilling, og den indstilling er normalt slået til af en urelateret grund, for eksempel at gøre det lettere at navngive konfigurationsfiler pr. bruger.

Hvad username-as-common-name gør ved navnet

Når username-as-common-name er aktiveret, erstatter OpenVPN certifikatets fælles navn med det autentificerede brugernavn, når brugernavn og adgangskode er verificeret. Verifikationshooket, der kører under den kontrol, modtager stadig certifikatets fælles navn, fordi erstatningen endnu ikke er sket. Alt derefter, inklusive client-connect, ser brugernavnet. Så det senere callback modtager én identitet to gange og kan ikke sammenligne den med det certifikat, der blev præsenteret.

Følg én illustrativ forbindelse: et certifikat udstedt til bob-device, et vellykket kataloglogin som alice og indstillingen aktiveret. Verifikationstrinnet kan stadig se to forskellige strenge. Forbindelsestrinnet ser alice og alice.

Det eksempel viser, hvorfor sammenligningen er tom. Det viser ikke, at forbindelsen ellers ville blive accepteret, da certifikatvalidering og adgangskodeverifikation stadig kører for sig selv.

Anbring koblingen, hvor begge identiteter stadig findes

Reglen skal håndhæves på et trin, der ser certifikatidentiteten og kontoen samtidig, hvilket i praksis betyder verifikationshooket for brugernavn og adgangskode eller et plugin, der indlæses der. Et understøttet plugin, der allerede udfører adgangskodeverifikation, er normalt det rigtige sted at tilføje en parringsregel, fordi en erstatning med en navnesammenligning helt ville droppe adgangskodekontrollen.

Definér mappingen, før du skriver kode, da lighed sjældent er den egentlige politik. Et certifikat identificerer ofte en enhed, mens login identificerer en person, og én enhed kan lovligt betjene flere personer. Opbevar forholdet i en form, hvis udstedelse du kontrollerer, og beslut, hvad der sker ved omdøbning, ved genudstedelse og ved domænekvalificerede navne. At gøre et domænepræfiks til små bogstaver eller fjerne det uden at forstå kataloget kan slå to konti sammen, som skulle forblive adskilte.

Husk, at indstillingen også ændrer, hvilken konfiguration pr. klient der gælder, fordi client-config-dir nøgles på det fælles navn.

Test parringen med to gyldige legitimationsoplysninger

Begynd med det par, din politik tillader, og bekræft, at det opretter forbindelse. Præsentér derefter det samme gyldige certifikat med en anden, men ellers gyldig konto: det forsøg skal mislykkes, og det skal mislykkes på grund af parringsreglen, ikke på grund af en forkert indtastet adgangskode. En forkert adgangskode beviser, at adgangskodekontrollen virker, og siger intet om reglen mellem certifikat og konto.

Kontrollér også stierne for manglende og ugyldigt certifikat, og bekræft, hvilken identitet serveren bruger til indstillinger pr. klient. Hvis den eneste måde at få sammenligningen til at virke er at deaktivere username-as-common-name, skal du først beregne prisen for den ændring, fordi den flytter hver klients konfigurationsopslag tilbage til certifikatnavnet.