BadCertificateRevoked

BadCRL

What you actually see

A connection that previously worked fails at the handshake with this code, and the peer certificate lands in the rejected store while the endpoint itself is reachable.

Why it happens

• The certificate genuinely was revokedAn administrator revoked it because the private key was compromised, the device was decommissioned or replaced, or the certificate was reissued with corrected details. The revocation is doing its job. The remedy is a new certificate, not a change to the validation.
• Device replaced but the old certificate still deployedA hardware swap where the replacement was imaged from the old device, or a container rebuilt from a snapshot containing the retired key pair, puts a revoked certificate back into service. It looks like a new deployment failing for no reason.
• Certificate reissued but the old one still in use somewhereWhen a certificate is reissued and the old serial revoked, any component still holding the old file fails. In a fleet this is usually one or two stragglers - a redundant partner, a test client, an image used for new installs - and they fail while everything else works.
• Wrong CRL loaded for the issuerA CRL from a different CA, or from a different sub-CA of the same hierarchy, can produce spurious matches or mask real ones depending on how the stack matches issuers. Mixing CRLs from a hierarchy without keeping them alongside the right issuer certificate is the usual mistake.
• Serial number collision from a badly managed CACertificates issued with duplicated or predictable serial numbers can collide with a revoked entry. Rare, but it happens with hand-rolled CAs using scripts that reset a serial counter, and the symptom is a brand-new certificate reported as revoked.

How to fix it

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

1. Read the certificate's serial number and confirm it is on the CRLExtract the serial from the rejected certificate and check it against the CRL in your issuer store. Confirm the CRL's issuer matches the certificate's issuer exactly. This tells you within a minute whether the revocation is real or a mismatched CRL.
2. If the revocation is real, issue a new certificateGenerate a new key pair and certificate with the correct SubjectAltName entries - the ApplicationUri as a URI entry plus the DNS names or IP addresses of the endpoint - install it in the application's own store, and distribute the new certificate to every peer's trust list.
3. Find every copy of the revoked certificateSearch your deployment for the revoked serial: golden images, container base layers, configuration backups, redundant partners and test rigs. A revoked certificate that survives in an image will reappear at the next deployment and the failure will look new.
4. Do not fix it by deleting the CRLRemoving the CRL to make the error go away also removes your ability to detect a genuinely compromised certificate, and it will typically convert this failure into a revocation-unknown condition instead. If you cannot maintain CRLs, that is a PKI design problem to solve deliberately, not by deletion.
5. Verify the CRL is current and correctly placedCRLs expire. Confirm the CRL's next-update time is in the future and that it sits in the CRL location of the PKI layout alongside the issuer certificate it belongs to, in the store structure your stack expects.
6. Clear the rejected store after the fixRemove the revoked certificate from the rejected store so a later investigation is not misled by it, and confirm the new certificate appears in the peer's trusted store rather than in rejected.

Where it shows up, by tool and stack

What it looks like in the log

Certificate validation failed: BadCertificateRevoked (serial 3f9a2c, issuer CN=Plant Sub CA)
Peer certificate found on CRL; connection rejected and certificate stored in rejected
CRL nextUpdate 2026-08-31T00:00:00Z has passed for issuer CN=Plant Sub CA

Confirm the fix

Confirm the new certificate's serial does not appear on any CRL in the issuer store, then connect and confirm the handshake completes and the certificate appears in the trusted store on both sides.

Stop it happening again

Track certificate serials against devices in an inventory so a revocation can be traced to every copy, rebuild golden images and containers with fresh certificates rather than baked-in ones, and automate CRL refresh so lists never go stale.

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.