Just to follow up on this in case anyone else has this problem. Both systems are on the same State Network using the same NTP Server however it look like their servers are running behind, In the tests I received back I was being rejected by 106, 54 and 111 milliseconds. The vendor will not adjust the time skew on the Data Power server to account for this.
-----Original Message----- From: Mark Presling <[email protected]> Sent: Monday, April 26, 2021 1:29 PM To: [email protected] Cc: [email protected] Subject: Re: Adjust cxf client timestamp start time to fix incorrect timestamp soapfault from DataPower Think twice before clicking on links or opening attachments. This email came from outside our organization and might not be safe. If you are not expecting an attachment, contact the sender before opening it. If it is under 1 second then they should adjust their service to be a little more lenient, as described by ws-security.timestamp.futureTimeToLive But a "big government network" should already have NTP in place as well. On Tue, 27 Apr 2021, 2:44 AM Wilken Marci J, <[email protected]> wrote: > Adjusting the clock would probably be harder. I'm on a big government > network and that is out of my control. I ran time.is from my > computer, varies from + .005 seconds to +.128 second. > > -----Original Message----- > From: Colm O hEigeartaigh <[email protected]> > Sent: Monday, April 26, 2021 1:38 AM > To: [email protected] > Subject: Re: Adjust cxf client timestamp start time to fix incorrect > timestamp soapfault from DataPower > > Think twice before clicking on links or opening attachments. This > email came from outside our organization and might not be safe. If > you are not expecting an attachment, contact the sender before opening it. > > Hi, > > It's not easily possible to change the "created" timestamp on the > outbound side. I suggest instead you sync your system clock so that it is > correct. > > Colm. > > On Wed, Apr 21, 2021 at 8:26 PM Wilken Marci J > <[email protected]> wrote: > > > > > > Is it possible to adjust the start time of a timestamp by a few > > second > on a CXF client? > > > > I am using the apache camel cxf component from Redhat > 2.21.0.fuse-730078-redhat-00001. > > I am making a call to the partner Data Power server that requires a > timestamp for. It is working about 75% of the time. When it doesn't work > I get this error back > > Response-Code: 500 > > Encoding: ISO-8859-1 > > Content-Type: text/xml > > Headers: {Connection=[close], Content-Type=[text/xml], > > X-Backside-Transport=[FAIL FAIL]} > > Payload: <?xml version="1.0" encoding="UTF-8"?> <env:Envelope > > xmlns:env="http://schemas.xmlsoap.org/soap/envelope/ > "><env:Body><env:Fault><faultcode>env:Client</faultcode><faultstring> > > Incorrect Timestamp > > (from > > client)</faultstring></env:Fault></env:Body></env:Envelope> > > > > According to the partner this is because my time stamp is future > > dated, > because our system time is slightly ahead of their time. Their > suggestion is to adjust my timestamp by a second but I haven't been > able to locate any thing I could set on the client side . > > > > I did find this but it would be server side not client side. > > ws-security.timestamp.futureTimeToLive The time in seconds in the > > future > within which the Created time of an incoming Timestamp is valid. The > default value is "60". See here for more information. > > This is my configuration > > > > <cxf:cxfEndpoint > > address="{{mci.ws.protocol}}://{{mci.ws.domain}}:{{mci.ws > .port}}/{{mci.ws.service}}" > > id="serviceEndPoint" serviceClass="mci.hbe.ky.IMciService" > > wsdlURL="wsdl/MciService_stl2_2020.05.20.wsdl" xmlns:s=" > https://urldefense.com/v3/__http://Ky.Hbe.Mci__;!!OxGzbBZ6!Iq1cbu6MFkv > L9tW98dbAxucfklxiHt1_lL_2krPPkQjPn9CTUtRmMMiAXboFK42QFSnCHUIepaBh$ "> > > <cxf:inInterceptors> > > <ref bean="loggingInInterceptor"/> > > </cxf:inInterceptors> > > <cxf:outInterceptors> > > <ref bean="loggingOutInterceptor"/> > > </cxf:outInterceptors> > > <cxf:inFaultInterceptors> > > <ref bean="loggingInInterceptor"/> > > </cxf:inFaultInterceptors> > > <cxf:outFaultInterceptors> > > <ref bean="loggingOutInterceptor"/> > > </cxf:outFaultInterceptors> > > <cxf:properties> > > <entry key="ws-security.timestamp.timeToLive" value="600"/> > > <entry key="ws-security.timestamp.futureTimeToLive " > value="60"/> > > <entry key="hostnameverifier" value="hostnameVerifier"/> > > <entry key="ws-security.must-understand" value="false"/> > > <entry key="ws-security.enable.timestamp" value="true"/> > > <entry key="ws-security.enable.timestamp.cache" > value="false"/> > > <entry key="loggingFeatureEnabled" value="true"/> > > </cxf:properties> > > </cxf:cxfEndpoint> > > <http-conf:conduit name="{ > https://urldefense.com/v3/__http://Ky.Hbe.Mci*7DMciBasicHttpEndpoint.h > ttp-conduit__;JQ!!OxGzbBZ6!MV8AhOcZXx7eqNckweQHL4c93CbTVGnw_nlLT0IiM7l > XPuXym2wLxVO1zgxa9kSzvjv77k7nTz-n$ > "> > > <http-conf:client AllowChunking="false" Connection="Keep-Alive" > > ConnectionTimeout="30000" MaxRetransmits="4" > ReceiveTimeout="15000"/> > > <http-conf:tlsClientParameters disableCNCheck="false"> > > <sec:keyManagers keyPassword="${server.keymanager.password}"> > > <sec:keyStore password="${server.keystore.password}" > > > resource="${jboss.home.dir}\opts\certs\${server.keystore}" > type="JKS"/> > > </sec:keyManagers> > > <sec:trustManagers> > > <sec:keyStore password="${server.truststore.password}" > > > resource="${jboss.home.dir}\opts\certs\${server.truststore}" > type="JKS"/> > > </sec:trustManagers> > > <sec:cipherSuites> > > > <sec:cipherSuite>TLS_RSA_WITH_AES_256_CBC_SHA</sec:cipherSuite> > > </sec:cipherSuites> > > <sec:cipherSuitesFilter> > > <sec:include>.*_EXPORT_.*</sec:include> > > <sec:include>.*_EXPORT1024_.*</sec:include> > > <sec:include>.*_WITH_DES_.*</sec:include> > > <sec:exclude>.*WITH_NULL.*</sec:exclude> > > <sec:exclude>.*DH_anon.*</sec:exclude> > > </sec:cipherSuitesFilter> > > </http-conf:tlsClientParameters> > > </http-conf:conduit> > > > > > > Thanks Marci >
