OpenVPN sûnder kliïntsertifikaat: serverbelied, net profyl

Jo wiskje de sertifikaat- en kaai-regels, jouwe it profyl oer, en de ferbining mislearret noch altyd mei in sertifikaatflater. It profyl wie nea it ding dat dy eask ôftwong. De server beslút oft in kliïntsertifikaat ferplicht is, en gjin bewurking oan de kliïntkant ûnderhannelet dat fuort. Dat de oplossing is in feroaring yn it serverbelied, mei opset dien, wêrby't alles dat dêrfan ôfhinget yn deselde pas bywurke wurdt.

It profyl is net it belied

Community OpenVPN 2.6 komt mei ferplichte kliïntsertifikaten, om't verify-client-cert standert require is. It ynstellen op none is wat de eask om in sertifikaat stopet en de kliïntautentikaasje oerdraacht oan hokker brûkersnamme-en-wachtwurd-regeling de server al draait. Aldere gidsen gripe nei client-cert-not-required, de ferâldere stavering fan itselde idee, dus brûk de rjochtline dy't jo ynstalleare ferzje dokumintearret. Hoe dan ek, de feroaring bart op de server, en gjin kliïntprofyl kin it útfiere.

It fragmint hjirûnder is de hiele feroaring oan de serverkant, en op himsels is it gjin wurkjende autentikaasjekonfiguraasje. verify-client-cert none hellet de sertifikaateask fuort, wylst username-as-common-name de kontonamme de identiteit makket dy't lettere callbacks en bestannen per kliïnt sjogge. Gjin fan beide regels kontrolearret in wachtwurd, dus moat der noch altyd in ferifiearder wêze.

verify-client-cert none
username-as-common-name

Dy ferifiearder is in plugin of in skript dat troch auth-user-pass-verify oandreaun wurdt, en it moat op syn plak wêze foardat ien fan 'e boppesteande regels wat betsjut. De oarder omdraaie jout jo in finster wêryn't de server gjin sertifikaat freget en gjin konto kontrolearret.

Wat de server noch ferifiearret

It fuortlitten fan it kliïntsertifikaat is net it fuortlitten fan TLS. De server hâldt syn sertifikaat en kaai, en de kliïnt hâldt it CA-fertrouwen en de hostnamme-kontrôles dy't him tsjinhâlde om mei in bedrager te praten. remote-cert-tls server of it CA-bondel fuortsmite om't de kliïnt gjin sertifikaat mear hat, is in algemiene en earnstige ferkearde lêzing, en de 2.6-referinsje is dúdlik dat de beide rjochtingen ûnôfhinklik binne. De iene bewiist de server oan de kliïnt; de oare bewiist de kliïnt oan de server.

In profyl kin ek in tls-auth- of tls-crypt-blok drage. Dat is in dielde kaai fan it kontrôlekanaal mei syn eigen ferspriedings- en rotaasjesyklus, dus in bestân sûnder sertifikaat- of kaai-regels is net automatysk feilich om te publisearjen. Behannelje it as in geheim oant jo it lêzen hawwe.

In sertifikaatbestân dat út in wurkjend profyl kopiearre is, bewiist op himsels neat; besit betsjut it priveekaai hâlden dat derby past, wat in sertifikaat-autentisearre útrôling kontrolearret. In bestân dat in sertifikaat befettet is gjin bestân wêrmei't jo jo autentisearje kinne.

Wat de ferifiearder dwaan moat

Mei de sertifikaateask fuort, rêstet alles op de ferifiearder: in plugin, of in skript dat troch auth-user-pass-verify oandreaun wurdt. It moat ûnjildige oanmeldgegevens ôfwize, útskeakele of net-geskikte konten ôfwize, en ticht mislearje as it syn backend net berikke kin. username-as-common-name wurdt faak dêrneist ynskeakele, en it feroaret de identiteit dy't lettere callbacks en konfiguraasjebestanden per kliïnt sjogge. It ferifiearret gjin wachtwurd, en it makket in net-geskikt konto net geskikt. Dat binne aparte taken, en se trochinoar helje is hoe't in migraasje syn happy-path-test hellet en by syn earste echte ynsidint mislearret.

Test de negatieve gefallen like soarchfâldich as it positive. In profyl dat in wachtwurdfraach lit sjen, bewiist allinnich dat de kliïnt in fraach tekenje kin, wylst in server dy't it ferkearde wachtwurd akseptearret eat folle slimmers bewiist. Foegje in útskeakele konto en in ferfallen oanmeldgegevens ta oan 'e testset, net allinnich in min wachtwurd.

Feroarje belied, profyl en mapping tagelyk

Koördinearje trije dingen: de serverrjochtline, it kliïntprofyl en de identiteitsmapping per kliïnt. Feroarje se apart en kliïnten mislearje foar de ferifikaasje, of ferbine ûnder in namme dy't de behearder net ferwachte, wat slimmer is om't it op súkses liket. In ferbining dy't slagget ûnder de ferkearde identiteit is hurder te merken as ien dy't mislearret.

Hâld twa testkonten foar dit paad, ien jildich en ien bekend min, en brûk beide nei elke feroaring oan 'e ferifiearder. It jildige konto bewiist it happy path en de identiteitsmapping; it minne bewiist dat it ôfwizen noch wurket. Gjin fan beide tests fertelt jo wat oer geskiktheidsregels, dus foegje in konto ta dat om beliedsredenen wegere wurde moat as de útrôling dy hat. Rin alle trije nei elke feroaring, want in ferifiearder dy't alles begjint te akseptearjen liket presys op in wurkjende oanmelding.

Registrearje hokker autentikaasjemetoaden de server eins akseptearret, net hokker it profyl suggerearret. Dat register beantwurdet de fraach dy't minsken hieltyd stelle, nammentlik wa't ferbine kin mei dizze tsjinst. It oerlibbet ek de folgjende behearder, dy't it oars út in pakketopname werûntdekke soe.