OpenVPN Certificate Renewal: Deliver the Cert, Not the Timer

Two renewal designs look identical in a design review and behave nothing alike in January. The first runs a timer, reissues certificates and drops files into a share. The second treats renewal as a delivery problem: who asks, what proves eligibility, how the material reaches the device, and what makes the client use it. Only the second one survives an offline laptop, a retired asset and a delivery that silently failed.

Compare the two designs where they actually differ

The timer design optimizes for the server side. A scheduled task calls the CA, a new certificate appears, and the operator considers the job done. Everything that happens after issuance is somebody else's problem until a device fails to connect and the expiry date explains why.

The workflow design optimizes for the last mile. It assumes issuance is one step in a chain and that each later step can fail independently. That costs more to build and much less to operate, because the failures show up as tracked states instead of as expired clients.

A useful way to hold the difference in view is the sequence each design has to name explicitly.

detect window -> authenticate request -> authorize -> issue
-> deliver and stage -> activate -> verify fresh auth -> retire old material

Detect the window from the certificate itself

Read the validity from the certificate the client is actually presenting, not from the date embedded in a copied filename. Filenames drift, and a file that says 2026 can hold a credential that expires in March.

Leave slack in the window for the slow cases: devices that are offline for weeks, approvals that need a person, and delivery paths that fail once before they work. A timer that reports success proves the timer ran, nothing more.

Authorize the request before anything is issued

An existing certificate can be part of a legitimate renewal mechanism, but its subject text is not an authorization decision. The question to answer is whether this account and this device are still entitled to an identity in the fleet, and that answer lives in your asset records rather than in the certificate.

A retired laptop whose scheduled task still runs should not receive a fresh entitlement. RFC 7030 is worth reading here because it separates authenticated reenrollment from server-side authorization and policy; it is a model to borrow from, not a claim that OpenVPN or EasyRSA ships that protocol.

Deliver, stage and activate as separate steps

Issuance preserves identity, purpose and issuing relationship, and a replacement generated with a new key pair is useless unless the matching key travels with it. Deliver the pair over a channel with an access-control design behind it, because an unguessable URL is obscurity rather than control.

Staging is where most automation quietly breaks. An imported profile can sit in one location while an administrator updates a file somewhere else, and the client keeps presenting the old certificate until someone notices. Write down the path the client reads, the account that may write it, and the event that triggers a reload. Then confirm the replacement is the file actually in use rather than a copy that arrived beside it.

Verification means a fresh authentication with the new material and a check of the application the user needs. A tunnel that was already established may still reflect the previous credential, so an open connection is not evidence of a successful renewal.

Design the missed-window recovery first

When a laptop only reaches the enrollment service through the VPN, expiry creates a loop: the device needs a certificate to enter the tunnel and the tunnel to fetch the certificate. Decide the out-of-band arrangement before the first scheduled task ships, whether that is a separately authenticated enrollment endpoint or administrator-assisted re-enrollment.

Whatever you choose has to verify the requester and the current entitlement. Configuring the server to accept expired certificates from anyone who asks is not a recovery path, it is a permanent weakening of the check you spent the rest of the design defending.

Finally, keep renewal and compromise in separate procedures. A leaked key needs revocation and a response to active sessions, and extending the expiry date contains none of that. Include an offline device, a failed delivery and a retired asset in the acceptance test, and the schedule is ready to enable.