OpenVPN uten klientcertifikat: serverpolicy, ikke profil

Du sletter sertifikat- og nøkkellinjene, overleverer profilen, og tilkoblingen feiler fortsatt med en sertifikatfeil. Profilen var aldri det som håndhevet dette kravet. Serveren avgjør om et klientcertifikat er obligatorisk, og ingen endring på klientsiden forhandler det bort. Så rettelsen er en endring av serverpolicyen, gjort med vilje, med alt som avhenger av den oppdatert i samme omgang.

Profilen er ikke policyen

Community OpenVPN 2.6 leveres med obligatoriske klientcertifikater, fordi verify-client-cert som standard er require. Å sette den til none er det som stopper kravet om et sertifikat og overlater klientautentiseringen til den brukernavn- og passordordningen serveren allerede kjører. Eldre veiledninger griper etter client-cert-not-required, den foreldede stavemåten for samme idé, så bruk direktivet den installerte versjonen din dokumenterer. Uansett skjer endringen på serveren, og ingen klientprofil kan utføre den.

Fragmentet nedenfor er hele endringen på serversiden, og i seg selv er det ikke en fungerende autentiseringskonfigurasjon. verify-client-cert none fjerner sertifikatkravet, mens username-as-common-name gjør kontonavnet til den identiteten senere tilbakekall og filer per klient ser. Ingen av linjene kontrollerer et passord, så en verifier må fortsatt finnes.

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

Den verifieren er en plugin eller et skript som styres av auth-user-pass-verify, og det må være på plass før noen av linjene ovenfor betyr noe. Reverserer du rekkefølgen, får du et vindu der serveren ikke ber om sertifikat og ikke kontrollerer noen konto.

Hva som fortsatt verifiserer serveren

Å droppe klientcertifikatet er ikke å droppe TLS. Serveren beholder sertifikatet og nøkkelen sin, og klienten beholder CA-tilliten og vertsnavnkontrollene som hindrer den i å snakke med en bedrager. Å fjerne remote-cert-tls server eller CA-pakken fordi klienten ikke lenger har et sertifikat er en vanlig og alvorlig feillesning, og 2.6-referansen er tydelig på at de to retningene er uavhengige. Den ene beviser serveren overfor klienten; den andre beviser klienten overfor serveren.

En profil kan også inneholde en tls-auth- eller tls-crypt-blokk. Det er en delt nøkkel for kontrollkanalen med sin egen distribusjons- og rotasjonssyklus, så en fil uten sertifikat- eller nøkkellinjer er ikke automatisk trygg å publisere. Behandle den som en hemmelighet til du har lest den.

En sertifikatfil kopiert ut av en fungerende profil beviser ingenting i seg selv; besittelse betyr å holde den private nøkkelen som passer til den, noe en sertifikatautentisert utrulling kontrollerer. En fil som inneholder et sertifikat, er ikke en fil man kan autentisere med.

Hva verifieren må gjøre

Når sertifikatkravet er fjernet, hviler alt på verifieren: en plugin, eller et skript som styres av auth-user-pass-verify. Den må avvise ugyldige påloggingsdata, avvise deaktiverte eller uegnede kontoer og feile lukket når den ikke når backend-en sin. username-as-common-name aktiveres ofte ved siden av, og det endrer identiteten senere tilbakekall og konfigurasjonsfiler per klient ser. Det verifiserer ikke et passord og gjør ikke en uegnet konto egnet. Det er separate oppgaver, og å blande dem er måten en migrering består lykkeprøven og feiler ved sin første virkelige hendelse.

Test de negative tilfellene like nøye som det positive. En profil som viser en passordforespørsel beviser bare at klienten kan tegne en forespørsel, mens en server som godtar feil passord beviser noe betydelig verre. Legg til en deaktivert konto og en utløpt påloggingsdetalj i testsettet, ikke bare et dårlig passord.

Endre policy, profil og mapping sammen

Koordiner tre ting: serverdirektivet, klientprofilen og identitetsmappingen per klient. Endre dem hver for seg, og klienter feiler før verifiseringen, eller kobler til under et navn administratoren ikke forventet, noe som er verre fordi det ser ut som suksess. En tilkobling som lykkes under feil identitet er vanskeligere å legge merke til enn en som feiler.

Hold to testkontoer til denne veien, en gyldig og en kjent dårlig, og bruk begge etter enhver endring av verifieren. Den gyldige kontoen beviser lykkeprøven og identitetsmappingen; den dårlige beviser at avvisningen fortsatt virker. Ingen av testene sier deg noe om egnethetsregler, så legg til en konto som bør avvises av policygrunner hvis utrullingen har dem. Kjør alle tre etter hver endring, fordi en verifier som begynner å godta alt, ser nøyaktig ut som en fungerende innlogging.

Registrer hvilke autentiseringsmetoder serveren faktisk godtar, ikke hvilke profilen antyder. Den registreringen svarer på spørsmålet folk fortsetter å stille, nemlig hvem som kan koble til denne tjenesten. Den overlever også den neste administratoren, som ellers ville gjenoppdage den fra et pakkeopptak.