How to Assemble an OpenVPN Client Profile From Issued Files

Your operator hands over a CA bundle, a client certificate and its key, and the client will not come up until they are wired into one profile. The profile is configuration: it points at those files, it does not contain them, and editing it cannot turn it into a certificate. The walkthrough starts from an already-approved laptop and ends with a profile you can start from a known directory. It does not create a CA, enrol a new certificate or touch the server.

The target here is a Linux OpenVPN 2.6 command-line client, routed TUN over UDP, with certificate authentication.

Collect only the client-side files

Work in a protected directory and gather the approved CA trust material, your issued client certificate, and the private key that matches it. For this example the names are ca.crt, laptop-a.crt and laptop-a.key. The filenames are only labels; they say nothing about what each file contains.

If you generated the key during enrolment, it never left the machine; only the signed certificate and the public chain need to come back from the issuer. Check that the certificate carries the client role the service expects. Check, too, that the key belongs to that certificate and not to an earlier one from a previous attempt. A mismatched pair produces a TLS failure much later, one that looks like a server problem.

Leave the CA private signing key, the server's private key and the DH parameters out of this package.

Wire the files into a small profile

The profile below is deliberately short. Every line either selects the endpoint, constrains the identity the client will accept, or points at one of the three files.

client
dev tun
proto udp
remote vpn.example.net 1194
nobind

remote-cert-tls server
verify-x509-name vpn-gateway name
ca ca.crt
cert laptop-a.crt
key laptop-a.key

The remote line picks the network endpoint. remote-cert-tls server insists that the peer present a server-role certificate. verify-x509-name pins the expected name, here vpn-gateway as the server certificate's Common Name with OpenVPN's default name field. That value is not inferred from the DNS hostname, so use whatever identity scheme the operator supplied.

Do not drop those checks just because a test endpoint shows a different certificate.

This base profile assumes no separate account challenge and no control-channel key. If the service needs auth-user-pass, tls-auth or tls-crypt, keep the configuration and the material you were given, because a control-channel secret you generate yourself will not match the one the server holds. Keep the service's cipher policy as well instead of importing compression or cipher lines from an old example.

Make the working directory explicit

Relative paths follow the working directory of the process, not the location of the .ovpn file.

That surprises people who move the profile to a new folder and expect the key to follow it. For an administrator-selected directory, the command below changes into an absolute path before reading the profile and its references.

sudo openvpn --cd /etc/openvpn/client/laptop-a --config laptop-a.ovpn

A desktop import wizard or a system service may package the dependencies for you and apply rules of its own. It may also use a different working directory than the one you tested in. Confirm how your launch method resolves the key, certificate and CA paths. Moving only the .ovpn file does not move the separate private key.

Keep the key readable only by its intended user or service identity.

Verify the handoff, not the filenames

Before the first authorised connection, check the endpoint, the certificate identity, the issuer and the validity window. Then confirm that the file references resolve from the working directory you will actually use. After connecting, test the application and DNS behaviour the routing policy is supposed to provide. Three readable files prove nothing about server authorisation or about a usable resource path.

If a passphrase prompt appears, it belongs to the private key, not to a VPN account.

Finally, inventory the package as credential material. Handing the same certificate and key to a second laptop copies the identity, and renaming the file does not give you a second enrolment. That is the difference between assembling a profile and issuing one.