A Correct VPN Password Cannot Replace a Missing Certificate

Credentials are right, the profile imports cleanly, and the connection still fails before authentication completes. On Windows the message may be error 798, about a certificate that could not be found for the EAP method. On OpenVPN the client log shows a TLS handshake that never satisfies the server. Both describe the same missing object: a client certificate the client was supposed to present.

A password proves knowledge of a secret; a certificate proves possession of a key, and one does not substitute for the other.

The Password Was Never the Problem

Error 798 is a certificate lookup failure. The client was asked for a certificate matching the configured authentication method, searched its store, and found nothing usable. That can mean the certificate is absent, present without its private key, expired, or stored where the lookup does not reach. Retrying the password cannot change any of those conditions, which is why the error keeps returning with correct credentials.

Read the message before acting on it. A credential rejection, a certificate lookup failure and a TLS handshake failure are three different findings, and only one involves the password.

What the Client Store Has to Contain

Two objects are involved. The client certificate must be installed for the user who runs the VPN client, with its private key, and the issuing root must be trusted. A .cer file contains only the public certificate, so it cannot authenticate anything by itself. In the Windows certificate manager, the client identity belongs in the current user's personal store, and the root belongs in the trusted root store.

Installing the identity into the machine store, or into the root store alone, does not satisfy a lookup aimed at the user's personal store. Check the store, the private key flag and the validity dates together, then restart the client so it re-reads the store.

Two Products, the Same Missing Credential

OpenVPN servers require a client certificate by default. Adding auth-user-pass to a client sends a username and password, and the TLS handshake still asks for a certificate, so a password alone cannot complete the connection under verify-client-cert require. The server can be set to require none, which makes the password the only client credential and is a real reduction in strength. A shell script behind auth-user-pass-verify can validate credentials, and it requires script execution to be enabled, which makes it a riskier design than a proper authentication backend.

A password-only profile also depends on pushed options, which in turn depend on the pull mechanism being enabled.

Do Not Fix a Missing Certificate by Disabling Checks

The temptation is to relax verification so the message disappears. That removes the control that was doing its job and leaves a connection that no longer proves what it claims. If the gateway recently changed its root, re-download the client package rather than editing the profile, because the old package may still carry the previous root. If the certificate authentication option is missing from the profile editor, the installed Windows version may not expose that method; update the system instead of hand-editing XML.

Record which store held the certificate, which user ran the client and whether the private key was present. Those three explain nearly every instance of this failure.

The password was fine. The credential the method actually needed was somewhere else.