Hello,
I encountered a problem when connecting to my (.net SDK based) UA server running on a different machine, both with my client and UAExpert.
The errorcode returned was Bad_InvalidTimestamp.
I mentionend that the client and server system time were different (Server time was about 50 minutes later than client time)
After changing the system times to an equal value the connection was successfull.
After changing back to the old value a new connection attempt failed again.
Can anybody give me an idea how to set up the maximum allowed system time difference between client and server.
Thanks and Regards
Fips
Bad_InvalidTimestamp when connecting
Moderator: uasdknet
-
Support Team
- Hero Member
- Posts: 3068
- Joined: 18 Mar 2011, 15:09
Re: Bad_InvalidTimestamp when connecting
Hello Fips,
The client and the server should be time synced when it comes down to UTC. Of course there can be differences in local time or day light saving, as this does not affect the UTC.
My guess is that you change the UTC time, not the local time. The UTC time between client and server can be different for hours or days, BUT of course the UTC-time should not be before or after the validity of the partners certificate. It is quite obvious that checking a certificate "before" it gets valid, will fail and you can not connect. However, when changing the time backwards during runtime, the server might not send data during the time span, because from a timestamp perspective such data was already sent. When changing the time forwards the lifetime of some objects may be expired depending on their timeouts. Anyway, on time changes (e.g. time syncing with NTP) the time will "jump" a small fraction only, so you will not even notice that.
In your case where the connect attempt fails (so obviously no time shift during runtime) you very likely have expired certificate.
Best Regards
Support Team
The client and the server should be time synced when it comes down to UTC. Of course there can be differences in local time or day light saving, as this does not affect the UTC.
My guess is that you change the UTC time, not the local time. The UTC time between client and server can be different for hours or days, BUT of course the UTC-time should not be before or after the validity of the partners certificate. It is quite obvious that checking a certificate "before" it gets valid, will fail and you can not connect. However, when changing the time backwards during runtime, the server might not send data during the time span, because from a timestamp perspective such data was already sent. When changing the time forwards the lifetime of some objects may be expired depending on their timeouts. Anyway, on time changes (e.g. time syncing with NTP) the time will "jump" a small fraction only, so you will not even notice that.
In your case where the connect attempt fails (so obviously no time shift during runtime) you very likely have expired certificate.
Best Regards
Support Team