OpenVPN Certificate Expired? Check the Clock, Then the Cert

The client connects, negotiates for a second, and then reports that a certificate has expired. Before you ask anyone to reissue anything, look at the date on the device in front of you: a laptop that has been asleep for a month, a phone with a manual clock and a router without a working NTP source all report the wrong moment to a TLS stack. A certificate is only valid inside a window, and the check compares that window against whatever the local clock claims. Get the clock right, then decide whether the problem is real.

Start with the clock on the device

Open a terminal and read the system's idea of UTC, not the desktop clock widget, which may show a timezone-adjusted view or a stale value cached by the GUI.

date -u
timedatectl status

A clock far ahead makes a valid certificate look expired, and one far behind makes it look not yet valid, which some clients report with the same generic handshake failure. If synchronization is disabled or the time source is unreachable, fix that first and retest before touching any file. Setting the clock backward to get past an expiry is not a fix: it breaks other services on the device and leaves the identity problem exactly where it was.

If the clock is correct, the expiry is real and the rest of this walkthrough applies. Note which timezone the client's log uses before comparing timestamps from two devices. A server in another zone can make a renewal look early or late when it was neither. Compare against the timestamp in the client's own log line rather than the wall clock on your desk.

Read the error line before the profile

Keep the exact text. OpenVPN's verification failure names a depth and a reason, and those two fields tell you who has to act.

A VERIFY ERROR with error=certificate has expired is a validity failure at a specific point in the chain. It is not a password rejection and not a timeout, and the three need different responses.

Copy the whole line into your notes together with the client version. If the message instead says the certificate is not yet valid, you are back at the clock question. If it says the issuer is unknown, you have a trust problem rather than a lifetime problem, and no amount of renewal will change it.

Find which certificate expired

Depth zero is the certificate presented by the peer you connected to, and higher depths walk toward the root. A work VPN usually expires a client identity or a server certificate, and occasionally an intermediate that the organization forgot it owned.

Print the dates of the files the profile actually references, starting with the one at the depth named in the error.

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl x509 -in ca.crt -noout -subject -dates

If the profile embeds certificates as inline blocks instead of pointing at files, the separate files on disk may be older or newer than what the client is using, which is why matching the error to a file requires reading the profile rather than the directory listing.

Renew through the issuer

A client certificate is replaced by whoever issued it, and an account password reset does not renew anything. For a work connection, use the renewal channel your organization publishes; for a hosted service, sign in to the provider's portal through a verified address rather than opening an attachment that claims to contain a new profile. An unsolicited bundle is not trustworthy because its filename mentions VPN.

If you operate the server, check the public details and the issuance records before replacing material, because a CA change affects every client that trusts it.

Renewing one identity should not require replacing the trust hierarchy. If someone proposes a new CA to fix a single expired leaf, ask what else depends on the old one first. The RFC 5280 validity and path rules are the model both sides are following.

Make the client use the replacement

Downloading a file is not importing it. Check the connection entry you actually select, and check whether the profile references external certificate paths that you forgot to overwrite.

Keep the old entry visible until the new one connects, then remove it so nobody selects the expired profile by habit. Reconnect and confirm that the specific expiry error is gone.

If a different TLS error remains, treat it as a new problem rather than weakening verification settings to get past it. An account rejection or a missing route after a successful renewal is a separate fault with a separate fix.