Message digest mismatch in signature
Hi Heller,
tearing my hair out on this one...
My trading partner is reporting this error upon receiving a sync MDN:
"Error verifying signature on received MDN".
They are using a bTrade product (TDAccess I think).
Since I cannot get access to that software, I have replicated this behavior by setting up /n software's AS2 connector - which when configured to ask for sync MDN, it reports:
"Failure: The receipt signature could not be verified: Message digest mismatch in signature."
Now, when testing for this behavior between two m-e-c as2 stations I always receive successful MDN response 'The AS2 message has been received. Thank you...' - which is expected.
Is this likely to be a jetty keystore problem - since this is used to sign the outgoing MDN. Is this correct?
The trading partner certificates have been added (as trusted) into this keystore, so I would not have expected any problems.
I was more than happy to appropriate blame to their configuration until I could not make the /n product work successfully either.
Let me know if there is anywhere I should be focusing my attention, and what further information would be useful for debugging.
My local station is RHEL5 Linux, running mec v1.0 b27.
Thanks.
Hi,
I encountered the same problems with a BizTalk user. I will try to switch to async and see if that works. I can send files with no problem when they send back a 997 it fails on their side with the following error:
Error [Unexpected error while parsing MDN - Integrity Check Failure while decoding message []. The exception is [Signature verification error: Computed digest [WYYP0xfglzsNOKHki0IKHxGSSR8=] does not match message digest [0K2mNI5IouH7YGB3hp/u2a8P9lg=] included within the authenticated attributes of signature]]
in the /n software
under trading partner (select your partner)
under MDN receipt
untick Request MDN receipt.
click on SAVE changes
try to send again.
If you can send from /n to mec then the signature on mec for /n is wrong or using the worng encription.
You should also check the other way - I bet you can send from mec to /n fine which means that the returning MDN from /n to mec is ok. Therefore the signature on /n is ok.
damon
I have just installed OpenAS2 to get a third opinion when communicating with mec.
This app was able to send but not receive valid MDN (org.openas2.WrappedException: org.bouncycastle.cms.CMSException: invalid signature format in message).
At this point I upgraded the BouncyCastle jars to the latest version (bcmail-jdk16-143.jar, bcprov-jdk16-143.jar) at the m-e-c end (to no avail) and then locally - at which time everything worked properly.
I need to check the other apps now - but this could be the clue.
Will update when I know more.
I don't think my partner wishes to use async MDN.
hi merky,
please give us detail of what to do if it does work.
I.e. what did you do locally?
thanks
Damon
@murky
We have heard about this problem already. I analyzed an AS2 message from the distributor you mentioned and have seen that they havend set the content transfer encoding. Could you please ask you partner to set it (best is to binary or base64) and post the results?
@Organize.com
We added a better MIC processing to mendelson opensource AS2 b27. Are you using this version?
Regards
Heller
@Heller:
I am using B27. The error is being reported on the BizTalk server side. When I switched to Async, I am not getting back the MDN...
We are going to try some configuration changes on the biztalk side now.
Hi Heller,
do you remember what you did to the /n software app to make change the transfer encodings?
thanks
Damon
@heller
I have requested that my partner change the Content Transfer Encoding setting - will make the results available.
Thx.
@organize.com
There are some tutorials about setting up AS2 in the Biztalk server. Please read the following manuals:
Overview:
http://msdn.microsoft.com/en-us/library/bb259970.aspx
Tutorial:
http://msdn.microsoft.com/en-us/library/bb245935.aspx
Regards
Heller
@damon
No. We didnt use the product itself but just built up a small test environment using their API. There was a method to set the content-transfer encoding header.
Regards
Heller
Hi all,
Sorry mistake on the partner software, it is a Bizlink server MDN problem. We went with turning off the MDN for when we send to the Bizlink server.
@heller
Partner made Content Transfer Encoding changes.
Now getting error:
[Jul 1, 2009 8:28:18 PM] mendelson_opensource_AS2-1246444098300-10@XXX: Outgoing MDN has been signed with the algorithm "SHA1".
[Jul 1, 2009 8:28:18 PM] mendelson_opensource_AS2-1246444098300-10@XXX: MDN created, state set to [processed/error: decryption-failed].
[Jul 1, 2009 8:28:18 PM] 20090701102808_64408F2F8E@bTrade:
MDN details:
--------------
Malformed content.
--------------
murky,
thats really weird. Could you please send me the inbound message and headers? Im not sure if I see something because its encrypted but lets try it.
sh at mendelson dot de
Regards
Heller
@murky:
Was your private key pair for the local station built with portecle? If it was, it probably does not have the "extensions" that are required in order to decrypt incoming data.
Please see:
http://community.mendelson-e-c.com/node/373
(Strange. Most forum software automatically makes clickable links. This one doesn't.)
neilparks1,
These key extensions are ignored in our software. You could use any key/certificate for encryption/signature even if it is just for webservers or something else.
Regards
Heller
@neilparks: Thanks for the hint.
We changed the settings.
I'm getting the same error (partner not able to verify my MDN signature after sending me a 997) using B27. When I actually send a signed and encrypted message to my partner there are no problems.
I'm just hoping that if anybody figures out what's going on they'll post here!
Dadmobile,
what system does your partner use?
Regards
Heller
Don't know if the issue come from this, but :
Be carefull when creating X509 certificates !
Key usage is a multi valued extension consisting of a list of names of the permitted key usages.
The supporte names are: digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly and decipherOnly.
You can sign with 'digitalSignature', sign MDN with 'nonRepudiation' .
You can crypt data with dataEncipherment .
Even your software don't care about this (weird !) (but maybe the X509 library cares about it for you :>) ...)
Remember that it can be the case for the software that is using your public certificate...
crownedgrouse,
a good point, didnt think about this possibility so far. Anybody who has problems with this verification issue, could you have a look at your key extensions and post them?
Regards
Heller
BizTalk Server Developer Center (MSCN)
"An error occurred when decrypting an AS2 message"
(answer) In answer to question 1, the certificate you use must have key usage for signing and encryption (sometimes noted as secure email).
That indeed was the problem for me. I was creating my keys using portecle and did not have all of the extensions I needed.
Thanks for the help!
Turns out I spoke too soon. My partner had turned off requesting a signed MDN and that's why this worked. We tried switching back and the added extensions did not resolve the problem.
Looks like murky was on to the problem earlier.
There seems to have been some sort of change to the bouncy castle APIs somewhere between 130-136 or so. I've tried using a few other AS2 servers and found that the problem arises when using old bouncy castle APIs to receive MDNs from Mendelson. On systems with newer versions of bc the problem goes away.
My partner doesn't seem willing or able to update their libraries for whatever reason, and reverting to an older version of bouncycastle on MEC causes major problems.
I'm guessing I'm out of luck.
Dadmobile,
a good hint, thank you for your effort! To be honest I had no idea about how to solve this issue so far because I wasn't able to reproduce it a single time.
Its not possible to update from older bc versions by simply copying the new bc jars into the classpath because the API has changed in my opinion.
Regards
Heller
Dadmobile,
I had a look to the bc releasenotes http://bouncycastle.org/releasenotes.html.
There are some fixes in the versions you mentioned that may affect the signatures:
Release 1.36
Another regression which sometimes affected the SMIMESignedParser has also been fixed.
Release 1.35
# SMIMESignedParser now handles indefinite length data in SignerInfos.
# Under some circumstances the SMIME library was failing to canonicalize mixed-multipart data correctly. This has been fixed.
Release 1.34
SMIMESignedParser now avoids JavaMail quoted-printable recoding issue.
Updating to a new version of bc (actual version is 1.43) is really recommended. Are there any product updates on your partners side? The mendelson AS2 server is always using the newest bc version (at release date). You can check this in the directory jlib, there will be the files bcprov-jdk16-xxx.jar and bcmail-jdk16-xxx.jar where xxx is the version number, e.g. 143 for 1.43.
Regards
Heller
Hi All,
I also faced the same issue.
I was using an AS2 software based on the newest BC version (1.43).
My partner was using /nsoftware AS2 connector to post AS2 messages to me. The "Synchronous signed MDN request" was selected.
First, when I ran the software on SUSE Linux with IBM JDK 1.4.2, my partner got the error The receipt signature could not be verified: Message digest mismatch in signature.
Then, I tried running the software on Windows with the same key/certificate used for the Linux case, everything worked fine.
The latest BC release doesn't seem to help. The issue seems to be OS platform related ...
Regards,
Victor
© 1999-2010 mendelson-e-commerce GmbH | Twitter | Contact us
Does your trading partner support sync MDN? Try changing to async and see if that works better.
"Program in haste; debug at leisure."