Status code · Certificates
BadCertificateUseNotAllowed
BadKey usage
BadCertificateUseNotAllowed means the peer certificate's key usage or extended key usage does not permit how it is being used. An application instance certificate needs digitalSignature and, for RSA policies, key and data encipherment, plus client or server authentication in extendedKeyUsage.
Defined behaviour: The certificate may not be used for the requested operation. (our description of the condition this code reports)
What you actually see
A certificate that is trusted, in date and correctly named is still rejected, and the message points at key usage rather than at trust, chain or hostname.
Why it happens
- Missing key usage bits for the active security policyAn application instance certificate used with an RSA policy needs digitalSignature for message signing and keyEncipherment plus dataEncipherment for the asymmetric key exchange in OpenSecureChannel. A certificate created from a signing-only template cannot complete the handshake for SignAndEncrypt.
- extendedKeyUsage does not include the required roleClients need clientAuth and servers need serverAuth in extendedKeyUsage. A certificate issued for one role and reused for the other is rejected. Applications that act as both client and server - gateways and aggregating servers - need both, or no EKU restriction at all.
- A user certificate is being presented as an application certificateX.509 user identity tokens and application instance certificates are different artefacts validated against different stores (trustedUser and issuerUser versus trusted and issuer). Handing a user certificate to the channel layer produces a usage error rather than an authentication error.
- A CA certificate is being used as an application certificateConfiguring an application to present a CA certificate as its own instance certificate - occasionally done when someone confuses the files - fails on usage grounds because a CA certificate asserts keyCertSign, not the leaf usages the handshake needs.
- ECC versus RSA usage requirements differWith ECC policies the relevant bit is digitalSignature for ECDSA rather than the encipherment bits an RSA policy needs. A certificate correct for one family of policies can be wrong for the other, which shows up when a server's policy list changes.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Read the usage extensions from the failing certificateRun openssl x509 -in cert.der -inform der -noout -text and read X509v3 Key Usage and X509v3 Extended Key Usage. Write down exactly which bits are present, and identify whether the certificate is the client's, the server's or a CA's.
- Establish which policy is in useCall GetEndpoints with security None and look at the SecurityPolicyUri and SecurityMode of the endpoint you are targeting. An RSA policy under SignAndEncrypt needs the encipherment bits; Sign-only and ECC policies have different requirements.
- Check you are not presenting the wrong fileConfirm the application's own certificate path points at the leaf application instance certificate and its private key, not at a CA certificate or a user certificate. This mix-up is more common than a genuinely mis-templated certificate.
- Reissue with correct usagesGenerate with -addext "keyUsage=digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment" and -addext "extendedKeyUsage=clientAuth,serverAuth" for an application that does both roles, keeping the SAN with its URI and DNS entries intact.
- Reinstall, re-trust and reconnectInstall the new certificate as the application's own, update peer trust stores because the thumbprint changed, restart and retry. Confirm the connection now reaches ActivateSession rather than failing earlier in the handshake.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | Certificate properties including key usage are checked in validation step 5 and this code is suppressible. The stack's own certificate generator produces correct usages, so this error usually points at a certificate supplied from outside the stack. |
| OPC Publisher | The documented generation recipe sets keyUsage to nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment, keyCertSign and extendedKeyUsage to clientAuth - a good reference for what a client certificate is expected to assert. |
| open62541 (C) | The security policy plugins require the encipherment usages for RSA-based policies. A certificate generated with a signing-only template fails at channel open rather than at trust validation, which makes the log look like a crypto problem. |
| UaExpert | If UaExpert's own certificate is refused, regenerate it from Settings, Manage Certificates rather than editing extensions by hand; the generated certificate carries the usages a client needs. |
| asyncua (Python) | asyncua's certificate helper writes appropriate usages when it generates a self-signed certificate. Certificates converted from a PFX exported for a web server frequently arrive with serverAuth only and fail when asyncua is acting as a client. |
| Beckhoff TwinCAT | The TwinCAT OPC UA server generates its own instance certificate with the usages it needs. Replacing it with a certificate from a corporate CA is where usage mismatches appear, so compare the replacement's extensions against the generated one before swapping. |
What it looks like in the log
Certificate validation failed. Error: BadCertificateUseNotAllowed. KeyUsage of CN=MyClient does not permit dataEncipherment
Certificate rejected: extendedKeyUsage does not contain clientAuth for CN=MyClientConfirm the fix
Reconnect on the intended endpoint with its real security policy and mode, and confirm openssl x509 -noout -text shows digitalSignature plus the encipherment bits and the clientAuth or serverAuth EKU the role requires.
Stop it happening again
Publish one certificate template for OPC UA application instance certificates with the required key usage, extended key usage and SAN structure, and reject certificate requests that do not use it.
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.