Learn OpenVPN - PKI & Certificate Management (Easy-RSA)

#Introduction

In episode 3 you already had a live tunnel, but using example keys that weren't yours. Now it's time to build the real security foundation: a complete Public Key Infrastructure (PKI) with Easy-RSA.

A PKI is a trust system that allows OpenVPN to verify who it is talking to. Without a PKI, anyone impersonating the server could fool your clients. Episode 4 covers the PKI architecture, step-by-step creation of a CA and certificates, Diffie-Hellman parameters, certificate revocation, and alternatives that can be used in large organizations.

#OpenVPN PKI Architecture

#Root CA as the Trust Anchor

Everything starts with a root CA: a key pair that signs all other certificates. Anyone holding the root CA can issue certificates trusted by the entire network, so the CA's private key must be stored extremely securely.

In a production architecture, the root CA is often kept offline and never connected to a network. All signing operations are done away from the server machine.

#Intermediate CA

For large scale, the root CA issues one or more intermediate CAs that sign server and client certificates. If an intermediate CA is compromised, the root CA doesn't need to be destroyed — a simple revocation is enough.

This two-tier architecture is standard practice in enterprises. For this series' lab, a single root CA is sufficient.

#Server and Client Certificates

Each server and client gets a leaf certificate: a certificate signed by the CA that contains the owner's identity. Server certificates are usually distinguished from client certificates by role, and on the client you use remote-cert-tls server to verify it.

#Certificate Chain

When a client receives a server certificate, it walks the chain of trust from the leaf certificate upward until it finds a CA it trusts. This chain is called the certificate chain. Understanding this is important because we will physically assemble it in the /etc/openvpn directory.

#Building the PKI with Easy-RSA

#Setting Up the Easy-RSA Directory

Prepare a workspace and initialize the PKI inside it:

mkdir -p /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
easyrsa init-pki

The command easyrsa init-pki creates the pki/ directory with a default structure: private/ for private keys and issued/ for issued certificates.

#Creating the Root CA

Create the CA with a passphrase so the CA private key is not stored in the clear:

easyrsa build-ca

When prompted for a Common Name, enter something like lab-ca. Display the CA certificate contents to verify:

openssl x509 -in pki/ca.crt -noout -subject -dates

openssl x509 -in pki/ca.crt -noout -subject -dates displays the subject and validity period of the CA. Note the expiry date — we will use it for monitoring in episode 19.

#Issuing the Server Certificate

Create the server key pair, then sign it with the CA:

easyrsa gen-req server nopass
easyrsa sign-req server server

gen-req server nopass creates a key without a passphrase (needed so the server can start automatically), and sign-req server server signs the request with the server role. The result is in pki/issued/server.crt with its key in pki/private/server.key.

#Issuing the Client Certificate

The process for a client is almost the same, only the role differs:

easyrsa gen-req client1 nopass
easyrsa sign-req client client1

Copy the required files to the right place on the server:

cp pki/ca.crt pki/issued/server.crt pki/private/server.key /etc/openvpn/server/
chmod 600 /etc/openvpn/server/server.key

chmod 600 on server.key is important: the private key should only be readable by its owner.

#Diffie-Hellman Parameters and Other Operations

#Generating Diffie-Hellman Parameters

Diffie-Hellman parameters allow server and client to share a secret without sending it. Generate them on the server side:

easyrsa gen-dh
cp pki/dh.pem /etc/openvpn/server/

For modern deployments, you can also use the faster ecdh-curve key — an option we discuss in episode 13.

#CRL and Certificate Revocation

When an employee leaves or a device is lost, revoke its certificate:

easyrsa revoke client1
easyrsa gen-crl
cp pki/crl.pem /etc/openvpn/server/

Don't forget to add crl-verify to the server configuration so revoked certificates are rejected. This revocation procedure is an important part of the production checklist in episode 21.

#Verifying with OpenSSL

Before use, verify that the certificate is valid:

openssl verify -CAfile pki/ca.crt pki/issued/server.crt

The output server.crt: OK means the chain of trust is correctly assembled.

#Alternative Certificate Management Options

#OpenSSL CLI Directly

For full control, you can create a CA and certificates directly with openssl req and openssl x509. This approach is more verbose but useful for understanding what Easy-RSA actually does behind the scenes.

#XCA: Multi-Platform GUI

XCA provides a graphical interface for managing CAs, certificates, and keys. It suits teams less comfortable with the CLI, or for visually auditing an entire PKI in a single project file.

#Integration with LDAP and ACME

In large organizations, certificates can be integrated with Active Directory/LDAP or issued automatically via ACME, as done by certbot. These approaches reduce manual work and ensure no certificate is forgotten as it approaches expiry.

#Conclusion

Key takeaways:

• A PKI consists of a root CA, server/client leaf certificates, and a certificate chain.
• The Easy-RSA flow: init-pki, build-ca, gen-req, sign-req, gen-dh.
• Client certificates are created with the client role; servers with the server role.
• Private keys must be chmod 600 and stored separately from certificates.
• Certificates are revoked with easyrsa revoke, then the CRL is regenerated.
• Alternatives: OpenSSL CLI, XCA, or LDAP/ACME integration at scale.

In the next episode, episode 5, we will discuss authentication: certificates vs pre-shared keys vs username/password — how mutual TLS works, using tls-auth, tls-crypt, and tls-crypt-v2, up to combining it with username/password authentication and session tokens. After this episode, you can choose the right authentication layer for every scenario.