Use Your Existing Enterprise CA for OpenVPN Peers

Nothing in OpenVPN requires the certificate to come from Easy-RSA, and a fleet that already has an organizational PKI usually should not build a second one. The real work is not choosing a tool but deciding what the issued identities mean, which peers the tunnel accepts, and how renewal and revocation arrive at the verifier. Work through the five steps below in order, because a later step cannot repair a role decision made in the first.

Issue two roles instead of one shared identity

Every peer needs its own certificate and matching private key. Ask the PKI team for a server identity carrying server usage and separate client identities carrying client usage, so that the tunnel can tell the two apart at handshake time.

Resist the shortcuts that appear under deadline pressure. A web server's key copied onto laptops erases the distinction the role check depends on, and a CA signing key installed on a VPN endpoint turns one compromised host into a compromised hierarchy. A PKCS12 bundle can carry an endpoint key and its chain, but it never grants permission to reuse that identity in another role.

Wire the trust inputs on each side

The client and the server each need a trust anchor, their own identity and an explicit role expectation. A client fragment that states all three looks like this.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

The server side mirrors it with remote-cert-tls client and its own certificate, which is what stops a client certificate from being accepted as a server. The name check is a separate decision from the role check. Read the deployed configuration to see which field is compared rather than assuming a browser-style hostname match. Both sides should also be explicit about which issuer they trust, because a shared file path across the fleet is not the same thing as a shared policy.

Deliver intermediates without widening trust

The two sides do not have to share one issuing chain. When a peer presents a certificate signed by an intermediate, the verifying side needs that intermediate available, and OpenVPN distinguishes the trust anchor input from the extra certificates used to complete a locally presented chain. The OpenVPN 2.6 TLS option reference documents both.

An intermediate CA is not inherently a problem, and a broad enterprise root dropped into the trust bundle is. The wider the anchor, the more certificates satisfy the chain test, and a role check does not turn that into a list of authorized staff. Narrow the anchor to the issuer that actually signs VPN identities where the hierarchy allows it. If it does not, document the wider anchor as a deliberate accepted risk instead of leaving it implicit.

Agree with the PKI team on how renewal and revocation reach the VPN verifiers, including which issuers matter and who publishes the list. A CRL distribution point embedded in a certificate is an instruction, not evidence that anything fetched it.

Decide how revocation actually arrives

crl-verify makes the verifier consult a file or endpoint, and that arrangement needs an owner and a refresh path. A list that is copied once during deployment silently stops protecting you the first time a certificate is revoked.

Write down the expected propagation time and test it with a certificate you are willing to revoke. If the list cannot be refreshed on the VPN host, the alternative is a shorter validity period plus a renewal process that actually runs, not an assumption that revocation works because a URL exists.

Prove acceptance with a real client

Connect a client that should be allowed and confirm the negotiated certificate details in the log. Then try the cases that must fail: a client certificate presented as a server, a certificate from an issuer outside the trust anchor, and a revoked certificate if you have one to spare.

Record the accepted issuer, the role check and the revocation source next to the profile. That record is what the next engineer needs when a device that worked last month stops connecting, and it is also the evidence that the enterprise CA is being used within a documented acceptance boundary rather than as a general-purpose trust dump.