OpenVPN uten klientcertifikat: serverpolitikk, ikke profil

Du sletter sertifikat- og nøkkellinjene, overleverer profilen, og tilkoblingen feiler fortsatt med en sertifikatfeil. Profilen har aldri vært det som håndhevet dette kravet. Det er serveren som avgjør om et klientcertifikat er obligatorisk, og ingen endring på klientsiden forhandler det vekk. Rettelsen er altså en endring av serverpolitikken, gjort bevisst, med alt som avhenger av den oppdatert i samme runde.

Profilen er ikke politikken

Community OpenVPN 2.6 leveres med obligatoriske klientcertifikater, siden verify-client-cert som standard er require. Det er innstillingen på none som stopper kravet om sertifikat og overlater klientautentiseringen til den brukernavn- og passordordningen serveren allerede driver. Gamle veiledninger griper til client-cert-not-required, den utdaterte skrivemåten for samme idé, så bruk direktivet som din installerte versjon dokumenterer. Uansett skjer endringen på serveren, og ingen klientprofil kan utføre den.

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

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

Den verifikatoren er en plugin eller et skript styrt av auth-user-pass-verify, og den må være på plass før noen av linjene ovenfor betyr noe. Snur du rekkefølgen, får du et vindu der serveren ikke ber om sertifikat og ikke sjekker noen konto.

Hva som fortsatt verifiserer serveren

Å droppe klientcertifikatet betyr 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 sertifikat, er en vanlig og alvorlig feillesning, og 2.6-referansen sier tydelig at de to retningene er uavhengige. Den ene beviser serveren for klienten; den andre beviser klienten for 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 sjekker. En fil som inneholder et sertifikat, er ikke en fil man kan autentisere seg med.

Hva verifikatoren må gjøre

Når sertifikatkravet er fjernet, hviler alt på verifikatoren: en plugin, eller et skript styrt 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 tilbakeringinger og konfigurasjonsfiler per klient ser. Den 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 grundig 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 et 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. Endrer du dem hver for seg, feiler klientene 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 verifikatoren. 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 verifikator 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.