Status code · Certificates
BadCertificateIssuerUseNotAllowed
BadCA keyUsage
BadCertificateIssuerUseNotAllowed means a CA certificate in the chain does not assert the key usage bits OPC UA requires. Every CA certificate must carry both keyCertSign and cRLSign; corporate CAs that omit cRLSign trip this. The only real fix is to reissue the CA certificate with both bits set.
Defined behaviour: The issuer certificate may not be used for the requested operation. (our description of the condition this code reports)
What you actually see
Certificates issued by a working corporate CA - trusted elsewhere in the enterprise, fine for TLS - are refused by OPC UA applications with an issuer key usage error.
Why it happens
- The CA certificate lacks the cRLSign key usage bitOPC UA requires every CA certificate in a chain to assert both keyCertSign and cRLSign in its KeyUsage extension. Corporate CAs are frequently issued with keyCertSign only, because nothing else in the enterprise checks for cRLSign. Strict OPC UA stacks reject them, and this is the single most common cause of this code.
- The CA certificate lacks keyCertSign, or has no KeyUsage extension at allA certificate used to sign other certificates but without keyCertSign asserted cannot serve as a CA in OPC UA validation. Certificates minted from a generic server template, or old certificates predating strict extension handling, hit this.
- basicConstraints does not mark it as a CAChain building also requires basicConstraints CA:TRUE, and where a pathlen is set the depth must accommodate your chain. A sub-CA issued under a root with pathlen:0 cannot itself issue further CAs, so the intended chain is not permitted.
- A leaf certificate is being used as an issuerThis happens when someone puts an application instance certificate into the issuer store to try to fix a chain error. It has no CA key usage bits, so it is refused as an issuer. Only real CA certificates belong in issuer.
- extendedKeyUsage on the CA is too narrowA CA certificate carrying a restrictive extendedKeyUsage can constrain what the leaves below it may be used for. Where that constraint excludes client or server authentication, the chain is rejected on usage grounds rather than on trust.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Dump the KeyUsage of every CA in the chainFor each CA certificate run openssl x509 -in ca.der -inform der -noout -text and read the X509v3 Key Usage and X509v3 Basic Constraints blocks. You are looking for both Certificate Sign and CRL Sign, and for CA:TRUE. Note which CA is missing which bit.
- Confirm this is the failing linkThe chain is validated bottom-up, so the first CA lacking a required bit is the one named. If the error message does not name a subject, work upward from the leaf's issuer and check each in turn. A leaf certificate sitting in the issuer store shows up immediately at this stage.
- Have the CA reissued with keyCertSign and cRLSignThis is a PKI change, not a client setting. Ask the CA owner for a sub-CA certificate whose KeyUsage includes both bits, with basicConstraints CA:TRUE. In an AD CS template the equivalent is enabling both the certificate signing and CRL signing usages.
- As a stopgap, run a dedicated OPC UA sub-CAIf reissuing the enterprise CA is a multi-week change, stand up a purpose-built sub-CA for OPC UA application certificates with correct bits, or fall back to self-signed application certificates with explicit trust-list management. Both restore service without weakening validation.
- Redistribute and reloadInstall the corrected CA certificate in the issuer store (or trusted, for a root), refresh the CRLs, restart the applications and reconnect. Leaves signed by the old CA certificate remain valid only while that certificate stays available, so plan reissuance of the leaves too.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | This error is suppressible through the CertificateValidation event, which is how many integrators quietly live with a non-conforming corporate CA. Suppressing it means the chain's signing authority is no longer verified against its declared usage, so record the decision rather than hiding it in a lambda. |
| open62541 (C) | Strict validation in the mbedTLS and OpenSSL plugins enforces CA key usage. Because the outcome sometimes surfaces as a generic certificate-invalid failure rather than this specific code, inspect the CA extensions directly rather than trusting the returned code alone. |
| UaExpert | UaExpert reports the issuer usage problem in its validation dialog and will let you accept for the session, which is a fast way to prove the corporate CA is the blocker before escalating to the PKI team. |
| node-opcua | Chain validation follows the OPC UA rules rather than generic TLS rules, so a CA that works for HTTPS can still fail here. Check the CA extensions before suspecting the store layout. |
| Eclipse Milo (Java) | Milo validates CA key usage as part of chain building. A CA imported from an enterprise keystore that works for JSSE TLS can still be refused, because TLS path validation does not insist on cRLSign the way OPC UA does. |
| Ignition | Certificates issued by a plant Windows CA are the usual trigger here. The gateway logs the validation failure; the resolution is with whoever owns the CA template, not in the gateway configuration. |
What it looks like in the log
Certificate validation failed. Error: BadCertificateIssuerUseNotAllowed. Issuer CN=Corp Issuing CA 02 KeyUsage does not include cRLSign
Chain validation rejected issuer CN=Corp Issuing CA 02: required KeyUsage keyCertSign, cRLSignConfirm the fix
Reissue, reinstall and reconnect, then confirm with openssl x509 -noout -text that every CA in the chain shows both Certificate Sign and CRL Sign under X509v3 Key Usage and CA:TRUE under Basic Constraints.
Stop it happening again
Add a keyCertSign plus cRLSign check to your certificate acceptance criteria before any CA is approved for OPC UA use, and validate a sample leaf against a strict stack as part of PKI onboarding.
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.