Closed laumann closed 3 years ago
Hi @locka99 sorry for the noise, I wanted to open this PR against omnioiot/opcua and do a full verification that it works before opening a PR for you. I'm also not convinced that the fix I've implemented is the right way to do it, but I think it works for our purposes for now.
This fixes two issues that combined caused the client to be unable to connect to our OPC-UA server (Kepware).
Here's a snippet from the GetEndpointsResponse that details the endpoint configuration
Overall, the two problems were:
None
, when it should beBasic128Rsa15
crypto/user_identity: Fix selection of security policy
In
make_user_name_identity_token()
the security policy to use when authenticating with username and password is determined from the user_token_policy and token_security_policy.In our tests, if the server provides eg. Basic128Rsa15 as the user token policy, the logic would select None as the policy and subsequently not encrypt the password and fail to connect.
Inverting some of the logic appears to work (at least for our tests).
core/comms/secure_channel: Always set remote nonce
The set_remote_nonce_from_byte_string() performs some checks against the message security mode.
In our tests, we use security policy = None and security mode = None, but the server sets Basic126Rsa15 for the user identity token policy meaning that we still need to use the server nonce for authentication.
This patch removes all the checking around security policy and mode, which allows the client to connect to our OPC-UA server (Kepware) successfully.