Learn OpenVPN - Authentication: Certificates vs PSK vs Username/Password

#Introduction

With the PKI standing from episode 4, the next question is: how does OpenVPN verify that the party on the other end is who you mean? There are three layers of answers: X.509 certificates for node identity, pre-shared keys to secure the control channel, and username/password for user identity.

The three are not mutually exclusive — they complement each other. A good production deployment uses all of them at once. Episode 5 covers how each works, when to use it, and how to combine them in a single configuration.

#Mutual TLS with X.509 Certificates

#How Mutual Authentication Works

In ordinary HTTP, only the client verifies the server's identity. In OpenVPN, verification is two-way: the client verifies the server's certificate, and the server verifies the client's certificate. Both must be signed by the same CA.

This is why certificates not issued by your CA are automatically rejected. Trust is derived from the CA, not from words.

#Directives Involved

On the client side, the following directives enable mutual TLS:

ca ca.crt
cert client1.crt
key client1.key
remote-cert-tls server

ca ca.crt points to the trusted CA, while remote-cert-tls server ensures the server certificate meets server-specific criteria. The combination of cert and key is the client's identity.

#Additional Identity Verification

To prevent valid certificates from another CA you don't want, add verify-x509-name:

verify-x509-name vpn.lab.example name-prefix

verify-x509-name vpn.lab.example name-prefix ensures the server certificate's subject begins with that name. Full details of this hardening are in episode 13.

#Pre-Shared Keys: tls-auth, tls-crypt, tls-crypt-v2

Beyond certificates, OpenVPN can add a pre-shared key known only to legitimate nodes. It serves two purposes: filtering guests before the TLS handshake and encrypting the control channel.

#tls-auth: HMAC Firewall

tls-auth attaches an HMAC to every packet. Packets without the correct HMAC are immediately dropped, so random probes on port 1194 never get to consume handshake resources:

openvpn --genkey secret ta.key

Add tls-auth ta.key 0 on the server and tls-auth ta.key 1 on the client. The numbers 0 and 1 indicate direction — the server is always 0, the client is always 1.

#tls-crypt: Control Channel Encryption

tls-crypt goes a step further: besides filtering, it also encrypts the entire control channel. This hides metadata such as certificates and negotiation from network observers.

tls-crypt ta.key

The same directive is written on both server and client without a direction number, because tls-crypt handles direction automatically.

#tls-crypt-v2: Per-Client Keys

tls-crypt-v2 is the newest evolution: each client gets a different pre-shared key, derived from a server master key:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/server/server-crypt.key
openvpn --genkey tls-crypt-v2-client --tls-crypt-v2 /etc/openvpn/server/server-crypt.key client-crypt.key

openvpn --genkey tls-crypt-v2-server creates the server master key, and the client variant generates a key specific to each client. Its advantage: if one client key leaks, only that client is affected.

#Username/Password

#auth-user-pass

For user-identity-based authentication, enable auth-user-pass on the client and add verification on the server:

# client.ovpn
auth-user-pass
 
# server.conf
plugin /usr/lib/openvpn/openvpn-auth-pam.so openvpn

Each time you connect, the client prompts for a username and password. The server verifies them via PAM — which can be mapped to LDAP, RADIUS, or a local database.

#verify and External Scripts

For custom verification logic, OpenVPN calls the --auth-user-pass-verify script with via-env or via-file mode. This script can check group membership, account status, or organizational policy.

auth-user-pass-verify /etc/openvpn/check-user.sh via-env
script-security 2

script-security 2 must be enabled so external scripts may run. More on LDAP and RADIUS integration is in episode 10.

#auth-gen-token for Session Management

When verification uses a slow external service, don't verify on every reconnect:

auth-gen-token 3600

auth-gen-token 3600 makes the server issue a session token valid for 3600 seconds after the first successful verification. Reconnects during the token's lifetime don't need to call the authentication service again.

#Combining All the Layers

#Defense-in-Depth Architecture

A production configuration combines all three. Illustrated on the server:

ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-crypt-v2 server-crypt.key
auth-user-pass-verify /etc/openvpn/check-user.sh via-env
script-security 2
auth-gen-token 3600

The flow: the tls-crypt-v2 HMAC filters probes, certificates authenticate nodes, then username/password authenticates users, and the session token prevents expensive repeated verification.

#Choosing the Right Combination

• Personal lab: certificates + tls-crypt are sufficient.
• Enterprise: certificates + tls-crypt-v2 + username/password via PAM/LDAP.
• High compliance needs: add MFA as discussed in episode 10.

#Conclusion

Key takeaways:

• Mutual TLS uses X.509 certificates signed by the same CA.
• tls-auth filters packets; tls-crypt encrypts the control channel.
• tls-crypt-v2 gives each client a different pre-shared key.
• auth-user-pass shifts authentication to user identity via PAM/LDAP/RADIUS.
• auth-gen-token reduces repeated authentication calls on reconnect.
• Combining all three forms defense-in-depth for production.

In the next episode, episode 6, we will discuss routing and IP forwarding — how routed tun mode works, distributing routes to clients with push and iroute, bridging with tap mode, and NAT with iptables. After this episode, you can direct traffic to any subnet through the tunnel.