BadUserSignatureInvalid
BadToken signature
BadUserSignatureInvalid means the signature that accompanies your user identity token did not verify at ActivateSession. It applies to X.509 user certificate tokens and to issued tokens that carry a signature. Check that the user certificate matches the private key signing for it, and that the user certificate is trusted in the trustedUser store.
What you actually see
Anonymous or username login to the same server works, and only the certificate-based user identity fails, always at ActivateSession.
Why it happens
- User certificate and private key do not matchThe client signs the server certificate and server nonce with the user private key, and the server verifies with the public key in the user certificate it was sent. A mismatched pair, common after a partial credential rollout, fails every time regardless of trust.
- The user certificate is not in the trustedUser storeUser certificates are validated against trustedUser and issuerUser, which are separate stores from the application trusted and issuer stores. Putting a user certificate in the application trust list looks right and does nothing.
- Wrong signature algorithm for the negotiated policyThe token signature algorithm must correspond to the security policy in force. A client that signs with a SHA-1 algorithm against a server on a SHA-256 policy produces a signature the server will not accept.
- Stale server nonce used to compute the signatureThe signature covers the server certificate and the server nonce from the current CreateSession response. Reusing the nonce from an earlier session, or recomputing the signature after a reconnect, invalidates it.
- Application certificate used as the user tokenPresenting the application instance certificate as an X.509 user token is a frequent shortcut. The server validates it against the user stores where it is unknown, and the signature check fails or the token is refused outright.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Confirm the user certificate and key are a pairopenssl x509 -in user.pem -noout -modulus | openssl md5 against openssl rsa -in userkey.pem -noout -modulus | openssl md5. Different hashes mean the client cannot produce a verifiable signature no matter what the server is configured with.
- Put the user certificate in the right storeInstall it in the server's trustedUser store, or install the issuing CA in issuerUser and the anchor in trustedUser. These are distinct from the application stores and a certificate in the wrong one is simply not found.
- Test with a simpler identity firstActivate a session as Anonymous, then with username and password, then with the certificate token. The first one that fails localises the problem to identity handling rather than to the channel or the application certificates.
- Match the signature algorithm to the policyLet the SDK derive the token signature algorithm from the negotiated SecurityPolicyUri rather than hard-coding it. Hand-rolled identity token code is the usual source of an algorithm mismatch.
- Recreate the session cleanlyClose the session completely and create a new one so the signature is computed over the current server nonce. Do not reuse a cached signature across a reconnect; recompute it from the new CreateSession response.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| UA-.NETStandard (C#) | X509IdentityToken handling computes the signature over the server certificate and nonce for you; supply the certificate with its private key attached. The server validates the user certificate against the user trust stores configured in SecurityConfiguration. |
| asyncua (Python) | The certificate-based user identity is set separately from the application certificate. Passing the same file for both is a common mistake and produces a user token the server does not recognise even though the channel is fine. |
| node-opcua | The user identity token for certificate login takes the certificate and the private key explicitly. Its role-based security tutorial is a workable reference for getting the server side of user certificate validation configured. |
| UaExpert | The user identity configuration on a server connection offers Anonymous, Username and Certificate. When the certificate option fails while username succeeds, the problem is in the user token, not in the connection. |
| Eclipse Milo (Java) | The server's identity validator for X.509 tokens is separate from the application certificate validator, and the two have separate trust configuration. Wiring the application validator to user tokens is a common integration error. |
| Ignition | Certificate-based user identity on an OPC UA connection needs the user certificate approved in the gateway separately from the peer application certificate. Approving one does not approve the other. |
What it looks like in the log
ActivateSession failed: BadUserSignatureInvalid
User token signature verification failed for X509IdentityToken 'CN=operator1'
The user token signature is missing or invalidConfirm the fix
Activate a session with the certificate identity and confirm the server logs the expected user, then read a node that only that user's role can access to prove the identity was really applied.
Stop it happening again
Provision user certificates and their keys as one bundle, keep them in the user trust stores rather than the application ones, and test certificate login during commissioning rather than after anonymous access is removed.
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.