You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@ws.apache.org by Giriraj Bhojak <gi...@gmail.com> on 2014/05/02 23:52:00 UTC
WSSecurityEngine: Invalid timestamp The security semantics of the
message have expired
Hi Everyone,
I am getting following message while receiving a response from the web
service call.
I am not sure what's going on.
ID: 1
Response-Code: 500
Encoding: UTF-8
Content-Type: text/xml;charset=UTF-8
Headers: {connection=[close], content-type=[text/xml;charset=UTF-8],
Date=[Fri, 02 May 2014 21:43:39 GMT], Server=[Apache-Coyote/1.1],
transfer-encoding=[chunked]}
Payload: <soap:Envelope xmlns:soap="
http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode
xmlns:ns1="
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ns1:MessageExpired</faultcode><faultstring>The
message has expired (WSSecurityEngine: Invalid timestamp The security
semantics of the message have
expired)</faultstring></soap:Fault></soap:Body></soap:Envelope>
When I test with the web-service client and web service provider deployed
on my machine, everything works fine.
In the above scenario, the web-service client is on one machine and the web
service provider on another machine.
I am trying to find if the provider server is in a different timezone than
the client.
But does anyone know what's the issue here?
Thanks,
Giriraj.
Re: WSSecurityEngine: Invalid timestamp The security semantics of the
message have expired
Posted by Colm O hEigeartaigh <co...@apache.org>.
> Are 'timestampStrict' and 'timeToLive' the relevant properties for
handling such scenarios?
Yes. "timestampStrict" controls whether to throw an exception or not if the
Expires time of the Timestamp is past the current receiving time.
"timeToLive" is the value in seconds that is added on to the Created time
of the Timestamp, which if greater than the current receiving time means it
is also expired. There is also another property "futureTimeToLive", which
is the time in seconds in the future within which the Created time of an
incoming Timestamp is valid. The default is "60".
Colm.
On Tue, May 6, 2014 at 4:51 PM, Giriraj Bhojak <gi...@gmail.com> wrote:
> I found out the clocks are off by more than 5 mins.
> Syncing them fixed the issue. But the clocks might get out of sync again.
> Are 'timestampStrict' and 'timeToLive' the relevant properties for
> handling such scenarios?
>
> Thanks,
> Giriraj.
>
>
> On Tue, May 6, 2014 at 5:03 AM, Colm O hEigeartaigh <co...@apache.org>wrote:
>
>>
>> The most likely reason is that the local time on the service machine is
>> out by more than 5 minutes. Timezones shouldn't come into it, as the client
>> should be sending the time in UTC format. You can disable this check via a
>> configuration property if necessary.
>>
>> Colm.
>>
>>
>> On Fri, May 2, 2014 at 10:52 PM, Giriraj Bhojak <gi...@gmail.com>wrote:
>>
>>> Hi Everyone,
>>>
>>> I am getting following message while receiving a response from the web
>>> service call.
>>> I am not sure what's going on.
>>>
>>> ID: 1
>>> Response-Code: 500
>>> Encoding: UTF-8
>>> Content-Type: text/xml;charset=UTF-8
>>> Headers: {connection=[close], content-type=[text/xml;charset=UTF-8],
>>> Date=[Fri, 02 May 2014 21:43:39 GMT], Server=[Apache-Coyote/1.1],
>>> transfer-encoding=[chunked]}
>>> Payload: <soap:Envelope xmlns:soap="
>>> http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode
>>> xmlns:ns1="
>>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ns1:MessageExpired</faultcode><faultstring>The
>>> message has expired (WSSecurityEngine: Invalid timestamp The security
>>> semantics of the message have
>>> expired)</faultstring></soap:Fault></soap:Body></soap:Envelope>
>>>
>>>
>>> When I test with the web-service client and web service provider
>>> deployed on my machine, everything works fine.
>>> In the above scenario, the web-service client is on one machine and the
>>> web service provider on another machine.
>>> I am trying to find if the provider server is in a different timezone
>>> than the client.
>>>
>>> But does anyone know what's the issue here?
>>>
>>> Thanks,
>>> Giriraj.
>>>
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: WSSecurityEngine: Invalid timestamp The security semantics of the
message have expired
Posted by Giriraj Bhojak <gi...@gmail.com>.
I found out the clocks are off by more than 5 mins.
Syncing them fixed the issue. But the clocks might get out of sync again.
Are 'timestampStrict' and 'timeToLive' the relevant properties for handling
such scenarios?
Thanks,
Giriraj.
On Tue, May 6, 2014 at 5:03 AM, Colm O hEigeartaigh <co...@apache.org>wrote:
>
> The most likely reason is that the local time on the service machine is
> out by more than 5 minutes. Timezones shouldn't come into it, as the client
> should be sending the time in UTC format. You can disable this check via a
> configuration property if necessary.
>
> Colm.
>
>
> On Fri, May 2, 2014 at 10:52 PM, Giriraj Bhojak <gi...@gmail.com>wrote:
>
>> Hi Everyone,
>>
>> I am getting following message while receiving a response from the web
>> service call.
>> I am not sure what's going on.
>>
>> ID: 1
>> Response-Code: 500
>> Encoding: UTF-8
>> Content-Type: text/xml;charset=UTF-8
>> Headers: {connection=[close], content-type=[text/xml;charset=UTF-8],
>> Date=[Fri, 02 May 2014 21:43:39 GMT], Server=[Apache-Coyote/1.1],
>> transfer-encoding=[chunked]}
>> Payload: <soap:Envelope xmlns:soap="
>> http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode
>> xmlns:ns1="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ns1:MessageExpired</faultcode><faultstring>The
>> message has expired (WSSecurityEngine: Invalid timestamp The security
>> semantics of the message have
>> expired)</faultstring></soap:Fault></soap:Body></soap:Envelope>
>>
>>
>> When I test with the web-service client and web service provider deployed
>> on my machine, everything works fine.
>> In the above scenario, the web-service client is on one machine and the
>> web service provider on another machine.
>> I am trying to find if the provider server is in a different timezone
>> than the client.
>>
>> But does anyone know what's the issue here?
>>
>> Thanks,
>> Giriraj.
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
Re: WSSecurityEngine: Invalid timestamp The security semantics of the
message have expired
Posted by Colm O hEigeartaigh <co...@apache.org>.
The most likely reason is that the local time on the service machine is out
by more than 5 minutes. Timezones shouldn't come into it, as the client
should be sending the time in UTC format. You can disable this check via a
configuration property if necessary.
Colm.
On Fri, May 2, 2014 at 10:52 PM, Giriraj Bhojak <gi...@gmail.com> wrote:
> Hi Everyone,
>
> I am getting following message while receiving a response from the web
> service call.
> I am not sure what's going on.
>
> ID: 1
> Response-Code: 500
> Encoding: UTF-8
> Content-Type: text/xml;charset=UTF-8
> Headers: {connection=[close], content-type=[text/xml;charset=UTF-8],
> Date=[Fri, 02 May 2014 21:43:39 GMT], Server=[Apache-Coyote/1.1],
> transfer-encoding=[chunked]}
> Payload: <soap:Envelope xmlns:soap="
> http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode
> xmlns:ns1="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">ns1:MessageExpired</faultcode><faultstring>The
> message has expired (WSSecurityEngine: Invalid timestamp The security
> semantics of the message have
> expired)</faultstring></soap:Fault></soap:Body></soap:Envelope>
>
>
> When I test with the web-service client and web service provider deployed
> on my machine, everything works fine.
> In the above scenario, the web-service client is on one machine and the
> web service provider on another machine.
> I am trying to find if the provider server is in a different timezone than
> the client.
>
> But does anyone know what's the issue here?
>
> Thanks,
> Giriraj.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com