OpenVPN username-as-common-name: zašto je vaša provjera CN prazna

Dodajete skriptu client-connect koja odbija svaku vezu u kojoj se common_name razlikuje od username, i to izgleda kao veza između certifikata i računa. Na poslužitelju koji pokreće username-as-common-name, ta je usporedba već izgubila smisao dok se skripta pokrene. Obje vrijednosti su isti niz znakova, pa test prolazi za certifikat izdan sasvim nekoj drugoj osobi.

Provjera nije pogrešna zato što je skripta loše napisana. Pogrešna je zato što je vrijednost koju čita zamijenjena ranije u istoj vezi.

Što usporedba kao da dokazuje

Autentikacija certifikatom i autentikacija lozinkom odvojeni su dokazi, a poslužitelj može zahtijevati oboje bez zahtjeva da pripadaju istoj osobi. Razlika je stvarna: valjan certifikat uređaja plus bilo koji valjan račun drugačiji je zahtjev od tog certifikata uređaja plus jednog imenovanog računa. Skripta koja uspoređuje common_name s username čita se kao karika koja nedostaje između njih. Bila bi to, kad bi common_name još značilo ono što je certifikat rekao.

Je li tako, ovisi o jednoj opciji poslužitelja, a ta se opcija obično uključuje zbog nepovezanog razloga, primjerice da se konfiguracijske datoteke po korisniku lakše imenuju.

Što username-as-common-name čini s imenom

Uz uključen username-as-common-name, OpenVPN zamjenjuje uobičajeno ime certifikata autentificiranim korisničkim imenom nakon što se korisničko ime i lozinka provjere. Kuka za provjeru koja se izvršava tijekom te provjere još uvijek prima uobičajeno ime certifikata, jer se zamjena još nije dogodila. Sve nakon toga, uključujući client-connect, vidi korisničko ime. Zato kasniji povratni poziv prima jedan identitet dva puta i ne može ga usporediti s predstavljenim certifikatom.

Pratite jednu ilustrativnu vezu: certifikat izdan za bob-device, uspješna prijava u imenik kao alice i uključena opcija. Faza provjere još može vidjeti dva različita niza znakova. Faza povezivanja vidi alice i alice.

Taj primjer pokazuje zašto je usporedba prazna. Ne pokazuje da bi veza inače bila prihvaćena, jer provjera certifikata i provjera lozinke i dalje rade same.

Postavite vezu tamo gdje oba identiteta još postoje

Pravilo se mora provoditi u fazi koja vidi identitet certifikata i račun istodobno, što u praksi znači kuku za provjeru korisničkog imena i lozinke ili ondje učitani dodatak. Podržani dodatak koji već obavlja provjeru lozinke obično je pravo mjesto za dodavanje pravila uparivanja, jer bi njegova zamjena usporedbom imena u potpunosti uklonila provjeru lozinke.

Definirajte mapiranje prije pisanja koda, jer jednakost rijetko je stvarna politika. Certifikat često identificira uređaj, dok prijava identificira osobu, a jedan uređaj može legitimno služiti više ljudi. Pohranite odnos u obliku čije izdavanje kontrolirate i odlučite što se događa pri preimenovanju, ponovnom izdavanju i kod imena s kvalifikacijom domene. Pretvaranje u mala slova ili uklanjanje prefiksa domene bez razumijevanja imenika može spojiti dva računa koji su trebali ostati odvojeni.

Imajte na umu da opcija također mijenja koja se konfiguracija po klijentu primjenjuje, jer je client-config-dir vezan uz uobičajeno ime.

Testirajte uparivanje s dvama valjanim vjerodajnicama

Počnite s parom koji vaša politika dopušta i potvrdite da se povezuje. Zatim predstavite isti valjani certifikat s drugim, ali inače valjanim računom: taj pokušaj mora propasti, i mora propasti zbog pravila uparivanja, a ne zbog pogrešno upisane lozinke. Pogrešna lozinka dokazuje da provjera lozinke radi i ne govori ništa o pravilu između certifikata i računa.

Provjerite i putanje bez certifikata i s nevaljalim certifikatom te potvrdite koji identitet poslužitelj koristi za postavke po klijentu. Ako je jedini način da usporedba radi isključivanje username-as-common-name, prvo procijenite cijenu te promjene, jer ona svako traženje konfiguracije po klijentu vraća na ime certifikata.