OpenVPN CRL expires and cannot be regenerated automatically

[akuzminsky]

Problem

OpenVPN clients cannot connect when the Certificate Revocation List (CRL) expires:

VERIFY ERROR: depth=0, error=CRL has expired
TLS Error: TLS handshake failed

The CRL has a 180-day expiration (EASYRSA_CRL_DAYS 180 in vars.erb), but Puppet only generates it once during initial setup and never regenerates it.

Root Cause

Issue 1: CRL is only generated once

In modules/profile/manifests/openvpn_server/config.pp (lines 147-158):

exec { 'generate_gen_crl':
  command => "/usr/share/easy-rsa/easyrsa --vars=${openvp_config_directory}/vars gen-crl",
  cwd     => $openvp_config_directory,
  creates => $openvpn_crl_path,  # <-- Only runs if file doesn't exist
  require => [...]
}

The creates parameter means this exec only runs once when the file doesn't exist. After the initial CRL is created, Puppet never regenerates it, even after it expires 180 days later.

Issue 2: Missing CA passphrase configuration

The vars.erb template is missing the EASYRSA_PASSIN variable needed for automated CRL regeneration:

Current vars.erb (lines 166-167):

set_var EASYRSA_BATCH true
set_var EASYRSA_NO_PASS 1

Missing:

set_var EASYRSA_PASSIN "file:<%= @openvp_config_directory %>/ca_passphrase"

Without this, any attempt to regenerate the CRL manually prompts for the CA passphrase:

root@ip-10-1-3-120:/etc/openvpn# /usr/share/easy-rsa/easyrsa gen-crl
Enter pass phrase for /etc/openvpn/pki/private/ca.key:

Impact

• Severity: High - All OpenVPN clients lose connectivity when CRL expires
• Frequency: Every 180 days (~6 months)
• Workaround: Manual CRL regeneration by ops team

Observed Behavior

root@ip-10-1-3-120:/etc/openvpn# openssl crl -in /etc/openvpn/pki/crl.pem -noout -text
Certificate Revocation List (CRL):
    Last Update: Jun 27 21:05:32 2025 GMT
    Next Update: Dec 24 21:05:32 2025 GMT  # EXPIRED

Current date: January 2, 2026 - CRL expired 9 days ago.

Proposed Solution

1. Add EASYRSA_PASSIN to vars.erb template

set_var EASYRSA_BATCH true
set_var EASYRSA_NO_PASS 1
set_var EASYRSA_PASSIN "file:<%= @openvp_config_directory %>/ca_passphrase"

2. Add automated CRL regeneration via cron

In modules/profile/manifests/openvpn_server/config.pp, add:

cron { 'regenerate_openvpn_crl':
  command  => "cd ${openvp_config_directory} && /usr/share/easy-rsa/easyrsa --vars=${openvp_config_directory}/vars gen-crl && systemctl reload openvpn-server@server",
  user     => 'root',
  hour     => 3,
  minute   => 0,
  monthday => 1,  # Run on the 1st of each month
  require  => Exec['generate_gen_crl'],
}

Alternatively, replace the creates parameter with a check that validates CRL expiration and regenerates when needed.

Temporary Workaround

Manual CRL regeneration (requires SSH access to OpenVPN server):

cd /etc/openvpn
cat /etc/openvpn/ca_passphrase | /usr/share/easy-rsa/easyrsa --vars=/etc/openvpn/vars gen-crl
systemctl restart openvpn-server@server

Questions

1. How did the CRL get generated initially without the passphrase? Was the CA created manually outside of Puppet?
2. Should we also increase EASYRSA_CRL_DAYS to reduce regeneration frequency?

Environment

• Puppet module: profile::openvpn_server
• Affected files:
  • modules/profile/manifests/openvpn_server/config.pp
  • modules/profile/templates/openvpn_server/vars.erb
• OpenVPN server: Ubuntu Noble (24.04)
• Easy-RSA version: 3.x

[akuzminsky]

Root Cause Analysis

The CRL regeneration issue has two underlying causes:

1. Puppet creates parameter: The generate_gen_crl exec only runs once because of the creates parameter. Once crl.pem exists, Puppet won't regenerate it even after expiration (180 days per EASYRSA_CRL_DAYS).

2. Missing passphrase configuration: The CA private key is encrypted (production shows -----BEGIN ENCRYPTED PRIVATE KEY-----), but EASYRSA_PASSIN was removed in PR Give permissions to read crl.pem #197. Without the passphrase, gen-crl cannot read the CA key to sign a new CRL.

Solution (development environment)

Changes to config.pp:

• Added EASYRSA_PASSIN and EASYRSA_PASSOUT to generate_ca exec for encrypted CA support
• Added EASYRSA_PASSIN to generate_server_key and generate_gen_crl execs
• Added EASYRSA_REQ_CN to generate_ca environment (required for batch mode, but conflicts with build-server-full if set in vars file)
• Removed inline option from build-server-full (not supported in Easy-RSA 3.1.7)
• Added trailing newline to passphrase file content (OpenSSL requirement)
• Created CRL regeneration cron job - runs monthly on the 1st at 3 AM

Changes to vars.erb:

• Removed EASYRSA_NO_PASS 1 - this was creating unencrypted CA keys, inconsistent with production

New file regenerate-crl.sh.erb:

Script for automated CRL regeneration that:

• Reads passphrase from file
• Runs easyrsa gen-crl
• Reloads OpenVPN service

Technical Notes

OpenSSL 3.x Compatibility

The file: prefix for EASYRSA_PASSIN doesn't work reliably with OpenSSL 3.x (Ubuntu 24.04):

Error reading password from BIO

Solution: Use pass: prefix instead, passing the passphrase value directly:

environment => [
  "EASYRSA_PASSIN=pass:${ca_passphrase}",
]

EASYRSA_REQ_CN Placement

Setting EASYRSA_REQ_CN in vars file causes conflicts:

Option conflict: build-server-full does not support setting an external commonName

Solution: Set EASYRSA_REQ_CN only in the generate_ca exec environment, not in the vars file.

Verification

Tested on fresh deployment:

• ✅ CA key is encrypted (-----BEGIN ENCRYPTED PRIVATE KEY-----)
• ✅ Server key generated successfully
• ✅ CRL generated with correct permissions (0640, root:nogroup)
• ✅ Cron job installed: 0 3 1 * * /etc/openvpn/regenerate-crl.sh
• ✅ OpenVPN service loaded