BadCertificateIssuerRevoked

BadCRL

What you actually see

Every application whose certificate came from one particular CA fails to connect at once, while applications certified by a different CA are unaffected.

Why it happens

• Sub-CA deliberately revoked by the rootA sub-CA is revoked when its key is compromised, when it is retired, or when a PKI is restructured. Revoking one sub-CA invalidates everything it signed in a single act, which is the point. The blast radius is every application in that branch.
• PKI migration where the old sub-CA was revoked before the fleet was reissuedMigrations often revoke the old CA on a date and reissue devices over a longer period. Anything not yet reissued fails from that date. The failures look sudden and simultaneous, which is a good clue that the cause is at the CA rather than at the device.
• Stale issuer certificate paired with a current root CRLYour issuer store may hold an old sub-CA certificate while the root's CRL now lists it. The chain builds, then fails at the revocation check. Cleaning out retired sub-CA certificates from issuer stores is part of a migration and is frequently missed.
• Wrong CA in the chain because the peer sends an outdated intermediateA peer configured to send a retired intermediate builds a chain through a revoked CA even though a valid path exists. Updating the peer's own certificate bundle, not your trust store, is the fix in that case.
• Cross-signed hierarchy where one path is revokedWhere a CA is cross-signed, the stack may build a chain through the revoked path while a valid path exists. Chain building order is implementation-specific, so the same certificates can validate on one stack and fail on another.

How to fix it

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

1. Identify the revoked CA and confirm the revocationDump the full chain the peer presented and check each CA certificate's serial against the CRL of its own issuer. Confirm which CA is listed. This is the difference between a PKI-wide action and a single-device fix, so establish it before doing anything else.
2. Re-issue affected certificates from a valid CAEvery application certificate signed by the revoked CA must be replaced. Reissue with the correct SubjectAltName entries and distribute the new certificates. There is no client-side setting that lets you keep using them.
3. Update issuer stores across the fleetRemove the revoked CA certificate from every issuer store and install the new CA chain. Leaving the retired CA in place invites a stack to build a chain through it again after the reissue is otherwise complete.
4. Refresh CRLs for every CA in the hierarchyEach CA needs a current CRL in the CRL location alongside its certificate. A hierarchy with a root CRL and no sub-CA CRL, or with an expired one, produces revocation-unknown conditions once this one is fixed, which is a different failure with a similar cause.
5. Check the CA certificates' key usage while you are thereOPC UA expects every CA certificate in a chain to assert both keyCertSign and cRLSign in its KeyUsage extension. Corporate CAs that omit cRLSign break OPC UA even when the revocation situation is clean, so confirm the new CA carries both.
6. Plan the sequence for the next migrationReissue and distribute first, cut over second, revoke the old CA last. Revoking before the fleet has moved converts a controlled migration into a plant-wide outage, which is what usually produces this code in practice.

Where it shows up, by tool and stack

What it looks like in the log

Chain validation failed: issuer CN=Plant Sub CA 2019 revoked by CN=Plant Root CA
All 34 endpoints certified by CN=Plant Sub CA 2019 failing since 2026-09-01
Issuer store contains retired sub-CA; chain built through revoked path

Confirm the fix

Confirm the presented chain now terminates at a valid, unrevoked CA in your trusted store, that every CA in it has a current CRL, and that a previously failing application connects without its certificate reaching the rejected store.

Stop it happening again

Keep an inventory of which CA signed which application, sequence migrations so revocation is last, purge retired CA certificates from issuer stores as part of the migration, and automate CRL distribution for every CA in the hierarchy.

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.