Renewing Certificates with EasyRSA

When managing PKI with EasyRSA, you sometimes need to extend the validity of an existing certificate without replacing the private key. This is common for servers, appliances, or infrastructure systems where replacing keys would require additional configuration changes.

Prerequisites

  • EasyRSA 3 or newer
  • An existing PKI (root or intermediate CA)
  • An already issued certificate you want to renew
Note on Zero Trust PKI with Easy-RSA
A dedicated article has been created that explains the Zero Trust PKI approach using Easy-RSA. It covers the step-by-step setup, including CA hierarchy design, intermediate CA usage, certificate issuance workflows, and operational best practices for maintaining a secure and scalable PKI model.
You can find the full guide here

Example environment using an intermediate CA:

EASYRSA_PKI=intermediate

Certificate Inspection Commands (Easy-RSA)

To inspect the current certificate request and the issued certificate for a specific host, the following Easy-RSA commands can be used. The request can be viewed with show-req, while the corresponding signed certificate can be displayed using show-cert. These commands help verify SANs, subject information, and overall certificate integrity:

EASYRSA_PKI=intermediate ./easyrsa show-req host.examplecorp.io
EASYRSA_PKI=intermediate ./easyrsa show-cert host.examplecorp.io

Renewing a Certificate

Renewing a Certificate without or with Subject Alternative Names

Example certificate: 

host.examplecorp.io

or

CN: host.examplecorp.io
SAN: DNS:host.examplecorp.io,DNS:hostalias.examplecorp.io

Renew the certificate:

su - pki
cd easy-rsa
EASYRSA_PKI=intermediate ./easyrsa renew host.examplecorp.io nopass

Result:

  • A new certificate with a new validity period is issued
  • The private key remains unchanged
  • The certificate file is written to: intermediate/issued/host.examplecorp.io.crt

Deployment

host.examplecorp.io.crt → replace the existing certificate
host.examplecorp.io.key → keep the existing private key
ca.crt → unchanged

What Happens to Existing Files

During renewal:

  • host.examplecorp.io.crt in issued/ is overwritten
  • host.examplecorp.io.key remains unchanged
  • CA files are not modified

If the previous certificate needs to be preserved, create a backup before renewal.

OpenSSL Certificate Validation Check

To validate an issued certificate and verify both the Subject Alternative Names (SANs) and expiration date, OpenSSL can be used. This is especially useful for quickly confirming that the certificate contains the correct DNS entries and is still valid:

openssl x509 -in intermediate/issued/host.examplecorp.io.crt -text -noout | grep -E "DNS:|Not After"

Check:

  • Validity period
  • Common Name
  • Subject Alternative Names (if used)

Easy-RSA Bug and Missing Dependency Issue

During certificate lifecycle operations, a critical issue was observed in Easy-RSA 3.2.1-2 where both automated renewal and manual certificate re-issuance workflows failed to correctly preserve or generate Subject Alternative Names (SANs). Specifically, when executing either a direct renewal:

EASYRSA_PKI=intermediate ./easyrsa renew host.examplecorp.io

or a manual re-issuance workflow using expire and re-sign:

EASYRSA_PKI=intermediate ./easyrsa expire host.examplecorp.io
EASYRSA_PKI=intermediate ./easyrsa sign-req server host.examplecorp.io

the resulting certificates were consistently generated without the expected SAN entries. This behavior effectively broke certificate consistency and made the issued certificates unusable for production TLS validation scenarios where DNS SANs are required.

In addition to this functional regression, the issue appears to be related to missing internal tooling dependencies introduced in Easy-RSA 3.2.x, specifically the easyrsa-tools.lib requirement referenced in upstream discussions and documented issues:
https://github.com/OpenVPN/easy-rsa/issues/1281

Due to the combination of broken SAN handling and the missing dependency preventing reliable renew behavior, a rollback was performed from version easy-rsa-3.2.1-2.el9.noarch to the last stable and functional version easy-rsa-3.1.6-1.el9.noarch, which restored expected certificate generation behavior and proper SAN handling.

Related Posts