Reloading keys/certificates without a full restart.

Summary:

A running openvpn server should be able to pick up a new --cert from the filesystem without a full restart that disconnects existing peers.

Use Case

We issue client certs from our internal CA, but not server certs. This is based on a policy at $WORK.

In my setup, the server's server.conf has:

• --ca of 'the root CA of an internally-managed PKI setup'
• --key of 'the server's key'
• --cert of '(a publicly-signed 1year cert) and (a 10year intermediate) from Sectigo'

The clients have

• --ca of 'Sectigo's root CA'
• --key and --cert from our internally managed PKI

As such, each node has a CA that verifies the peer cert, using separate PKI chains.

Restarts are opportunistic weekend maintenance windows, but since they kick everyone off, we try to minimize them.

While the headline is a bit dramatic, https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days is the main part of the reasoning here: public-issued certs are going to be coming in faster than ever over the coming years. VPN tunnels persist orders-of-magnitude longer than a web hit, so the need to rotate certificates nondisruptively will become apparent as certificate timeframes shorten.

Desired Solution

A server.conf containing (non-inline) cert declarations:

cert /etc/openvpn/server/sitename/server.crt
key /etc/openvpn/server/sitename/server.key

should be able to discover new certs from those files references, and start using them for connections that come in later. Whether that is in the style of --crl-verify ("every peer means we check the filesystem") or an issued command ('HUP' / some signal / some management command), whatever does a "toss out the old key/cert and load the new ones" feels like a Don't Care Which.

Complex edge cases exist, I'm sure, and then there's a question of how far you're willing to let the scope creep here (--dh? --tls-auth?), but, minimally I'm thinking "just the certs" to start with, since that's where certs are heading. I imagine some people would want the current 'must restart' behavior, so I could see having this be an opt-in feature.

Describe alternatives you've considered

I know the first thing people are going to do is solution something at me:

• "you can't use Let's Encrypt for your PKI." I know, and I don't.
• "Use a private CA, you won't have this problem!" Outside of policy.
• "You/your policy is dumb." Thank you, next.
• "Restarts aren't impactful, clients just reconnect." Multifactor makes this not-always-true. Yes,--auth-gen-token-secret helps.

All these suggestions ignore that it shouldn't be necessary to force reconnects for a certificate change.

Without 'graceful' restarts we'll have to work out some multi-host A/B deploys and hope that we can minimize disruptions by steering new connections to newer-cert and draining people from older-cert.

Thanks for reading.

Start by tracing how the server handles the non-inline --cert and --key entries in server.conf, then inspect existing HUP, signal, management-command, or --crl-verify reload paths. Done means a running server can load replacement certificates for later connections without disconnecting existing peers, with the chosen behavior and any opt-in scope documented and tested.