BadCertificateIssuerTimeInvalid

BadExpiry / clock skew

What you actually see

Every application certified by one CA stops connecting at the same moment, and the individual application certificates are all well within their own validity periods.

Why it happens

• The CA certificate has expiredIntermediate CAs typically have shorter lifetimes than roots, and a sub-CA issued for a few years will expire while the certificates it signed are still in date. Nothing warns you unless someone is tracking CA expiry, so the whole branch fails on one day.
• Clock skew on one of the machinesValidity is judged against the local clock. A host whose clock is wrong by days - a device with no battery-backed clock, a VM resumed from a snapshot, a container in an environment with no time source - will judge a perfectly current CA as expired or not yet valid. The peer sees no problem at all, which is the diagnostic clue.
• A newly issued CA whose validity starts in the futureA CA issued with a not-before date in the future, or issued in a different time zone and interpreted incorrectly, is not yet valid. The failure appears immediately at deployment rather than after years of service.
• Retired CA still in the presented chainA peer that still sends an expired intermediate builds a chain that fails on the CA's dates, even though a current path exists. The fix is at the peer's certificate bundle, not in your trust store.
• Root CA expiry at the end of a long lifetimeRoots are issued for long periods and are then forgotten. When one finally expires, everything beneath it fails simultaneously across the plant. It is rare per site and severe when it happens, and it is entirely predictable if anyone is tracking it.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Dump the whole chain and read every validity periodPrint not-before and not-after for the application certificate and for each CA above it. Identify which certificate is outside its window. This distinguishes a CA expiry from a clock problem faster than anything else, because a clock problem usually makes several certificates look wrong at once.
2. Check the clocks on both machinesCompare the system time on the client host and the server host against a reliable source. A skew of more than a few minutes is a problem in its own right for OPC UA, since timestamps and certificate validity both depend on it. Fix time synchronisation before touching certificates.
3. Reissue the CA and everything it signedAn expired CA must be replaced. Issue a new CA with a suitable lifetime, reissue the application certificates it signed, distribute the new CA into every issuer and trusted store, and remove the expired one. Plan this as a migration, not as an incident.
4. Update the peer's presented chainWhere the CA is current but the peer sends a retired intermediate, update the peer's certificate bundle so it presents the valid path. Nothing you change on your own side will help, which is why this variant is often misdiagnosed.
5. Treat suppression as a bridge, not a fixThis condition is in the suppressible set, so a validation callback can accept it to keep a plant running while the reissue is prepared. Scope it narrowly, record it, and set an end date, because accepting an expired CA removes a real control.
6. Set up expiry monitoring for CAs, not only for leaf certificatesMost monitoring watches application certificates and ignores the CAs above them. Add every CA in the hierarchy to the same monitoring with a lead time long enough to run a migration - months, not days.

Where it shows up, by tool and stack

What it looks like in the log

Chain validation failed: issuer CN=Plant Sub CA 2021 notAfter 2026-08-30T00:00:00Z
Local time 2026-09-08T04:20:11Z; peer reports certificate not yet valid
34 endpoints failing simultaneously; common issuer CN=Plant Sub CA 2021

Confirm the fix

Confirm every certificate in the presented chain is within its validity period as judged by both machines' clocks, and that the two clocks agree to within a minute, then confirm a previously failing application connects.

Stop it happening again

Monitor expiry for every CA in the hierarchy with months of lead time, keep time synchronisation working on every OPC UA host including embedded ones, and schedule CA renewals as planned migrations rather than discovering them as outages.

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.