VPN certificate not valid yet: three causes, one check order
Not-yet-valid means the device clock is behind, the window really starts later, or an intermediate has not opened yet. Check them in that order.
You open the client, choose the profile you have used for months, and it stops with "certificate is not yet valid". Nothing about your sign-in changed, and the trust store is probably fine: the certificate presented in the handshake carries a validity window that starts later than the instant the verifier is using. Three different situations produce that exact message, and they call for different actions. The order below tells you which one you have before you touch a clock or a certificate file.
Which of the three causes you are looking at
The first cause is local: the device doing the check holds a clock earlier than the certificate's start date. You see it on hardware with a dead CMOS battery, on virtual machines restored from an old snapshot, on appliances that sat powered off long enough to lose time, and on networks where outbound NTP is blocked and nobody noticed. The certificate can be entirely valid and still fail this way.
The second cause belongs to the issuer, because the certificate really does begin in the future: issued early, generated with an explicit start time, or signed as part of an activation step that has not run. The third cause wastes the most time, because the leaf is current while another certificate in the presented chain is not, so the error names material you never installed.
One question separates them. Does the failure follow the device or the service? Two machines on the same network behaving differently points at clocks. Every client failing the same way points at the certificate's window and the chain behind it.
Read the window from the certificate that was actually presented
Do not inspect a PEM file left over from an earlier deployment; ask the service for the chain it sends right now. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts prints every certificate in the chain. Save the block you care about and run openssl x509 -noout -subject -issuer -dates; the last of those prints notBefore and notAfter, which are the two values that decide this. On Windows, the certificate dialog for the connection and certutil -dump on an exported file show the same fields.
Read both ends of the window, not only the start. A certificate that opens in two hours and one that closes in two hours fail with different messages and involve different teams. Note which certificate the error names, whether leaf, intermediate, or root, because that decides whether anything on the client side can be fixed at all.
You can also test the window without waiting for it. Verification accepts an explicit time: openssl verify -attime 1793600000 -CAfile ca.pem -untrusted intermediate.pem leaf.pem evaluates the chain as of that timestamp. Run it with the current time to reproduce the failure, then with the certificate's start time to confirm that the same chain passes once the window opens. RFC 5280 defines the validity field and the rule that a certificate must not be used outside it, which is the rule your client just enforced.
Your clock, or theirs
Compare the device clock with the certificate's start in UTC, from a source you trust. date -u gives the instant, and timedatectl status on a systemd host also reports whether the clock is synchronized. On Windows, w32tm /query /status shows the current source and the last successful sync. A timezone shown in the tray is a display choice, not a wrong clock; the verifier compares UTC instants.
| What you see | Most likely reading | Next step |
|---|---|---|
| Clock behind, one device affected | Local time fault | Resync time, keep validation on, retest |
| Clock correct, window opens soon | Certificate staged early | Wait for the window or follow the cutover plan |
| Clock correct, intermediate not yet valid | Chain material mismatch | Operator replaces the intermediate |
| Some peers pass, others do not | Inconsistent nodes | Record each peer's chain before changing anything |
If the clock is behind, resynchronize and retest before changing any certificate material. A device that is minutes or hours off rejects every recently issued certificate it meets, not just one service, so a single-service explanation is usually the wrong one. If the clock is correct and synchronized, stop looking at the device: the window belongs to the issuer, and no local setting should be adjusted to make it pass.
That table is the whole decision. Moving your clock to whatever the certificate expects is not a repair, and turning off time checks is not one either, because both hide the condition that produced the error.
Why the chain fails while the leaf looks fine
Renewed leaves and replacement intermediates usually ship together, and they do not always land at the same moment. A service can send a new leaf signed by an intermediate whose own window starts later, or keep serving an older intermediate under a fresh leaf. Either way the chain fails while the leaf's own dates look reasonable.
Load-balanced endpoints turn this from broken into inconsistent. If a retry succeeds, or one network works while another does not, record which peer answered and which chain it sent before changing settings. openssl s_client prints the connected address, so a few attempts reveal whether every node serves the same chain.
Repair paths that keep validation intact
A clock problem is fixed on the device with validation left enabled. A certificate problem is fixed by the operator with material issued for a window that already includes now. No client setting makes a not-yet-valid certificate valid; the flags that skip time checks exist so you can confirm a diagnosis, not so you can ship them.
When the certificate is staged for a planned activation, follow the cutover plan. Install it when its window opens, or use the overlap procedure the provider documents, rather than installing early and teaching users to click through warnings. Warnings that people learn to dismiss cost more than a short delay.
Finally, retest the way the failure happened: a new session, the same client, the resource you actually need. TLS libraries may cache a verified chain for the life of a connection, and a resumed session does not necessarily check it again, so an old session can keep failing after the fix or keep working after a regression. A file that opens in a viewer only proves the file is readable; a completed handshake proves that the chain validates.
Before you close the ticket, confirm four things: the failing device's UTC time and sync state, the notBefore and notAfter of each certificate in the presented chain, the same chain from a second client, and the name the error puts on the certificate. If the clock is right and the window has not opened, the rest is the operator's work, and the correct move on your side is to wait for the window instead of weakening the check.