Data modified during transit causing signature verification to fail


When a client sends us a signed financial transaction as an xmlnode over https it fails to verify the signature. We narrowed down the issue to the fact that newline characters and spaces are added to the xml during the https call.

We can successfully verify the signature when we manually get the data in a file from the client (notice there are only two lines and no spaces…)

But the data that is received when the service is called is this (notice every tag is in a new line, well intended with spaces etc). This data received fails to verify the signature…

The client is calling the service thru a java code

Anybody came across an issue like the message over the internet adding newline characters

I tried to remove the CRLF and space characters manually and found that the message can be successfully verified.

I wonder how to help my client solve it in his java code. Any pointers are most welcome.

Thanks and Regards


You mean the receiving side uses java code for parsing the XMLData node?

What are the starting service logic being called and is the https send set content-type text/xml?

Also receiving XML having with CRLF is a pretty standard and shouldn’t be an issue.

Any signature verification need to be done with the original binary bytes/stream. Once parsed, it’s not the same.
Try to get the bytes or stream of the xml before verification.


What mode are you receiving node or bytes or stream payload? you mentioned node correct?


The sender sends it from a java program.

I am the receiver. I receive the data as xml node. The content type is verified to be text/xml

These are the steps that I perform when I receive the xml node

a) pub.xml: xmlNodeToDocument
b) pub.xml:documentToXMLString
c) pub.xml:queryXMLNode - extract the signature and signed msg from the xml
d) pub.string:base64Decode - signatue
e) pub.string:stringToBytes - convert the body into bytes
f) - the signature

The update: Now the client deliberately gave ‘\r\n’ after each tag and I can verify it correctly when I get it from the file they send me, but my service still fails and I could see there are space characters in the xml. Now if I manually remove space characters the verification will pass, what could be done on the client side since I have other working clients (dotNet) here.

Original Msg Tried from the input file that they provided (with new line chars inserted by client)

The same message received over https (spaces can be seen marked, notice spaces after \r\n)

Part of various trials I asked them to send the data zipped and streamed and found that it was untampered and verifiable when unzipped from my side.


These are the steps that I always used to verify the signature. How could I get the signature and the signed body from the xml without parsing.?


Can you use the sting:replace service to remove those CR LF and it should work? But I am still not sure how it deals with spaces though.




I cannot use string:replace to remove them since if there was one inserted by the client then the signature verification would fail. There is no point in signature verification if I could modify the message right.

I asked them to send it as stream and found that I can receive the message intact. I guess I would have to stick with stream with this customer.

Thanks Dude


Sure…glad you convinced out the stream way: :smiley: