SDK 2.0.1: API-key logins fail (BadIdentityTokenInvalid) when the client clock is >5 min ahead of the server #873
Assignees
dohertj2 (dohertj2)
Clear assignees
dohertj2 (dohertj2)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: dohertj2/lmxopcua#873
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found by the #800 partial Windows validation on windev (master
88698ca0, SDK 2.0.1, self-contained win-x64, 2026-11-11).Symptom: every API-key login from the Mac to the server on windev failed with
BadIdentityTokenInvalid. The same key from a client on windev itself was accepted, and so was a Mac→Mac connection.Cause: with SDK 2.0.1, a client whose password is over 64 bytes encrypts it as
RsaEncryptedSecret, which carries a signing time. OtOpcUa API keys are 65 characters, so every SDK 2 client now does this. The 2.0.1 server (EncryptedSecret.cs) rejects the token if the client's signing time is more than 5 minutes ahead of the server's clock or more than 1 hour behind it. windev's time service is stopped and its clock was 549 s slow. SDK 1.5 clients use the old format and are unaffected.Impact: on any SDK 2 server, API-key logins depend on client and server clocks agreeing within 5 minutes in that direction. This covers our CLI, the OpcUaClient driver, and ScadaBridge once it moves to SDK 2 (ScadaBridge#125). Before upgrading VD03 or QA, check the Windows time service and clock offset on both server and client hosts. Document this in the SDK 2 rollout runbook and docs/security.md, and consider a startup health warning.
Documented on master: a clock-sync prerequisite in
docs/plans/2026-11-10-opcua-sdk-2-rollout.md(Operating constraints) and a note indocs/security.md. The refusal is now visible in the server log (#874). This stays open as an operational item: checkw32tm /query /statuson VD03 and every SDK 2 client host before the OtOpcUa SDK 2 deploy. A startup check is not possible server-side, because the server never sees a client's clock until it logs in.Closing: docs landed on master (rollout runbook Operating constraints + docs/security.md), the refusal is logged (#874), and the vd03 clock was checked during the #793 upgrade (agrees with the Mac within seconds, w32tm source recorded in docs/deploy/vd03-upgrade-b8b4c18f-to-master.md). The remaining per-host clock check for QA vq03/vq04 and every SDK 2 client host is a deploy precondition and belongs to the SDK2 rollout gates #800/#801.