Hi Tim,
Log file was very helpful. When I looked at the this part[Ref 1] in the
log file I can see that the Timestamp of the received message is in the
future.
Rampart rejects timestamps created in the future by throwing a
RampartException("cannotValidateTimestamp"). For Rampart to successfully
validate timestamp, current time must be between ts->Created and
ts->Expires.
When it comes to .NET client, it must be allowing a time skew for future
creations. Please report a bug in https://issues.apache.org/jira/ and
attach this log file and a complete stack trace of the Exception thrown.
If you can, it will be better to attach the Client java code and the
configurations/policy files.
I'll try to get it into the next release.
Thank you,
Dimuthu.
[Ref 1]
3234 DEBUG [main] processor.TimestampProcessor - Found Timestamp list
element
3234 DEBUG [main] processor.TimestampProcessor - Preparing to verify
the timestamp
3234 DEBUG [main] processor.TimestampProcessor - Current time:
2007-07-09T09:38:38.687Z
3234 DEBUG [main] processor.TimestampProcessor - Timestamp created:
2007-07-09T09:39:31.765Z
3234 DEBUG [main] processor.TimestampProcessor - Timestamp expires:
2007-07-09T09:44:31.765Z
On Mon, 2007-07-09 at 19:43 +1000, Tim Munro (myDIALS) wrote:
> Thanks for the response Dimuthu.
>
> When I turn on DEBUG logging for just "org.apache.ws.security.handler" I do
> not receive anything in my log file (actual log4j config file attached;
> perhaps I have configured it incorrectly).
>
> I am not sure whether this will be helpful, but I have turned on DEBUG
> logging (all namespaces) for a complete cycle & attached the output file.
>
> If it would be helpful I can send you my test client project that will run
> against our test server (our server app can be accessed via the internet).
>
> Best,
> Tim
>
>
