Status code · Certificates
BadCertificateIssuerRevocationUnknown
BadCRL
BadCertificateIssuerRevocationUnknown means revocation status could not be determined for a CA certificate in the chain, not for the peer certificate itself. Install a current CRL for every CA above the failing certificate, including the root, in the crl folder of the store holding that CA.
Defined behaviour: It was not possible to determine if the issuer certificate has been revoked. (our description of the condition this code reports)
What you actually see
Validation completes on the peer certificate but fails on one of the CA certificates above it, typically in a two-tier PKI where only the sub-CA's CRL was installed.
Why it happens
- A CRL exists for the sub-CA but not for the rootEach CA in the chain needs its own CRL. Installing the issuing sub-CA's CRL fixes BadCertificateRevocationUnknown for the leaf and then exposes the root's missing CRL as this code. Two-tier PKIs therefore need two CRL files, not one.
- The root CRL has expiredOffline root CAs publish CRLs rarely and with long validity, and organisations forget to re-publish. Once nextUpdate has passed, the file is discarded and the issuer's status becomes unknown again, which takes down every OPC UA connection in the plant at once.
- The CRL is filed against the wrong storeAn intermediate CA held in the issuer store needs its CRL in issuer/crl; a root held in trusted needs it in trusted/crl. Putting every CRL in one folder works on some stacks and not others, which makes the failure look intermittent across vendors.
- CA key rollover left a CRL that covers only new issuanceAfter a CA renewal the old CA certificate stays in the chain for previously issued leaves. Its CRL, signed by the retired key, must stay installed too. Replacing it with the new CA's CRL leaves the old issuer unknown.
- Delta CRLs or partitioned CRLsSome enterprise CAs publish a small delta CRL plus a base CRL. OPC UA stacks generally read a plain base CRL. Installing only the delta leaves the validator unable to establish full revocation status for that issuer.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Enumerate the whole chainPrint the chain with openssl x509 -in peer.der -inform der -noout -issuer, then repeat for each CA certificate you hold until you reach a self-signed root. You now know exactly how many CRLs you need - one per CA.
- Export a current base CRL per CAOn AD CS, certutil -CRL on each CA writes to its CertEnroll share; take the base CRL, not a delta. With OpenSSL, openssl ca -gencrl -config ca.cnf -out ca.crl. Verify each with openssl crl -in ca.crl -inform der -noout -text.
- Install each CRL beside its CA certificateRoot CA certificate in trusted/certs means its CRL goes in trusted/crl. Intermediate in issuer/certs means its CRL goes in issuer/crl. Do this on both peers of the connection.
- Reload the trust configuration and reconnectRestart the application or trigger a trust-list reload. If you now see BadCertificateIssuerRevoked, the CRLs are being parsed and one of the CAs is genuinely listed as revoked - a much more serious finding that needs the PKI owner.
- Put CRL refresh under a schedulePull each CA's CRL on a timer well inside its validity period and push it to every PKI store. A Global Discovery Server using the push model can maintain the trust list and CRLs on the devices for you.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | This error is on the suppressible list, so a validation-callback handler can accept it. Many field deployments do exactly that and then have no revocation checking at all, which is worth knowing when auditing someone else's configuration. |
| UaExpert | The dialog distinguishes issuer revocation problems from certificate revocation problems. Accepting once confirms the diagnosis; the durable fix is dropping the CA CRLs into UaExpert's PKI folders. |
| open62541 (C) | The revocationList passed to UA_ClientConfig_setDefaultEncryption must contain a CRL for each entry in issuerList and trustList, not just for the direct issuer. Embedded deployments should provision all of them at image build time. |
| node-opcua | Place root CRLs in trusted/crl and intermediate CRLs in issuers/crl within the certificate manager root folder, then re-initialise the manager so the revocation cache is rebuilt. |
| OPC Publisher | Publisher's pki volume carries the same store layout, including crl folders. Because the volume is often mounted read-only from a config map or secret, refreshing CRLs means updating that mounted content, not writing into the container. |
| Prosys | Prosys tools use a PKI directory with the standard subfolders; CRL files placed in the matching crl directory are picked up on restart. Check the application data path rather than the installation directory. |
What it looks like in the log
Certificate validation failed. Error: BadCertificateIssuerRevocationUnknown. No CRL found for issuer CN=Plant Root CA
Issuer revocation status unknown: CN=Plant Sub CA 1 (CRL nextUpdate 2026-06-01 has passed)Confirm the fix
After reconnecting successfully, list every CA certificate in your trusted and issuer stores and confirm a CRL with a future nextUpdate exists in the matching crl folder for each one.
Stop it happening again
Treat CRL publication as a monitored service: alert on any CRL whose nextUpdate is within a few days, and distribute CA certificates and their CRLs as an inseparable pair to every device.
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.