BadSecurityChecksFailed

BadNonce / signature

What you actually see

The handshake gets past the endpoint list and then dies during OpenSecureChannel, CreateSession or ActivateSession with a security error that names nothing specific.

Why it happens

• The certificate and private key do not matchThe application signs with its private key and the peer verifies with the public key in the certificate it received. If the own store holds a certificate from one generation and a key from another, every signature fails verification. This is common after a half-finished certificate replacement.
• A different certificate on the channel and on the sessionThe client certificate sent in CreateSession must be the same one used to open the secure channel. Clients that regenerate or reselect a certificate between the two steps, or that run behind a proxy that alters the handshake, fail this binding check.
• Nonce or signature mismatch during ActivateSessionThe client signs the concatenation of the server certificate and the server nonce. A stale nonce from a previous attempt, a reused nonce on a reconnect, or a signature computed over the wrong bytes all present as a failed security check rather than as a specific nonce error.
• Clock skew large enough to break message securityTimestamps in the request header and the security token lifetime are checked. A machine minutes or hours out of step can have its messages judged outside the acceptable window, which surfaces here rather than as a certificate time error.
• Mismatched security policy or a truncated handshakeA client and server that disagree about the negotiated policy, or a middlebox that inspects and rewrites the opc.tcp stream, produce messages that will not verify. Deep packet inspection on port 4840 is a real cause in hardened networks.

How to fix it

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

1. Establish where in the handshake it failsEnable stack tracing on the client and note whether the last successful step was OpenSecureChannel, CreateSession or ActivateSession. Failing at channel open points at certificates and policy; failing at activate points at nonces, signatures and identity tokens.
2. Prove the certificate and key belong togetherCompare the moduli: openssl x509 -in cert.pem -noout -modulus | openssl md5 and openssl rsa -in key.pem -noout -modulus | openssl md5 must produce the same hash. If they differ, the own store is inconsistent and nothing else you change will help.
3. Check the clocks on both machinesdate -u on each side. Clock skew is a security failure, not only a data quality one; bring both ends onto the plant NTP source and retest before investigating further.
4. Retry with a clean sessionFully close the client and reconnect rather than letting a reconnect handler reuse cached security material. A stale server nonce or channel token cached across a reconnect is a frequent, self-inflicted cause.
5. Drop to a lower security setting to isolate the layerConnect with security None to prove the endpoint, network and identity are fine, then move to Sign, then to SignAndEncrypt. The step that reintroduces the failure tells you whether signing or encryption is at fault.
6. Look for anything rewriting the streamCapture on port 4840 with the Wireshark OPC UA dissector and confirm the chunks the server receives are the chunks the client sent. Inline inspection appliances and some VPN accelerators break message security in exactly this way.

Where it shows up, by tool and stack

What it looks like in the log

ServiceFault: BadSecurityChecksFailed during ActivateSession
Error validating client signature over server certificate and nonce
An error occurred verifying security

Confirm the fix

Connect on SignAndEncrypt with the strictest policy the server offers, complete a Read, and confirm no security faults appear in either log across a full session lifetime including a token renewal.

Stop it happening again

Replace certificates and keys as a single atomic operation, keep NTP running everywhere, and keep deep packet inspection off opc.tcp traffic. Alert on repeated security check failures, which look identical to a probing attempt.

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.