Een correct VPN-wachtwoord vervangt geen ontbrekend certificaat

De inloggegevens kloppen, het profiel wordt schoon geïmporteerd en de verbinding mislukt nog steeds voordat de authenticatie is voltooid. Op Windows kan het bericht fout 798 zijn, over een certificaat dat niet is gevonden voor de EAP-methode. Bij OpenVPN toont het clientlogboek een TLS-handdruk die de server nooit tevreden stelt. Beide beschrijven hetzelfde ontbrekende object: een clientcertificaat dat de client had moeten overleggen.

Een wachtwoord bewijst kennis van een geheim; een certificaat bewijst bezit van een sleutel, en het ene vervangt het andere niet.

Het wachtwoord was nooit het probleem

Fout 798 is een mislukte certificaatzoekopdracht. De client werd gevraagd om een certificaat dat bij de geconfigureerde authenticatiemethode past, doorzocht zijn archief en vond niets bruikbaars. Dat kan betekenen dat het certificaat ontbreekt, aanwezig is zonder de persoonlijke sleutel, verlopen is of is opgeslagen waar de zoekopdracht niet komt. Opnieuw het wachtwoord proberen kan geen van die omstandigheden veranderen, daarom komt de fout terug, ook met correcte inloggegevens.

Lees het bericht voordat u ernaar handelt. Een afwijzing van inloggegevens, een mislukte certificaatzoekopdracht en een mislukte TLS-handdruk zijn drie verschillende bevindingen, en slechts één ervan heeft met het wachtwoord te maken.

Wat het clientarchief moet bevatten

Er zijn twee objecten in het spel. Het clientcertificaat moet zijn geïnstalleerd voor de gebruiker die de VPN-client uitvoert, met de persoonlijke sleutel, en de uitgevende root moet worden vertrouwd. Een .cer-bestand bevat alleen het openbare certificaat, dus het kan op zichzelf niets authenticeren. In het Windows-certificaatbeheer hoort de clientidentiteit in het persoonlijke archief van de huidige gebruiker, en de root in het archief van vertrouwde roots.

De identiteit in het machinearchief installeren, of alleen in het rootarchief, voldoet niet aan een zoekopdracht die op het persoonlijke archief van de gebruiker is gericht. Controleer het archief, de markering voor de persoonlijke sleutel en de geldigheidsdatums samen, en herstart daarna de client zodat hij het archief opnieuw leest.

Twee producten, dezelfde ontbrekende inloggegevens

OpenVPN-servers eisen standaard een clientcertificaat. Door auth-user-pass aan een client toe te voegen, worden een gebruikersnaam en wachtwoord verstuurd, en de TLS-handdruk vraagt nog steeds om een certificaat, dus een wachtwoord alleen kan de verbinding onder verify-client-cert require niet voltooien. De server kan zo worden ingesteld dat er niets vereist is, wat het wachtwoord de enige clientinloggegevens maakt en een echte verzwakking is. Een shellscript achter auth-user-pass-verify kan inloggegevens valideren, en dat vereist dat scriptuitvoering is ingeschakeld, wat het een riskanter ontwerp maakt dan een degelijke authenticatie-backend.

Een profiel met alleen een wachtwoord is ook afhankelijk van gepushte opties, die op hun beurt afhangen van het inschakelen van het pullmechanisme.

Repareer een ontbrekend certificaat niet door controles uit te schakelen

De verleiding is om de verificatie te versoepelen zodat het bericht verdwijnt. Dat verwijdert de controle die zijn werk deed en laat een verbinding achter die niet meer bewijst wat hij beweert. Als de gateway onlangs zijn root heeft gewijzigd, download het clientpakket opnieuw in plaats van het profiel te bewerken, want het oude pakket kan nog de vorige root bevatten. Als de optie voor certificaatauthenticatie ontbreekt in de profieleditor, toont de geïnstalleerde Windows-versie die methode misschien niet; werk het systeem bij in plaats van XML met de hand te bewerken.

Noteer welk archief het certificaat bevatte, welke gebruiker de client uitvoerde en of de persoonlijke sleutel aanwezig was. Die drie verklaren bijna elk geval van deze fout.

Het wachtwoord was in orde. De inloggegevens die de methode werkelijk nodig had, stonden ergens anders.