OpenVPN client-config-dir: filename vs certificate CN

Two names are in play before a client ever connects: the file name on the laptop (nuc.ovpn) and the identity the server derives from the credential. A client-config-dir lookup uses the second one. Renaming the profile on the client, or adding .conf to the server file, changes nothing about which file the server opens.

The useful comparison is not "which name did I use" but "which rule is the server applying", because certificate authentication and username/password authentication can produce different effective names from the same login.

Profile name versus certificate common name

With the default certificate-based setup the server takes the X.509 common name and looks for a file with exactly that name inside client-config-dir. A profile called nuc.ovpn whose certificate says tester resolves to /etc/openvpn/server/ccd/tester. The client file name never enters the calculation. That is the first place a mismatch hides.

A directory full of carefully named profiles can therefore miss every time. The file is not matched by subject, by e-mail address or by the name shown in a GUI; it is matched by the common name string.

On a case-sensitive filesystem Tester and tester are two different files, and only one is ever opened. Check the common name from the certificate the client actually presents, not from a copy in your notes.

username-as-common-name flips the rule

When the server runs username/password authentication with username-as-common-name, the authenticated user name replaces the certificate common name for this lookup.

Compare the two cases directly: with certificate identity, the file follows the certificate and a password change is irrelevant; with username identity, the file follows the login name and reissuing the certificate is irrelevant. Whichever field the server substitutes is the one to rename against. A reissued certificate with a new CN silently changes the lookup target, and the old CCD file stays on disk looking correct.

Mixed configurations exist, and that is where most confusion starts. If one service block enables the substitution and another does not, the effective name depends on which instance handled the connection. Confirm the active configuration rather than assuming the global file applies. The upstream server-options reference documents the named-file lookup and the optional fallback.

What the server reads, and what it silently skips

Two small differences decide whether a file is selected. The first is an added extension. The second is a stray character in the name.

OpenVPN does not append .conf to the name it looks for, so tester.conf is not a match for tester. An editor that hides extensions can leave a file that looks right in a listing and never matches.

When no matching file exists, the server can fall back to a file named DEFAULT. Some settings arriving is therefore not proof that the per-client file was used. Compare the assigned address or pushed routes against what the per-client file would produce. Permissions are the third filter, because the server opens the file after dropping privileges; a root shell that can read it proves nothing.

A correct filename does not validate the contents

Selection and content are separate failures. Once the right file is opened, its directives still have to be valid for that client.

ifconfig-push must assign an address the topology can actually use, and iroute only makes sense for a routed subnet behind that client.

One identity, several devices

Two laptops that present the same common name select the same file and receive the same client-specific settings. If you need separate addresses or separate revocation, you need separate identities, not two copies of one file.

The comparison is between sharing an identity and issuing one certificate per device. Sharing is simpler to administer and coarser to revoke, while per-device certificates cost more setup and give you a clean unit to disable.