Status code · Certificates
BadCertificateTimeInvalid
BadExpiry / clock skew
BadCertificateTimeInvalid means the peer certificate's validity window does not contain the current time. Either the certificate really has expired, or one machine's clock is wrong. Check the notBefore and notAfter dates against both systems' clocks before assuming you need a new certificate.
Defined behaviour: The certificate has expired or is not yet valid. (our description of the condition this code reports)
What you actually see
A connection that worked for months fails overnight, or a brand-new device fails immediately on first connect with a certificate validity error.
Why it happens
- The certificate has genuinely expiredSelf-signed application instance certificates are often generated with short lifetimes and then forgotten. Whole fleets commissioned in the same week expire in the same week, which is why this failure tends to arrive as a plant-wide event rather than as one broken device.
- Clock skew on either machineValidation compares notBefore and notAfter against local time. A PLC or embedded server whose clock is hours or years out will reject a perfectly valid certificate, and a client with a wrong clock will reject the server's. Clock skew is a security failure in OPC UA, not just a data-quality problem.
- A device booted before NTP synchronisedEmbedded servers frequently start at an epoch default such as 1970 or the firmware build date, open their endpoint, and validate certificates with that wrong time. Connections made in the first seconds after boot fail and then succeed once NTP lands, which reads as an intermittent fault.
- notBefore is in the futureA newly issued certificate whose notBefore was set with a timezone error, or issued by a CA whose own clock is ahead, is not yet valid. This is the version of the fault that hits new commissioning rather than long-running systems.
- A container regenerated its certificate with a bad clockA container without a persistent pki volume regenerates its identity at each start. If it also lacks correct time, the new certificate carries a wrong validity window that every peer refuses.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Print the validity windowRun openssl x509 -in peer.der -inform der -noout -dates on the certificate from the rejected store. You get notBefore and notAfter in UTC. Write them down before touching anything.
- Compare against both clocksCheck the current UTC time on both the client and the server host, not just the one showing the error. Read the server's own ServerStatus CurrentTime through any working connection, or check the device web interface. A skew of hours or years is immediately obvious against the certificate dates.
- Fix the clock first if it is wrongCorrect the time and point the host at a reachable NTP source. On plant networks that usually means an internal NTP server, since external pools are blocked. Restart the OPC UA application after the correction so it re-evaluates with the right time.
- If the certificate is genuinely expired, reissue itGenerate a replacement keeping the same ApplicationUri in the SAN and the same DNS entries, for example with -days 730. Install it as the application's own certificate and update peer trust stores, since the thumbprint changes.
- Reconnect and clear the stale rejected entriesDelete the expired certificate from peer trusted stores and remove old files from rejected so the next failure is unambiguous. Then reconnect and confirm the session activates.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UaExpert | The validation dialog shows the certificate's valid-from and valid-to dates, which makes the clock-versus-expiry question answerable in one glance. The error is suppressible for the session, which is useful for diagnosis while a clock is being fixed. |
| UA-.NETStandard (C#) | Validity is checked in validation step 5 and this code is suppressible. The stack can renew its own self-signed certificate on startup when the existing one has expired, depending on configuration, which sometimes fixes the server side and leaves every client's trust list stale. |
| open62541 (C) | On embedded targets without a battery-backed clock, certificate validation is the first thing broken by a wrong time. Provision NTP or an RTC before enabling security; there is no way to validate dates without a trustworthy clock. |
| Siemens S7-1500 | The controller's time and its OPC UA server certificate validity are managed in the device configuration. A controller whose time-of-day was never set, or set without the correct timezone and daylight offset, produces this error against otherwise valid client certificates. |
| node-opcua | The certificate manager reports expiry distinctly from trust problems and can generate a fresh self-signed certificate with a chosen validity. Regenerating changes the thumbprint, so plan the trust-list update at the same time. |
| OPC Publisher | In containers, check both the pki volume persistence and the container clock. A restart that regenerates the certificate and a host clock that is wrong combine into a certificate no peer will ever accept. |
What it looks like in the log
Certificate validation failed. Error: BadCertificateTimeInvalid. Certificate CN=plc-01.plant.local expired on 2026-08-31T00:00:00Z
Certificate is not yet valid: notBefore 2026-09-10T00:00:00Z, current time 2026-09-07T11:22:03ZConfirm the fix
Reconnect and confirm the session activates, then check that both hosts agree on UTC within a second or two and that notAfter is far enough away that the certificate is not about to fail again.
Stop it happening again
Run NTP on every OPC UA host including embedded servers, and monitor certificate notAfter dates across the fleet with an alert well before expiry so renewal is scheduled rather than reactive.
Related status codes
Concepts on this page
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.