OpenVPN zonder clientcertificaat: serverbeleid, geen profiel

Je verwijdert de certificaat- en sleutelregels, geeft het profiel door, en de verbinding mislukt nog steeds met een certificaatfout. Het profiel was nooit het ding dat die eis afdwong. De server beslist of een clientcertificaat verplicht is, en geen enkele aanpassing aan de clientkant onderhandelt dat weg. De oplossing is dus een wijziging van het serverbeleid, bewust gedaan, met alles wat ervan afhangt in dezelfde ronde bijgewerkt.

Het profiel is niet het beleid

Community OpenVPN 2.6 wordt geleverd met verplichte clientcertificaten, omdat verify-client-cert standaard require is. Het op none zetten is wat de eis om een certificaat stopt en de clientauthenticatie overdraagt aan de gebruikersnaam-en-wachtwoordregeling die de server al draait. Oudere gidsen grijpen naar client-cert-not-required, de verouderde spelling van hetzelfde idee, dus gebruik de richtlijn die je geïnstalleerde versie documenteert. Hoe dan ook gebeurt de wijziging op de server, en geen enkel clientprofiel kan die uitvoeren.

Het fragment hieronder is de hele wijziging aan de serverkant, en op zichzelf is het geen werkende authenticatieconfiguratie. verify-client-cert none verwijdert de certificaateis, terwijl username-as-common-name de accountnaam de identiteit maakt die latere callbacks en bestanden per client zien. Geen van beide regels controleert een wachtwoord, dus er moet nog steeds een verificator bestaan.

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

Die verificator is een plug-in of een script dat door auth-user-pass-verify wordt aangestuurd, en het moet op zijn plaats staan voordat een van de regels hierboven iets betekent. De volgorde omdraaien geeft je een venster waarin de server geen certificaat vraagt en geen account controleert.

Wat de server nog steeds verifieert

Het laten vallen van het clientcertificaat betekent niet het laten vallen van TLS. De server houdt zijn certificaat en sleutel, en de client houdt het CA-vertrouwen en de hostnamecontroles die hem ervan weerhouden met een bedrieger te praten. remote-cert-tls server of de CA-bundel verwijderen omdat de client geen certificaat meer heeft, is een veelvoorkomende en ernstige verkeerde lezing, en de 2.6-referentie is expliciet dat de twee richtingen onafhankelijk zijn. De ene bewijst de server aan de client; de andere bewijst de client aan de server.

Een profiel kan ook een tls-auth- of tls-crypt-blok bevatten. Dat is een gedeelde sleutel voor het controlekanaal met zijn eigen distributie- en rotatiecyclus, dus een bestand zonder certificaat- of sleutelregels is niet automatisch veilig om te publiceren. Behandel het als een geheim totdat je het hebt gelezen.

Een certificaatbestand dat uit een werkend profiel is gekopieerd, bewijst op zichzelf niets; bezit betekent de bijbehorende privésleutel hebben, wat een met certificaat geauthenticeerde implementatie controleert. Een bestand dat een certificaat bevat, is geen bestand waarmee je je kunt authenticeren.

Wat de verificator moet doen

Met de certificaateis verwijderd, rust alles op de verificator: een plug-in, of een script dat door auth-user-pass-verify wordt aangestuurd. Hij moet ongeldige inloggegevens weigeren, uitgeschakelde of ongeschikte accounts weigeren en gesloten falen wanneer hij zijn backend niet kan bereiken. username-as-common-name wordt vaak ernaast ingeschakeld, en het verandert de identiteit die latere callbacks en configuratiebestanden per client zien. Het verifieert geen wachtwoord en maakt een ongeschikt account niet geschikt. Dat zijn aparte taken, en ze door elkaar halen is hoe een migratie de happy-path-test haalt en bij zijn eerste echte incident faalt.

Test de negatieve gevallen net zo zorgvuldig als het positieve. Een profiel dat een wachtwoordprompt toont, bewijst alleen dat de client een prompt kan tekenen, terwijl een server die het verkeerde wachtwoord accepteert iets aanzienlijk ergers bewijst. Voeg een uitgeschakeld account en een verlopen inloggegeven toe aan de testset, niet alleen een slecht wachtwoord.

Wijzig beleid, profiel en mapping samen

Coördineer drie dingen: de serverrichtlijn, het clientprofiel en de identiteitsmapping per client. Wijzig ze apart en clients falen vóór de verificatie, of verbinden onder een naam die de beheerder niet verwachtte, wat erger is omdat het op succes lijkt. Een verbinding die slaagt onder de verkeerde identiteit is moeilijker op te merken dan een die faalt.

Houd twee testaccounts voor dit pad, een geldige en een bekend slechte, en gebruik beide na elke wijziging aan de verificator. Het geldige account bewijst het happy path en de identiteitsmapping; het slechte bewijst dat weigeren nog werkt. Geen van beide tests vertelt je iets over geschiktheidsregels, dus voeg een account toe dat om beleidsredenen geweigerd zou moeten worden als de implementatie die heeft. Voer alle drie na elke wijziging uit, want een verificator die alles begint te accepteren ziet er precies uit als een werkende login.

Leg vast welke authenticatiemethoden de server feitelijk accepteert, niet welke het profiel suggereert. Die registratie beantwoordt de vraag die mensen blijven stellen, namelijk wie verbinding kan maken met deze dienst. Ze overleeft ook de volgende beheerder, die haar anders opnieuw zou ontdekken uit een pakketopname.