Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Consumer + intermediary + Provider = digest value mismatch  RSS feed

Akram Chotu
Ranch Hand
Posts: 43
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have been working with Axis 1.x, WSS4J for sometime. There is a
propietary intermediary that we are using that just acts like a kind
of proxy between the consumer and provider. This intermediary will not
modify the soap message when it passes the soap message from the
consumer to the provider.

I usually sign the body and try to verify the signature and occassionaly
I face an exceptions like "digest value mismatch" while trying to
validate the signature. What I feel is after the soap messages with
signature reach from the consumr to the provider, on the provider end
somehow the body gets modified with some not so eye visible newline
characters, spaces etc. that breaks the signature verification. When
WSS4J calculates the digest on the body and compares this digest value
with the digest value that is already present in the digest value
element of the SignedInfo element then if they both do not match then
I get "digest value mismatch" error from WSS4J. All this stuff may
happen even with the signature value.

I tried these settings on both client side and provider side with Axis
1.2, Axis 1.2.1,
Axis 1.3, Axis 1.4, WSS4J 1.5 but these settings did not solve the
problem even though I dont really what these settings do.

<parameter name="enableNamespacePrefixOptimization" value="false"/>
<parameter name="disablePrettyXML" value="true"/>

Now my question is do we have any workaround may be at the axis level
or wss4j for fixing this problem because I dont have any control on
the intermediary if by any chance it is modifying the soap message
when it passses the message to the provider and I am pretty sure that
in our case it WILL not modify the soap message.

Please suggest.
Watsh Rajneesh
Ranch Hand
Posts: 110
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Canonical XML finds its application in this scenario. The signing authority will digest and sign the canonical form of the document instead of the original form. Similarly, at the time of verification, the canonical form will be verified instead of the original XML. Thus all logically equivalent versions of the signed XML document will result in successful verification (validation) of XML digital signatures.

Read more about Canonicalizing Before Signing and Verifying here.

And here's one good article on the xml signature validation.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!