OpenVPN utan klientcertifikat: serverpolicy, ikkje profil

Du slettar sertifikat- og nøkkellinjene, overleverer profilen, og tilkoplinga feilar framleis med ein sertifikatfeil. Profilen var aldri det som handheva dette kravet. Serveren avgjer om eit klientcertifikat er obligatorisk, og inga endring på klientsida forhandlar det bort. Så rettinga er ei endring av serverpolicyen, gjort med vilje, med alt som avheng av han oppdatert i same omgang.

Profilen er ikkje policyen

Community OpenVPN 2.6 kjem med obligatoriske klientcertifikat, fordi verify-client-cert som standard er require. Å setje han til none er det som stoppar kravet om eit sertifikat og overlet klientautentiseringa til den brukarnamn- og passordordninga serveren allereie køyrer. Eldre rettleiarar grip etter client-cert-not-required, den forelda stavinga for same idé, så bruk direktivet den installerte versjonen din dokumenterer. Uansett skjer endringa på serveren, og ingen klientprofil kan utføre han.

Fragmentet nedanfor er heile endringa på serversida, og i seg sjølv er det ikkje ein fungerande autentiseringskonfigurasjon. verify-client-cert none fjernar sertifikatkravet, medan username-as-common-name gjer kontonamnet til den identiteten seinare tilbakekall og filer per klient ser. Ingen av linjene kontrollerer eit passord, så ein verifier må framleis finnast.

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

Den verifieren er ein plugin eller eit skript som blir styrt av auth-user-pass-verify, og det må vere på plass før noka av linjene ovanfor tyder noko. Snu du rekkjefølgja, får du eit vindauge der serveren ikkje ber om sertifikat og ikkje kontrollerer nokon konto.

Kva som framleis verifiserer serveren

Å droppe klientcertifikatet er ikkje å droppe TLS. Serveren held på sertifikatet og nøkkelen sin, og klienten held på CA-tilliten og vertsnamnkontrollane som hindrar han i å snakke med ein bedragar. Å fjerne remote-cert-tls server eller CA-pakken fordi klienten ikkje lenger har eit sertifikat er ein vanleg og alvorleg feillesing, og 2.6-referansen er tydeleg på at dei to retningane er uavhengige. Den eine beviser serveren overfor klienten; den andre beviser klienten overfor serveren.

Ein profil kan også innehalde ein tls-auth- eller tls-crypt-blokk. Det er ein delt nøkkel for kontrollkanalen med sin eigen distribusjons- og rotasjonssyklus, så ei fil utan sertifikat- eller nøkkellinjer er ikkje automatisk trygg å publisere. Handsame ho som ein hemmelegheit til du har lese ho.

Ei sertifikatfil kopiert ut av ein fungerande profil beviser ingenting i seg sjølv; å ha ho betyr å halde på den private nøkkelen som passar til ho, noko ein sertifikatautentisert utrulling kontrollerer. Ei fil som inneheld eit sertifikat, er ikkje ei fil ein kan autentisere seg med.

Kva verifieren må gjere

Når sertifikatkravet er fjerna, kviler alt på verifieren: ein plugin, eller eit skript som blir styrt av auth-user-pass-verify. Han må avvise ugyldige påloggingsdata, avvise deaktiverte eller ueigna kontoar og feile lukka når han ikkje når backend-en sin. username-as-common-name blir ofte aktivert ved sida av, og det endrar identiteten seinare tilbakekall og konfigurasjonsfiler per klient ser. Det verifiserer ikkje eit passord og gjer ikkje ein ueigna konto eigna. Det er separate oppgåver, og å blande dei er måten ein migrasjon består lukkeprøva og feilar ved si første verkelege hending.

Test dei negative tilfella like nøye som det positive. Ein profil som viser ei passordforespurnad beviser berre at klienten kan teikne ei forespurnad, medan ein server som godtek feil passord beviser noko monaleg verre. Legg til ein deaktivert konto og ein utløpt påloggingsdetalj i testsettet, ikkje berre eit dårleg passord.

Endre policy, profil og mapping saman

Koordiner tre ting: serverdirektivet, klientprofilen og identitetsmappinga per klient. Endre dei kvar for seg, og klientar feilar før verifiseringa, eller koplar til under eit namn administratoren ikkje forventa, noko som er verre fordi det ser ut som suksess. Ei tilkopling som lukkast under feil identitet er vanskelegare å leggje merke til enn ei som feilar.

Hald to testkontoar til denne vegen, ein gyldig og ein kjend dårleg, og bruk begge etter kvar endring av verifieren. Den gyldige kontoen beviser lukkeprøva og identitetsmappinga; den dårlege beviser at avvisinga framleis verkar. Ingen av testane seier deg noko om eigneregler, så legg til ein konto som bør avvisast av policygrunnar viss utrullinga har dei. Køyr alle tre etter kvar endring, fordi ein verifier som byrjar å godta alt, ser nøyaktig ut som ei fungerande innlogging.

Registrer kva autentiseringsmetodar serveren faktisk godtek, ikkje kva profilen antydar. Den registreringa svarar på spørsmålet folk held fram med å stille, nemleg kven som kan kople til denne tenesta. Ho overlever også den neste administratoren, som elles ville gjenoppdage ho frå eit pakkeopptak.