OpenVPN uden klientcertifikat: serverpolitik, ikke profil

Du sletter certifikat- og nøglelinjerne, udleverer profilen, og forbindelsen fejler stadig med en certifikatfejl. Profilen var aldrig det, der håndhævede dette krav. Serveren afgør, om et klientcertifikat er obligatorisk, og ingen ændring på klientsiden forhandler det væk. Så rettelsen er en ændring af serverpolitikken, foretaget bevidst, med alt, der afhænger af den, opdateret i samme omgang.

Profilen er ikke politikken

Community OpenVPN 2.6 leveres med obligatoriske klientcertifikater, fordi verify-client-cert som standard er require. At sætte den til none er det, der stopper kravet om et certifikat og overlader klientautentificeringen til den brugernavn- og adgangskodeordning, serveren allerede kører. Ældre vejledninger griber efter client-cert-not-required, den forældede stavemåde for den samme idé, så brug det direktiv, din installerede version dokumenterer. Uanset hvad sker ændringen på serveren, og ingen klientprofil kan udføre den.

Fragmentet nedenfor er hele ændringen på serversiden, og i sig selv er det ikke en fungerende autentificeringskonfiguration. verify-client-cert none fjerner certifikatkravet, mens username-as-common-name gør kontonavnet til den identitet, som senere callbacks og filer pr. klient ser. Ingen af linjerne kontrollerer en adgangskode, så en verifier skal stadig findes.

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

Den verifier er et plugin eller et script, der styres af auth-user-pass-verify, og det skal være på plads, før nogen af linjerne ovenfor betyder noget. Vender man rækkefølgen om, får man et vindue, hvor serveren ikke beder om certifikat og ikke kontrollerer nogen konto.

Hvad der stadig verificerer serveren

At droppe klientcertifikatet er ikke at droppe TLS. Serveren beholder sit certifikat og sin nøgle, og klienten beholder CA-tilliden og værtsnavnskontrollerne, der forhindrer den i at tale med en bedrager. At fjerne remote-cert-tls server eller CA-pakken, fordi klienten ikke længere har et certifikat, er en almindelig og alvorlig fejllæsning, og 2.6-reference er tydelig om, at de to retninger er uafhængige. Den ene beviser serveren over for klienten; den anden beviser klienten over for serveren.

En profil kan også indeholde en tls-auth- eller tls-crypt-blok. Det er en delt nøgle til kontrolkanalen med sin egen distributions- og rotationscyklus, så en fil uden certifikat- eller nøglelinjer er ikke automatisk sikker at offentliggøre. Behandl den som en hemmelighed, indtil du har læst den.

En certifikatfil, der er kopieret ud af en fungerende profil, beviser intet i sig selv; besiddelse betyder at have den private nøgle, der passer til den, hvilket en certifikatautentificeret udrulning kontrollerer. En fil, der indeholder et certifikat, er ikke en fil, man kan autentificere med.

Hvad verifieren skal gøre

Når certifikatkravet er fjernet, hviler alt på verifieren: et plugin eller et script, der styres af auth-user-pass-verify. Det skal afvise ugyldige legitimationsoplysninger, afvise deaktiverede eller uegnede konti og fejle lukket, når det ikke kan nå sin backend. username-as-common-name aktiveres ofte samtidig, og det ændrer den identitet, som senere callbacks og konfigurationsfiler pr. klient ser. Det verificerer ikke en adgangskode og gør ikke en uegnet konto egnet. Det er separate opgaver, og at blande dem er måden, hvorpå en migrering består sin happy-path-test og fejler ved sin første virkelige hændelse.

Test de negative tilfælde lige så omhyggeligt som det positive. En profil, der viser en adgangskodeprompt, beviser kun, at klienten kan tegne en prompt, mens en server, der accepterer den forkerte adgangskode, beviser noget betydeligt værre. Føj en deaktiveret konto og en udløbet legitimationsoplysning til testsættet, ikke bare en dårlig adgangskode.

Ændr politik, profil og mapping sammen

Koordinér tre ting: serverdirektivet, klientprofilen og identitetsmappingen pr. klient. Ændr dem hver for sig, og klienter fejler før verifikationen, eller forbinder under et navn, administratoren ikke forventede, hvilket er værre, fordi det ligner succes. En forbindelse, der lykkes under den forkerte identitet, er sværere at bemærke end en, der fejler.

Hold to testkonti til denne vej, en gyldig og en kendt dårlig, og brug begge efter enhver ændring af verifieren. Den gyldige konto beviser happy path og identitetsmappingen; den dårlige beviser, at afvisningen stadig virker. Ingen af testene fortæller noget om egnethedsregler, så føj en konto til, der bør afvises af politiske grunde, hvis udrulningen har dem. Kør alle tre efter hver ændring, fordi en verifier, der begynder at acceptere alt, ligner præcis et fungerende login.

Registrér, hvilke autentificeringsmetoder serveren faktisk accepterer, ikke hvilke profilen antyder. Den registrering besvarer det spørgsmål, folk bliver ved med at stille, nemlig hvem der kan forbinde til denne tjeneste. Den overlever også den næste administrator, som ellers vil genopdage den ud fra en pakkeoptagelse.