Status code · Certificates
BadCertificatePolicyCheckFailed
BadKey size / SHA-1
BadCertificatePolicyCheckFailed means the certificate is structurally fine but fails your cryptographic policy - usually an RSA key below 2048 bits or a SHA-1 signature while SHA-1 rejection is enabled. Reissue the certificate with a 2048-bit or larger key and a SHA-256 signature rather than relaxing the policy.
Defined behaviour: The certificate does not meet the cryptographic policy the application enforces, such as a minimum key size or an acceptable signature algorithm. (our description of the condition this code reports)
What you actually see
An older device or a legacy client is refused at the handshake while modern peers connect normally to the same endpoint, and the certificate itself is in date and trusted.
Why it happens
- RSA key smaller than the minimumOPC UA requires a minimum RSA key length of 2048 bits for application instance certificates. Certificates generated years ago with 1024-bit keys, or produced by an embedded device's built-in generator with a small default, fail the policy check. The certificate is otherwise valid, which is why the failure looks arbitrary.
- SHA-1 signature with SHA-1 rejection enabledModern stacks default to rejecting SHA-1 signed certificates. A certificate signed with SHA-1 by an old CA, or a self-signed certificate produced by an old tool, fails on that basis alone. The setting is a deliberate hardening default and should stay on.
- Signature algorithm or curve the policy does not permitA certificate using an algorithm or an elliptic curve outside what the active security policy allows fails here rather than at the trust check. This appears when mixing ECC certificates into a deployment configured for RSA policies, or the reverse.
- Certificate generated by an embedded device with weak defaultsPLCs, drives and small gateways sometimes generate their self-signed certificate on first boot with defaults that predate current requirements. Where the device offers no way to change the key size, the only remedy is a firmware update or importing a certificate generated elsewhere.
- Policy tightened on one side of an existing connectionA stack upgrade or a hardening change can enable stricter checks on a system that was previously permissive. Nothing about the certificate changed; the policy did. The give-away is that the failure starts at a software update rather than at a certificate expiry.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Inspect the certificate's key size and signature algorithmDump the certificate and read the public key length and the signature algorithm. That single check identifies which of the two common causes applies and takes seconds. Keep the output; you will need it to justify a device replacement if the device cannot do better.
- Reissue with a 2048-bit or larger RSA key and SHA-256Generate a new key pair and certificate meeting current requirements, including the ApplicationUri as a URI entry in SubjectAltName plus the DNS names or IP addresses of the endpoint, and the KeyUsage bits the transport needs. Install it and distribute the public certificate to every peer's trust list.
- Where the device generates its own certificate, look for a firmware or configuration optionMany devices expose a key size selection or a regenerate-certificate function. Where they do not, check with the vendor whether a newer firmware improves the defaults or whether an externally generated certificate can be imported. Do not assume either is possible.
- Import an externally generated certificate where the device allows itA certificate generated with a proper key size and signed by your CA, imported into the device, solves the problem permanently and brings the device into your PKI at the same time. This is preferable to leaving a weak self-signed certificate in service.
- Treat suppression as a temporary, documented exceptionThis condition is in the suppressible set, so a validation callback can accept it. Doing so accepts a weak key or a deprecated signature on that connection. If you must, scope it to the specific certificate, record it as a known exception with an expiry date, and do not apply it globally.
- Retire the last SHA-1 CAIf the failing certificates come from a CA that signs with SHA-1, replacing the individual certificates only postpones the problem. Reissue from a SHA-256 CA and plan the migration for everything that CA signed.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | The validator enforces a minimum key size and a RejectSHA1SignedCertificates setting, and the condition is suppressible through the validation callback. Keep the SHA-1 rejection on and fix the certificate instead. |
| open62541 (C) | Policy enforcement depends on the crypto backend the build uses, so behaviour differs between builds. Check what your build enforces before concluding a certificate is acceptable elsewhere. |
| node-opcua | Certificate generation tooling produces conformant key sizes and signatures by default, so a failure here almost always concerns a certificate that came from somewhere else - typically a device's own generator. |
| Siemens S7-1500 | Certificate handling and available key sizes depend on the CPU and firmware, and the options offered in the engineering tool have changed across releases. Confirm what your exact firmware supports with the vendor before planning a fix. |
| UaExpert | The certificate dialog displays the key length and signature algorithm, which is the quickest non-command-line way to identify why the policy check failed. |
| OPC Publisher | It generates its own application certificate on first run if none is present, so removing a weak certificate from a persistent PKI volume and restarting produces a conformant replacement. |
What it looks like in the log
Certificate policy check failed: RSA key length 1024, minimum 2048
Rejecting SHA-1 signed certificate CN=LegacyGateway per policy
Signature algorithm sha1WithRSAEncryption not permittedConfirm the fix
Confirm the replacement certificate reports a 2048-bit or larger key and a SHA-256 signature, then connect and confirm the handshake completes with the certificate landing in the trusted store rather than in rejected.
Stop it happening again
Set a minimum key size and signature algorithm standard for your PKI and enforce it at issuance, keep SHA-1 rejection enabled, audit device-generated certificates at commissioning, and record any suppression as a dated exception rather than a permanent setting.
Verify before you rely on this: Available key sizes and signature algorithms on device-generated certificates depend on the exact model and firmware; confirm what your hardware supports with the vendor.
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.