What Your VPN Client Checks Before It Trusts a Certificate

Your VPN client says the certificate could not be verified, and the dialog stops there. The file is present, the server is up, and the same profile worked on another laptop last month. Underneath that one-line warning the client ran the peer certificate through four gates: a certificate authority you configured vouches for the signature path, that path reaches the authority, the peer name is the one you asked for, and the certificate is usable now for this purpose. Find the gate that closed and the repair is usually one file; skip that step and you will re-import bundles all afternoon.

Read the dialog before you edit the profile

Certificate errors are worded by the library underneath, not by the VPN product you installed, so the exact string is your first evidence. "Unable to get local issuer certificate" points at the path or at the trust anchor. "Certificate has expired or is not yet valid" points at time. "Unsupported certificate purpose" points at extended key usage. A name mismatch tells you which name it wanted. None of the four is repaired by reinstalling the client.

Raise logging before changing anything. OpenVPN reports the verification failure around the handshake once you run it with --verb 4, and strongSwan logs its identity and chain decisions to the charon log. Then confirm which certificate you are inspecting, because people routinely test the file on disk while the profile inlines an older copy. When the profile embeds PEM blocks, the embedded certificate is the one under test.

A certificate authority signs identities, not permissions

The authority holds a name and a signing key. It issues certificates that bind a public key to that name under its own policy, with a validity window and usage constraints attached. Your client needs only the authority certificate to recognise the issuer; it never needs the signing key, and shipping that key to clients would hand out the ability to mint any identity the deployment trusts.

Trusting an authority makes every certificate it signed a candidate, not the right peer. A web server certificate from the same internal CA is a candidate too. That is why the name and purpose gates exist, and why a compromised CA key matters more than any single server: it reaches each identity the authority ever issued. Hand out client certificates per device, so a lost laptop is one revocation instead of a deployment-wide re-key.

Rebuild the path the client is trying to build

The path runs from the peer certificate, through zero or more intermediates, to a root in your trust store. A missing intermediate is the most common chain failure, and from the client side it looks identical to an untrusted root. Read the leaf first, then let OpenSSL build the path from the material you intend to ship.

openssl x509 -in server.crt -noout -subject -issuer -dates
openssl verify -CAfile root.crt -untrusted intermediate.crt server.crt
openssl verify -show_chain -CAfile root.crt -untrusted intermediate.crt server.crt

Exit status zero means the path built from those files; a failure names the certificate it could not reach. If openssl verify succeeds while the client still refuses, the difference is in what the server actually sends or in which trust file the profile loads. In OpenVPN, intermediates can ride along in the server certificate file or be supplied separately with --extra-certs, and a bundle holding two roots written under the same subject name will send one of your clients down the wrong branch.

Name and purpose are separate gates

Chain building never asks whether the name is yours. OpenVPN checks it only when the profile sets --verify-x509-name, and the older habit of matching the common name alone breaks on certificates whose identities live in subjectAltName. IKEv2 deployments match the configured identity against SAN entries or against the distinguished name, depending on the client, and a wildcard or %any value quietly disables the comparison you thought you had.

Time and purpose come next. A laptop whose clock runs a few hours fast rejects a certificate that is not yet valid, and an expired intermediate fails the path while the leaf is current. Purpose failures come from a certificate without serverAuth in extended key usage, or with a keyUsage that does not allow the handshake signature, which OpenSSL reports as an unsupported certificate purpose. Reissue from the right template; nothing in that message is a reason to switch verification off.

Revocation only runs if someone configured it

A CRL or an OCSP response is not consulted automatically. On an OpenVPN server, client certificates are checked against a list only when --crl-verify points at one. Client-side checking of the server certificate depends on the implementation and is often absent. strongSwan needs its revocation plugin and a policy before it looks at a CRL for a peer.

That explains the ticket you will eventually get: a revoked client certificate still connects, and everyone concludes revocation is broken. Nothing was checking. Publish and refresh the CRL, or keep client certificates short-lived enough that a stale revocation matters briefly, and rehearse the revocation path on a lab certificate before you need it during an incident.

A repair order that keeps verification on

Sort by symptom before touching files, because each row of the table sends you to a different object.

Work the list in one pass: confirm the file the profile loads, build the path yourself, check that the server sends the intermediate, compare the clock, read the SAN, read the EKU, then reconnect and watch the same log line disappear. If a device cannot be given a CA at all, pinning is the honest alternative, since OpenVPN 2.6 accepts --peer-fingerprint and narrows trust to one key instead of removing the check. RFC 5280 is the reference for what each of those fields means.