jonasar
commented
2 years ago I am running version 0.8.1 of the opcua library When this was tested I was using security policy Basic256Sha256 and message security mode SignAndEncrypt.
The calculation of the elapsed secure channel lifetime that I am talking about is in function should_renew_security_token() in secure_channel.rs (core/src/comms/secure_channel.rs).
The condition now.signed_duration_since(created_at) > renew_lifetime calculates the difference between chrono::Utc::now() and created_at which is self.token_created_at, which in turn is set from the received security token in function set_security_token(), also in secure_channel.rs
When evaluating whether it is time to renew the secure channel token, the time that the current token has been used is calculated as a difference between the current time on the local computer and the time of creation reported by the server.
This means that if the clocks in the client and server are not in sync, the calculated elapsed lifetime is incorrect.
Note that I am not talking about time zones/local time, all times are handled correctly in UTC, the problem is just calculating the elapsed lifetime as a difference between current time on the local computer and the time of creation from the server.
This can be tested by connecting to an OPC UA server where the clock is a few hours before the clock on the machine where the opcua client is runnint.
Using the UaExpert client, I get a warning if the server time is off by more than 30 minutes compared with the local computer, but it still handles the channel lifetime correctly.