Status code · Security
BadApplicationSignatureInvalid
BadToken signature
BadApplicationSignatureInvalid means the client's ActivateSession signature over the server certificate and server nonce did not verify. The client either signed with a key that does not match the certificate it presented, signed over a stale nonce, or presented a different certificate than the one used to open the channel.
Defined behaviour: The signature generated with the client certificate is missing or invalid - the client's proof of possession of its certificate private key did not verify. (our description of the condition this code reports)
What you actually see
The secure channel opens and CreateSession succeeds, then ActivateSession fails immediately, so the client appears to almost connect before dropping.
Why it happens
- Private key does not match the presented certificateThe client proves possession of the certificate's private key by signing the server certificate concatenated with the server nonce. A own store holding a certificate from one generation and a key from another fails this check while everything earlier in the handshake succeeded.
- The certificate changed between channel and sessionThe certificate used in CreateSession must be the one used to open the secure channel. Clients that regenerate a certificate on startup, or that pick from a store with more than one candidate, can send different certificates at the two stages.
- Signature computed over a stale server nonceThe signature must cover the server nonce from the current CreateSession response. A reconnect helper that caches the signature, or code that reuses a nonce from a previous attempt, produces a well-formed signature over the wrong bytes.
- Signature algorithm mismatched to the security policyThe algorithm used for the client signature follows the negotiated policy. Hand-written handshake code, or a client that assumes SHA-1 era behaviour against a modern policy, produces a signature the server cannot verify.
- The private key is inaccessible or the wrong one was loadedOn Windows the private key may live in the machine or user certificate store; on Linux it is a file. A process without permission to read the key, or one loading a key from an unexpected path, ends up signing with nothing usable.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Verify the certificate and key pairopenssl x509 -in cert.pem -noout -modulus | openssl md5 and openssl rsa -in key.pem -noout -modulus | openssl md5 must match. On Windows, check the certificate in the application's store has an associated private key at all, which certmgr.msc shows plainly.
- Make sure only one candidate certificate is in the own storeRemove superseded certificates from the application's own store so the stack cannot select a different one at different stages. Two certificates with the same subject is the classic setup for this failure.
- Restart the client cleanly rather than reconnectingA full restart discards cached nonces, signatures and channel state. If a cold start succeeds where a reconnect fails, the defect is in the reconnect path reusing security material.
- Check the key is readable by the running processA service running under a different account than the one that generated the certificate frequently cannot read the private key. Check file permissions on Linux, or the private key permissions on the Windows store entry, before regenerating anything.
- Regenerate the pair and re-trust itIf the pair is genuinely mismatched, generate a fresh certificate and key with the correct ApplicationUri and SAN, install both, and promote the new certificate from the server's rejected store because the thumbprint changed.
- Reproduce against a reference serverPoint the same client at opc.tcp://milo.digitalpetri.com:62541/milo or opc.tcp://opcuademo.sterfive.com:26543 with the same certificate. Failing there too confirms the problem is entirely client side.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | The application certificate is loaded from the configured store; on Windows the default application store is CurrentUser\UA_MachineDefault, viewable in certmgr.msc. A certificate present without its private key produces exactly this failure at ActivateSession. |
| asyncua (Python) | load_client_certificate and load_private_key are separate calls, so pointing them at files from different generations is easy and produces a signature that never verifies. Check both paths, not just the certificate. |
| node-opcua | The certificate manager pairs the certificate with the key in its PKI tree. Supplying certificateFile explicitly while the key stays in the managed location is a common way to break the pairing. |
| open62541 (C) | Certificate and private key are passed as separate DER and key buffers when configuring encryption. A build that loads a stale key from a baked-in path signs with the wrong key while presenting the right certificate. |
| OPC Publisher | In a container, if the pki volume is not persistent the certificate is regenerated on restart while an old key may persist elsewhere in the image. Mount the whole pki tree persistently so the pair stays together. |
| UaExpert | Regenerating its own application certificate from settings produces a matched pair, which is a quick way to rule the client out. Remember to re-trust the new certificate on the server side afterwards. |
What it looks like in the log
ActivateSession failed: BadApplicationSignatureInvalid
Client signature over server certificate and nonce did not verify
The signature generated with the client certificate is missing or invalidConfirm the fix
Complete a full connect, activate and Read on the strictest endpoint, then force a reconnect and confirm the second activation also succeeds, since reconnect paths are where this failure hides.
Stop it happening again
Treat the certificate and private key as one artefact in provisioning and in backups, keep exactly one application certificate in the own store, and make sure the service account can read the key it is supposed to sign with.
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.