Your VPN Certificate Expires Today: What Actually Stops

The expiry alert fires, the tunnel is still passing traffic, and nobody can agree whether the date matters. It does, but not always at the instant printed on the certificate. An expired certificate stops new authentications, and it stops the revalidations some implementations perform inside a long-lived session. Whether your existing tunnel dies at midnight depends on the protocol, the client and the server's renegotiation settings. Plan the renewal before the date and verify it with a fresh login rather than with the session that was already up.

Find which certificate is actually expiring

A deployment holds a server leaf, client credentials, one or more intermediates and a trust anchor, and they do not expire together. Read the certificate named in the error and the chain it was presented with, not the first file in the profile directory. A server leaf that renews cleanly can still fail if the intermediate above it expired. Write down subject, issuer, not-after and the deployment location of each file before you change anything.

The trust anchor is usually the longest-lived object and the least likely to be the cause.

Why a live session can outlast the date

Authentication happens at connection setup, and some protocols re-check identity later. OpenVPN renegotiates the data channel on a timer, so a renegotiation presenting an expired certificate fails even though the tunnel has been up for hours. Implementations that never revalidate can carry an established session past the expiry date, which is why "it still works" is not evidence. Neither behaviour is something you can plan around.

Treat the date as the deadline for new logins, and the session lifetime as borrowed time.

Check the clock before blaming the certificate

Validity is evaluated against the local clock, so a device with the wrong time reports a validity failure for a certificate that is perfectly current. Check the client, the server and any appliance in the path.

A clock that resets on boot explains failures that appear only after a power cut.

Renew through the authority that issued it

Keep the identity, the intended purpose and a compatible key configuration. If the renewal introduces a new issuer or a pinned certificate, clients need a coordinated trust update rather than a server file swap. Protect private keys during issuance and distribution, because a renewed certificate does not revoke a compromised old key. A password reset is not a renewal, whatever the ticket says.

Publish the new chain completely, since a leaf without its intermediate is a half-renewal that works only on machines that already cached it.

Prove it with a fresh login, keep a rollback

After deployment, establish a new permitted connection from a representative client and exercise the actual application. Check that the chain is delivered as clients expect and that any revocation information is reachable. Keep a rollback that does not depend on trusting expired material, so you can return to the previous state without weakening verification. Remove the obsolete files only after the replacement is verified.

Existing sessions may still reflect earlier state, so they prove nothing either way.

The order I use on the day

Confirm the expiring object and its chain, then confirm the clocks:

• Which certificate expires, and which chain it belongs to.
• Whether every intermediate is deployed and published.
• Client and server clocks agree within a reasonable margin.
• A fresh login succeeds from a representative client.
• Revocation information is reachable.
• A rollback exists that does not weaken verification.

Then renew, deploy the full chain, test with a new login, and only afterwards clean up. Validity periods and the rules for evaluating them are defined in RFC 5280, and the date is not a surprise if your monitoring watched the object that actually expires.