OpenVPN sonder ’n kliëntsertifikaat: bedienerbeleid, nie profiel nie

Jy verwyder die sertifikaat- en sleutelreëls, gee die profiel oor, en die verbinding misluk steeds met ’n sertifikaatfout. Die profiel was nooit die ding wat daardie vereiste afgedwing het nie. Die bediener besluit of ’n kliëntsertifikaat verpligtend is, en geen wysiging aan die kliëntkant beding dit weg nie. Die oplossing is dus ’n verandering aan die bedienerbeleid, doelbewus gedoen, met alles wat daarvan afhang in dieselfde rondte opgedateer.

Die profiel is nie die beleid nie

Community OpenVPN 2.6 kom met verpligte kliëntsertifikate, want verify-client-cert is by verstek require. Om dit op none te stel, is wat die eis om ’n sertifikaat stop en kliëntverifikasie oorhandig aan watter gebruikersnaam-en-wagwoord-reëling die bediener reeds gebruik. Ouer gidse gryp na client-cert-not-required, die ouer spelling van dieselfde idee, dus gebruik die direktief wat jou geïnstalleerde weergawe dokumenteer. In elk geval vind die verandering op die bediener plaas, en geen kliëntprofiel kan dit uitvoer nie.

Die fragment hieronder is die hele verandering aan die bedienerkant, en op sigself is dit nie ’n werkende verifikasiekonfigurasie nie. verify-client-cert none verwyder die sertifikaatvereiste, terwyl username-as-common-name die rekeningnaam die identiteit maak wat latere terugroepe en per-kliënt-lêers sien. Nie een van die reëls kontroleer ’n wagwoord nie, so ’n verifieerder moet steeds bestaan.

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

Daardie verifieerder is ’n inprop of ’n skrip wat deur auth-user-pass-verify gedryf word, en dit moet in plek wees voordat enige van die twee reëls hierbo iets beteken. Om die volgorde om te keer gee jou ’n venster waarin die bediener geen sertifikaat vra nie en geen rekening kontroleer nie.

Wat die bediener steeds verifieer

Om die kliëntsertifikaat te laat val, laat nie TLS val nie. Die bediener hou sy sertifikaat en sleutel, en die kliënt hou die CA-vertroue en gasheernaamkontroles wat verhoed dat hy met ’n bedrieër praat. Om remote-cert-tls server of die CA-bondel te verwyder omdat die kliënt nie meer ’n sertifikaat het nie, is ’n algemene en ernstige waninterpretasie, en die 2.6-verwysing is duidelik dat die twee rigtings onafhanklik is. Die een bewys die bediener aan die kliënt; die ander bewys die kliënt aan die bediener.

’n Profiel kan ook ’n tls-auth- of tls-crypt-blok bevat. Dit is ’n gedeelde beheerkanaalsleutel met sy eie verspreidings- en rotasiesiklus, so ’n lêer sonder sertifikaat- of sleutelreëls is nie outomaties veilig om te publiseer nie. Behandel dit as ’n geheim totdat jy dit gelees het.

’n Sertifikaatlêer wat uit ’n werkende profiel gekopieer is, bewys op sigself niks; besit beteken om die privaatsleutel te hou wat daarby pas, waarvoor ’n sertifikaatgeverifieerde ontplooiing kontroleer. ’n Lêer wat ’n sertifikaat bevat, is nie ’n lêer waarmee jy kan verifieer nie.

Wat die verifieerder moet doen

Met die sertifikaatvereiste verwyder, rus alles op die verifieerder: ’n inprop, of ’n skrip wat deur auth-user-pass-verify gedryf word. Dit moet ongeldige geloofsbriewe verwerp, uitgeskakel of onbevoegde rekeninge verwerp, en toe misluk wanneer dit sy backend nie kan bereik nie. username-as-common-name word dikwels saam geaktiveer, en dit verander die identiteit wat latere terugroepe en per-kliënt-konfigurasielêers sien. Dit verifieer nie ’n wagwoord nie, en dit maak nie ’n onbevoegde rekening bevoeg nie. Dit is afsonderlike take, en om hulle te verwar, is hoe ’n migrasie sy gelukkige-pad-toets slaag en sy eerste werklike voorval misluk.

Toets die negatiewe gevalle net so sorgvuldig as die positiewe een. ’n Profiel wat ’n wagwoordprompt wys, bewys net dat die kliënt ’n prompt kan teken, terwyl ’n bediener wat die verkeerde wagwoord aanvaar, iets aansienlik erger bewys. Voeg ’n uitgeskakelde rekening en ’n verstreke geloofsbrief by die toetsstel, nie net ’n slegte wagwoord nie.

Verander die beleid, profiel en kartering saam

Koördineer drie dinge: die bedienerdirektief, die kliëntprofiel en die per-kliënt-identiteitskartering. Verander hulle afsonderlik en kliënte misluk voor verifikasie, of verbind onder ’n naam wat die administrateur nie verwag het nie, wat erger is omdat dit soos sukses lyk. ’n Verbinding wat onder die verkeerde identiteit slaag, is moeiliker raak te sien as een wat misluk.

Hou twee toetsrekeninge vir hierdie pad, ’n geldige een en ’n bekende slegte een, en gebruik albei na enige verandering aan die verifieerder. Die geldige rekening bewys die gelukkige pad en die identiteitskartering; die slegte een bewys dat verwerping steeds werk. Nie een toets sê iets oor bevoegdheidsreëls nie, so voeg ’n rekening by wat om beleidsredes geweier moet word as die ontplooiing dit het. Voer al drie na elke verandering uit, want ’n verifieerder wat alles begin aanvaar, lyk presies soos ’n werkende aanmelding.

Teken aan watter verifikasiemetodes die bediener werklik aanvaar, nie watter een die profiel voorstel nie. Daardie rekord beantwoord die vraag wat mense aanhoudend vra, naamlik wie by hierdie diens kan aansluit. Dit oorleef ook die volgende administrateur, wat dit andersins uit ’n pakketopname sal herontdek.