OpenVPN utan klientcertifikat: serverprincip, inte profil

Du tar bort certifikat- och nyckellinjerna, lämnar över profilen, och anslutningen misslyckas fortfarande med ett certifikatfel. Profilen var aldrig det som genomdrev kravet. Servern avgör om ett klientcertifikat är obligatoriskt, och ingen ändring på klientsidan förhandlar bort det. Så rättelsen är en ändring av serverpolicyn, gjord medvetet, med allt som beror på den uppdaterat i samma omgång.

Profilen är inte policyn

Community OpenVPN 2.6 levereras med obligatoriska klientcertifikat, eftersom verify-client-cert som standard är require. Att ställa den till none är det som stoppar kravet på ett certifikat och överlämnar klientautentiseringen till den användarnamn- och lösenordsordning servern redan kör. Äldre guider griper efter client-cert-not-required, den föråldrade stavningen av samma idé, så använd det direktiv som din installerade version dokumenterar. Hur som helst sker ändringen på servern, och ingen klientprofil kan utföra den.

Fragmentet nedan är hela ändringen på serversidan, och i sig är det inte en fungerande autentiseringskonfiguration. verify-client-cert none tar bort certifikatkravet, medan username-as-common-name gör kontonamnet till den identitet som senare återanrop och filer per klient ser. Ingen av raderna kontrollerar ett lösenord, så en verifierare måste fortfarande finnas.

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

Den verifieraren är en plugin eller ett skript som styrs av auth-user-pass-verify, och den måste vara på plats innan någon av raderna ovan betyder något. Vänder du på ordningen får du ett fönster där servern inte begär något certifikat och inte kontrollerar något konto.

Vad som fortfarande verifierar servern

Att släppa klientcertifikatet är inte att släppa TLS. Servern behåller sitt certifikat och sin nyckel, och klienten behåller CA-förtroendet och värdnamnskontrollerna som hindrar den från att prata med en bedragare. Att ta bort remote-cert-tls server eller CA-paketet eftersom klienten inte längre har ett certifikat är en vanlig och allvarlig felläsning, och 2.6-referensen är tydlig med att de två riktningarna är oberoende. Den ena bevisar servern för klienten; den andra bevisar klienten för servern.

En profil kan också innehålla ett tls-auth- eller tls-crypt-block. Det är en delad nyckel för kontrollkanalen med sin egen distributions- och rotationscykel, så en fil utan certifikat- eller nyckellinjer är inte automatiskt säker att publicera. Behandla den som en hemlighet tills du har läst den.

En certifikatfil som kopierats ut ur en fungerande profil bevisar ingenting i sig själv; innehav betyder att hålla den privata nyckel som passar till den, vilket en certifikatautentiserad driftsättning kontrollerar. En fil som innehåller ett certifikat är inte en fil man kan autentisera sig med.

Vad verifieraren måste göra

När certifikatkravet är borttaget vilar allt på verifieraren: en plugin, eller ett skript som styrs av auth-user-pass-verify. Den måste avvisa ogiltiga inloggningsuppgifter, avvisa inaktiverade eller olämpliga konton och misslyckas stängt när den inte når sin backend. username-as-common-name aktiveras ofta vid sidan om, och det ändrar den identitet som senare återanrop och konfigurationsfiler per klient ser. Det verifierar inte ett lösenord och gör inte ett olämpligt konto lämpligt. Det är separata uppgifter, och att blanda dem är hur en migrering klarar lyckotestet och misslyckas vid sin första verkliga incident.

Testa de negativa fallen lika noggrant som det positiva. En profil som visar en lösenordsförfrågan bevisar bara att klienten kan rita en förfrågan, medan en server som accepterar fel lösenord bevisar något betydligt värre. Lägg till ett inaktiverat konto och en utgången inloggningsuppgift i testuppsättningen, inte bara ett dåligt lösenord.

Ändra policy, profil och mappning tillsammans

Samordna tre saker: serverdirektivet, klientprofilen och identitetsmappningen per klient. Ändra dem var för sig och klienter misslyckas före verifieringen, eller ansluter under ett namn som administratören inte förväntade sig, vilket är värre eftersom det ser ut som framgång. En anslutning som lyckas under fel identitet är svårare att lägga märke till än en som misslyckas.

Håll två testkonton för den här vägen, ett giltigt och ett känt dåligt, och använd båda efter varje ändring av verifieraren. Det giltiga kontot bevisar lyckovägen och identitetsmappningen; det dåliga bevisar att avvisningen fortfarande fungerar. Ingen av testerna säger dig något om lämplighetsregler, så lägg till ett konto som borde avvisas av policyskäl om driftsättningen har sådana. Kör alla tre efter varje ändring, eftersom en verifierare som börjar acceptera allt ser precis ut som en fungerande inloggning.

Registrera vilka autentiseringsmetoder servern faktiskt accepterar, inte vilka profilen antyder. Den registreringen besvarar frågan folk fortsätter ställa, nämligen vem som kan ansluta till den här tjänsten. Den överlever också nästa administratör, som annars skulle återupptäcka den från en paketinsamling.