More WSE Issues: Timestamp Validation and Clock Skew

My newly-deployed WSE 3.0-enabled site wasn’t working properly.  Invoking the service caused the following exception:

"WSE910: An error happened during the processing of a response message, and you can find the error in the inner exception.  You can also find the response message in the Response property."

Checking the InnerException, the real cause was this:

"WSE066: Timestamp is expired. This indicates a stale message but may also be caused by lack of synchronization between sender and receiver clocks. Make sure the clocks are synchronized or use the timeToleranceInSeconds element in the microsoft.web.services3 configuration section to adjust tolerance for lack of clock synchronization."

Step 1 was to make sure that the clock on the server was properly synchronized with an accurate NTP server.  I followed the steps in KB816042 to configure Windows Time service to use an external time source.  When that confirmed that the server time was accurate, I suspected that it had something to do with time zones, since the consumers of the service are in a different time zone.  Turning on WSE tracing let me look at the timestamp:

<wsu:Timestamp wsu:Id="Timestamp-4bd14e9e-37fa-4658-b1cb-43256498cb60">
  <wsu:Created>2007-03-20T17:34:31Z</wsu:Created>
  <wsu:Expires>2007-03-20T17:49:31Z</wsu:Expires>
</wsu:Timestamp>

confirming that it uses UTC for the timestamp.  Some more checking led me to an MSDN article on WS-I BSP Interoperability Guidance (Web Services-Interoperability Basic Security Profile, FYI) that discusses message age and clock skew.  I found these two statements:

“The <defaultTtlInSeconds> element specifies the number of seconds after creation that every outgoing SOAP message is valid. The default value is 5 minutes, but the WS-I SCM architecture document recommends that this is set to 900 seconds (15 minutes).”

“The <timeToleranceInSeconds> setting corresponds to the acceptable time difference (clock skew) between the sender and the recipient of a message. By default, it is configured to 300 seconds or 5 minutes. However, you can change this value in the service’s Web.config file if you require a different value. The WS-I SCM Architecture document recommends that this is set to 900 seconds (15 minutes).”

Setting the defaultTtlInSeconds to 900 on both server and client did the trick!  You can add these elements manually in web.config to the configuration/microsoft.web.services3/security section:

<defaultTtlInSeconds value="900" />
<timeToleranceInSeconds value="900" />

Advertisements

7 thoughts on “More WSE Issues: Timestamp Validation and Clock Skew

  1. Nice post. I tried the settings you mentioned here, however I’m still getting the same problem . Are there are other settings you are aware of?

    I also noticed that there is a setting in the wse3policyCache.config file:

    but I tried bumping that up to 900 and still no dice.

  2. I see your comment system scrubs out XML….here’s the other setting I found (with no tags):

    policies
    policy
    mutualCertificate11Security ttlInSeconds

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s