OpenVPN Without a Client Certificate: Server Policy, Not Profile

You delete the certificate and key lines, hand the profile over, and the connection still fails with a certificate error. The profile was never the thing enforcing that requirement. The server decides whether a client certificate is mandatory, and no client-side edit negotiates that away. So the fix is a server policy change, made deliberately, with everything that depends on it updated in the same pass.

The profile is not the policy

Community OpenVPN 2.6 ships with client certificates mandatory, because verify-client-cert defaults to require. Setting it to none is what stops the demand for a certificate and hands client authentication to whatever username and password arrangement the server already runs. Older guides reach for client-cert-not-required, the legacy spelling of the same idea, so use the directive your installed version documents. Either way the change happens on the server, and no client profile can perform it.

The fragment below is the entire server-side change, and on its own it is not a working authentication configuration. verify-client-cert none removes the certificate requirement, while username-as-common-name makes the account name the identity that later callbacks and per-client files see. Neither line checks a password, so a verifier still has to exist.

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

That verifier is a plugin or a script driven by auth-user-pass-verify, and it has to be in place before either line above means anything. Reversing the order gives you a window in which the server asks for no certificate and checks no account.

What still verifies the server

Dropping the client certificate does not drop TLS. The server keeps its certificate and key, and the client keeps the CA trust and hostname checks that stop it talking to an impostor. Removing remote-cert-tls server or the CA bundle because the client no longer has a certificate is a common and serious misreading, and the 2.6 reference is explicit that the two directions are independent. One proves the server to the client; the other proves the client to the server.

A profile can also carry a tls-auth or tls-crypt block. That is a shared control-channel key with its own distribution and rotation cycle, so a file with no cert or key lines is not automatically safe to publish. Treat it as a secret until you have read it.

A certificate file copied out of a working profile proves nothing on its own; possession means holding the private key that matches it, which a certificate-authenticated deployment checks for. A file that contains a certificate is not a file that can authenticate with it.

What the verifier has to do

With the certificate requirement removed, everything rests on the verifier: a plugin, or a script driven by auth-user-pass-verify. It has to reject invalid credentials, reject disabled or ineligible accounts, and fail closed when it cannot reach its backend. username-as-common-name is often enabled alongside, and it changes the identity that later callbacks and per-client configuration files see. It does not verify a password, and it does not make an ineligible account eligible. Those are separate jobs, and mixing them up is how a migration passes its happy-path test and fails its first real incident.

Test the negative cases as carefully as the positive one. A profile that shows a password prompt proves only that the client can draw a prompt, while a server that accepts the wrong password proves something considerably worse. Add a disabled account and an expired credential to the test set, not just a bad password.

Change the policy, profile and mapping together

Coordinate three things: the server directive, the client profile, and the per-client identity mapping. Change them separately and clients fail before verification, or connect under a name the administrator did not expect, which is worse because it looks like success. A connection that succeeds under the wrong identity is harder to notice than one that fails.

Keep two test accounts for this path, a valid one and a known-bad one, and use both after any change to the verifier. The valid account proves the happy path and the identity mapping; the bad one proves that rejection still works. Neither test tells you anything about eligibility rules, so add an account that should be refused for policy reasons if the deployment has them. Run all three after every change, because a verifier that starts accepting everything looks exactly like a working login.

Record which authentication methods the server actually accepts, not which ones the profile suggests. That record answers the question people keep asking, which is who can connect to this service. It also outlives the next administrator, who will otherwise rediscover it from a packet capture.