Message digest mismatch in signature

As long as we dont have access to these systems its hard to say what happens there.
During the test phase of the b29 we had often the problem that this was a configuration issue. A good starting point to debug it is extracting the certificate from the signed MDN and really check the fingerprint or serial no and compare it to the fingerprint or the serial no of the used cert of the receiver AS2 system to see if this is really the same.

Regards
Heller

Hi guys,

I opened a thread about this problem before finding this topic.

Looks like I am facing the same problem here.

Everything works good from mendelson AS2 side, but my partner is not able the verify the MDN message that I send back when they send me files.

It says "Signature verification failed due to message digest mismatch. Signature could not be validated."

http://community.mendelson-e-c.com/files/image001.jpg

MDN that is being sent back.

The AS2 message has been received. Thank you for exchanging AS2 messages with mendelson opensource AS2.
Please download your free copy of mendelson opensource AS2 today at http://opensource.mendelson-e-c.com

------=_Part_705_651467.1256167257337
Content-Type: message/disposition-notification
Content-Transfer-Encoding: 7bit

Reporting-UA: mendelson opensource AS2
Original-Recipient: rfc822; FG_AS2Server_T
Final-Recipient: rfc822; FG_AS2Server_T
Original-Message-ID: <023465155978540376@as2.am.gxsics.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Received-Content-MIC: So7ngAYyH7BgM+oSZiJ7/MA4/2Y=, sha1

------=_Part_705_651467.1256167257337--

I am running the b29

Thank you

Same was reported by my partner. I tried to change content-encoding and remove old jar files from the mecas2 jlib folders. Also tested with sync and async MDN mode. What I found is that my partners using compresson experienced this issue. Others without compression do not have any issue with the MDN. Can the compression cause it?

What is intersting too that the MDN is not encrypted. This would mean that what needs to be checked is a simple SHA1 digest on the receiver side. How this can be different?

as2user

Dear Heller,

northw mentioned that the MDN is generated differently depending on the bcmail and bcprov versions. Is there any possibility to use older versions running b29 and check the result internally? I mean check the generated signed MNDs.

Thank you,

as2user

Hi all

I've tested the as2 connector for a few hours and I am able to send and receive files now. But I have the same problem as discussed here. m-e-c doesn't send signed MDNs.
While I was comparing the MDNs received by m-e-c and those which are send by m-e-c I saw that a MDN sent by m-e-c is not signed. It looks like exactly a not signed one.

I made following steps to take a look at the message m-e-c sends out:
Double click at the received message. Now am in the message details window. Then click on the secound line. Then click on “Raw data (unencrypted)”.

Here is the complete message and you see there is no signature at the end. Maybe this is the problem! Please help!

Content-Type: multipart/report; report-type=disposition-notification; boundary="----=_Part_29_10881285.1256680677414"

------=_Part_29_10881285.1256680677414
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

The AS2 message has been received. Thank you for exchanging AS2 messages with mendelson opensource AS2.
Please download your free copy of mendelson opensource AS2 today at http://opensource.mendelson-e-c.com

------=_Part_29_10881285.1256680677414
Content-Type: message/disposition-notification
Content-Transfer-Encoding: 7bit

Reporting-UA: mendelson opensource AS2
Original-Recipient: rfc822; XXXXXXX
Final-Recipient: rfc822; XXXXXXX
Original-Message-ID: <324d8e24-6332-460f- XXXXXXX -7dab1ef62a9d@ XXXXXXX -b156-47f3-9826-facf0c676e36>
Disposition: automatic-action/MDN-sent-automatically; processed
Received-Content-MIC: s7meT+ XXXXXXXXXXXXXX+I4SM=, sha1

------=_Part_29_10881285.1256680677414--

mn,

It seems that everybody with any problem regarding MDNs or configuration problem is posting into this thread, I doubt that this will help.
Anyway in your case this is not a problem of the mendelson AS2 server. The AS2 message sender flags if the returned MDN should be signed or not. Please ask your partner to request signed MDNs.

Regards
Heller

heller,

my partner requestet a signed MDN and he gets the error message "Message digest mismatch in signature" because mendelson AS2 server does not sign the MDN.
I will double check my configuration again and I will also take a look at the messages my partner sends.

Regards
Markus

Markus,

please let me verify the issue. Please send me the following things: The MDN the mendelson AS2 server sent and the certificate your partner uses to verifiy the signature. Please dont send me any certificates of the mendelson AS2 server.

Please send it to sh at mendelson dot de

Regards
Heller

Dear Heller,

would you please explain the above request with a bit more details. I would like to check the same and verify the MDN manually. Where is the signed MDN located exactly in the AS2 server?

Thank you very much,

as2user

as2user,

in message details of a transaction you could see all files of a transaction with their filenames.

Regards
Heller

Hi all,

this issue has become a huge topic in this forum and we are still on it.
Fact seems to be after severeal messages we received from the community that openSSL has no problems to verify the signature of the MDN our products sends. That means that the MDN is signed correctly and could be verified without problems.
You could check this using openSSL if you install it and run the following commands:

1. Convert the certificate to verify the signature to PEM format
openssl x509 -inform der -in certificate.cer -out certificate.pem

2. Verify the signature
openssl smime -verify -in sent.mdnfile.txt -CAfile certificate.pem

The result should contain "Verification successful".

Anyway even if we didnt encounter it so far there seems to be a compatibility problem. It is weired that the signatures of the MDN cause problems sometimes and the signatures of the messages dont. We received a hint that text potions of the MDN that contain a single "\n" could cause this problem. Every "\n" should be replaced by a "\r\n". No idea if this solves the problem but it would be great if somebody could check this with a system that shows the compatibility problem. The class where to change it is de.mendelson.comm.as2.message.MDNText.

Thanks for your help, please let us know if this was the issue.
Regards
Heller

Hi all,

good news, the new changes we made seem to fix the problem. We had three tests with systems that had formerly problems and the signature verification works fine now. The changes will be delivered in the next release. Thanks to the people who took the time to test.

Regards
Heller

Trust you are well and not too cold in Berlin.

Since I have been coming here I think there has been one update which was recently. Am guessing that the updates are pretty much yearly. :)

Is there a patch available or some instructions you could give to temporarily solve the problem in the interim.

Alternativly a guestimate of the release would be cool (no pun intended)

Thanks
Damon

Damon,

You could solve the problem if you replace all "\n" to "\r\n" in the strings of the class de.mendelson.comm.as2.message.MDNText.

As far as I understand there are some AS2 products out that extend every single "\n" to "\r\n" in an incoming AS2 message or MDN _BEFORE_ checking the signature. That means they are changing message content if they encounter a single "\n". No idea why they are doing this but it will surely lead to a signature verification problem of the message.

We havent encounted this so far because this is only a problem of the open source version of the mendelson AS2 server, the commercial version is not affected.

Regards
Heller

Hi Heller,

ok worked all that out and changed the MDNText

I did have to remove some information as the JAVA compiler didnt like some of the references - so I ended up with this

//$Header: /cvsroot-fuse/mec-as2/b29/de/mendelson/comm/as2/message/MDNText.java,v 1.1 2009/10/07 10:08:28 heller Exp $
package de.mendelson.comm.as2.message;

/*
* Copyright (C) mendelson-e-commerce GmbH Berlin Germany
*
* This software is subject to the license agreement set forth in the license.
* Please read and agree to all terms before using this software.
* Other product and brand names are trademarks of their respective owners.
*/
/**
* Text that is written to MDN
* @author S.Heller
* @version $Revision: 1.1 $
*/
public class MDNText {

public static final int RECEIVED = 1;
public static final int ERROR = 2;

public static final String get(final int ID) {
switch (ID) {
case RECEIVED:
return ("The AS2 message has been received. Thank you for exchanging AS2 messages with " + ".\r\nPlease download your free copy of "
+ " today at http://opensource.mendelson-e-c.com\r\n\r\n");
case ERROR:
return ("Thank you for exchanging AS2 messages with "
+ ".\r\nPlease download your free copy of "
+ " + today at http://opensource.mendelson-e-c.com.\r\n\r\nAn error occured during the AS2 message processing: ");
default:
return ("");
}
}
}

I can send small files fine but when I send large files to MEC I get this error

[Nov 12, 2009 11:18:03 AM] ed9ccf0c-6654-481d-ab79-6638732d68d3@7d37f50f-046a-4087-96bb-c871bfd0f59c: Incoming transmission is a AS2 message, raw message size: 56.23 KB.
[Nov 12, 2009 11:18:03 AM] ed9ccf0c-6654-481d-ab79-6638732d68d3@7d37f50f-046a-4087-96bb-c871bfd0f59c: AS2 message is encrypted.
[Nov 12, 2009 11:18:03 AM] ed9ccf0c-6654-481d-ab79-6638732d68d3@7d37f50f-046a-4087-96bb-c871bfd0f59c: The data has been decrypted using the key "daisychainedi1-ECOM1".
[Nov 12, 2009 11:18:03 AM] ed9ccf0c-6654-481d-ab79-6638732d68d3@7d37f50f-046a-4087-96bb-c871bfd0f59c: AS2 message is signed.
[Nov 12, 2009 11:18:03 AM] ed9ccf0c-6654-481d-ab79-6638732d68d3@7d37f50f-046a-4087-96bb-c871bfd0f59c: The sender used the algorithm SHA1 to sign the message.
[Nov 12, 2009 11:18:03 AM] ed9ccf0c-6654-481d-ab79-6638732d68d3@7d37f50f-046a-4087-96bb-c871bfd0f59c: Using certificate "daisychain test n as2" to verify signature.
[Nov 12, 2009 11:18:03 AM] ed9ccf0c-6654-481d-ab79-6638732d68d3@7d37f50f-046a-4087-96bb-c871bfd0f59c: Verification of digital signature failed (message-digest attribute value does not match calculated value).
[Nov 12, 2009 11:18:03 AM] mendelson_opensource_AS2-1257985083546-4@DaisychainEDI1_Daisychain-Test-N-AS2: Outgoing MDN has been signed with the algorithm "SHA1".
[Nov 12, 2009 11:18:03 AM] mendelson_opensource_AS2-1257985083546-4@DaisychainEDI1_Daisychain-Test-N-AS2: MDN created, state set to [processed/error: authentication-failed].
[Nov 12, 2009 11:18:03 AM] ed9ccf0c-6654-481d-ab79-6638732d68d3@7d37f50f-046a-4087-96bb-c871bfd0f59c:
MDN details:
--------------
Error verifying the senders digital signature: message-digest attribute value does not match calculated value.
--------------
[Nov 12, 2009 11:18:03 AM] mendelson_opensource_AS2-1257985083546-4@DaisychainEDI1_Daisychain-Test-N-AS2: Synchronous MDN sent as answer to message ed9ccf0c-6654-481d-ab79-6638732d68d3@7d37f50f-046a-4087-96bb-c871bfd0f59c.

Any ideas?
Thanks
Damon

Hi,

I am interrested for implement your open source solution but i have the same problem with MDN which are not decrypted correctly by Sterling commerce AS2.
Have you an idee of a date to implément the correction ?

Thanks for your answer
Regards.
bengil

Failure unpackaging message Error - class: 5; subclass: 1; code: -1; reporting function: SecureMessageResolver.ValidateSMIMEDetachedSignaturecalled function: SecureMessageResolver.ValidateSMIMEDetachedSignatureText: verification failed

bengil,

the problem has been fixed in the code base. We dont have a release date so far.

Regards
Heller

Hi People,

Greetings from South Africa!

Just to add a bit more information to this thread:
I believe I am experiencing the same issue, while trying to do AS2 communications with a product called "Cleo VLTrader", which is used by our one-and-only AS2 partner. :-(

On their side, our AS2 trading partner gets the following error message, after they have sent data to our Mendelson Opensource (v1.1b29) AS2 setup:

Content hash does not match to MessageDigest attribute value!

I have read the comments from heller above. I guess I must also try to modify the "MDNText.java" file, by replacing all the "\n" with "\r\n". Maybe this will solve the problem.

For those who are interested, I will also post the more complete error text from the Cleo VLTrader side, just after this post.

Regards, Riaan

As promised, here is the more complete error text, from the Cleo VLTrader side of things:

WARNING! VLTrader 4.1.20 has detected a failure while sending a message

2009/12/08 10:00:06 Response: "200 OK"
2009/12/08 10:00:06 Exception: "iaik.cms.CMSSignatureException:
iaik.cms.InvalidContentHashException: Content hash does not match to
MessageDigest attribute value!
at iaik.cms.SignerInfo.verifySignature(Unknown Source)
at iaik.cms.SignerInfo.verifySignature(Unknown Source)
at iaik.cms.SignedDataStream.verify(Unknown Source)
at iaik.cms.SignedDataStream.verify(Unknown Source)
at iaik.smime.SignedContent.verify(Unknown Source)
at iaik.smime.SignedContent.verify(Unknown Source)
at com.cleo.lexicom.beans.as2bean.MDNParse.extractElements(MDNParse.java:256)
at com.cleo.lexicom.beans.as2bean.MDNParse.(MDNParse.java:199)
at com.cleo.lexicom.beans.as2bean.MDN.processSyncMDN(MDN.java:246)
at com.cleo.lexicom.beans.as2bean.MDN.(MDN.java:69)
at com.cleo.lexicom.beans.as2bean.HttpSender.processResponse(HttpSender.java:410)
at com.cleo.lexicom.beans.as2bean.AS2Action.post(AS2Action.java:347)
at com.cleo.lexicom.beans.httpbean.HttpAction.issue(HttpAction.java:2228)
at com.cleo.lexicom.beans.httpbean.HttpAction.put(HttpAction.java:900)
at com.cleo.lexicom.beans.httpbean.HttpAction.put(HttpAction.java:701)
at com.cleo.lexicom.beans.httpbean.HttpAction.putFile(HttpAction.java:691)
at com.cleo.lexicom.beans.httpbean.HttpAction.putFile(HttpAction.java:666)
at com.cleo.lexicom.beans.httpbean.HttpAction.putFileLoop(HttpAction.java:584)
at com.cleo.lexicom.beans.httpbean.HttpAction.put(HttpAction.java:542)
at com.cleo.lexicom.beans.httpbean.HttpAction.macroCommand(HttpAction.java:408)
at com.cleo.lexicom.beans.LexActionBean$LexBeanRunCommand.run(LexActionBean.java:2940)
at java.lang.Thread.run(Thread.java:595)

Result: "Exception"
"iaik.cms.CMSSignatureException: iaik.cms.InvalidContentHashException:
Content hash does not match to MessageDigest attribute value!

Hi Heller and Everybody,

Just to give some feedback here: I got my MDN issue resolved!

I implemented Heller's suggestion to replace all the "\n" occurrences in the "...comm.as2.message.MDNText.java" source code file, and that worked for me.

My AS2 trading partner (using Cleo VLTrader) now reports that the MDNs are working correctly on their side. In other words: MDNs produced by Mendelson Opensource are being processed successfully on the Cleo VLTrader side.

Now I can finally replace an old AS1 (e-mail) solution with AS2 (http).
:-)

Thank you Heller (and Mendelson), for a GREAT opensource product!

Good luck to you all.
Regards, Riaan.

riaanp1,

nice to hear you fixed it for your version and it works fine. Anyway the fix will be included in the next release of the mendelson opensource AS2.

Regards
Heller

If it is going to be awhile before the next build is released, is it possible to release this fix as a patch?

with riaanp1's help I got my MDN's working with partners based on the removal of the \n in MDNText.java. The partners are no longer complaining.

thx to all that helped.

FWIW, replacing the occurrences of "\n" with "\r\n" and recompiling MDNText.java solved the same problem for me.

Heller,

Could you please give me the default path of MDNText.java file.

I have search it but I didn't found.

Regards
Kalyan

hello everybody, I think I have the "reversed" problem.

I'm actually using mendelson to test the routines of my software.

What's happening is that if mendelson sends a message requesting a signed MDN and my software sends it, mendelson complains about the digital-signature verification failed.

here's the complete log

[6:23:38 PM] Processing the file "off_rich_matching.txt" for the relationship "mostro7/niphlod".
[6:23:38 PM] mendelson_opensource_AS2-1282839818797-609@mostro7_niphlod: Outgoing message signed with the algorithm SHA-1,using keystore alias "mostro7".
[6:23:38 PM] mendelson_opensource_AS2-1282839818797-609@mostro7_niphlod: Outgoing message encrypted with the algorithm 3DES, using keystore alias "niphlod".
[6:23:39 PM] mendelson_opensource_AS2-1282839818797-609@mostro7_niphlod: Outbound AS2 message created from "off_rich_matching.txt" for the receiver "niphlod" in 206ms, raw message size: 3.14 KB
[6:23:39 PM] mendelson_opensource_AS2-1282839818797-609@mostro7_niphlod: The file "off_rich_matching.txt" has been deleted and enqueued into the processing message queue of the server.
[6:23:39 PM] mendelson_opensource_AS2-1282839818797-609@mostro7_niphlod: Sending message to http://127.0.0.1:8000/as23/default/up/, sync MDN requested.
[6:23:39 PM] mendelson_opensource_AS2-1282839818797-609@mostro7_niphlod: Message sent successfully (HTTP 200); 3.14 KB transfered in 279ms [11.27 KB/s].
[6:23:39 PM] blablabla@mostro7: Incoming transmission is a MDN.
[6:23:39 PM] blablabla@mostro7: MDN is the answer to AS2 message "mendelson_opensource_AS2-1282839818797-609@mostro7_niphlod".
[6:23:39 PM] blablabla@mostro7: MDN state is [processed].
[6:23:39 PM] blablabla@mostro7:
Details of MDN received from remote AS2 server:
--------------
MDN for message
--------------
[6:23:40 PM] blablabla@mostro7: MDN is not encrypted.
[6:23:40 PM] blablabla@mostro7: MDN is signed.
[6:23:40 PM] blablabla@mostro7: Using certificate "niphlod" to verify signature.
[6:23:40 PM] blablabla@mostro7: Verification of digital signature failed (message-digest attribute value does not match calculated value).
[6:23:40 PM] Error verifying the senders digital signature: message-digest attribute value does not match calculated value.
[6:23:40 PM] mendelson_opensource_AS2-1282839818797-609@mostro7_niphlod: Transaction state written to /home/niphlod/Scrivania/mendelson/messages/niphlod/sent/mostro7/20100826/off_rich_matching.txt_mendelson_opensource_AS2_1282839818797_609@mostro7_niphlod.sent.state.

OK, then I took /home/niphlod/Scrivania/mendelson/messages/_rawincoming/20100826182339693_unknownhost.as2 that is the raw incoming MDN, added the content-type line by hand and ran:

openssl smime -verify -in raw.as2 -noverify -CAfile mycert.pem

and voilà, verification of the message is successful.

I can provide the cert and the raw file, if you want to inspect the problem in a better way.....

has somebody faced this issue before ?

keep up the good work and thanks a lot

Niphlod

Niphlod,

as I have written earlier in this thread there is something special in the AS2 protocol that seems not to be documented very well in the RFC:
In the message every "\n" is extended to "\r\n" in an incoming AS2 message or MDN _BEFORE_ checking the signature. That means that data content is changed, that is why openssl says the verification is successful but AS2 fails at this point. Do not use standalone "\n" in your message, always use "\r\n".
We had problems with the verification of MDNs signatures because of this issue for a long time but it has been fixed in the actual build 31.

Regards
Heller

I read that and I'll keep that in mind, but the problem is that the entire MDN has CRLF as line terminators.

From what you say, I expect that mendelson can complain in the case I send an MDN with only LF as line terminators (or some random LF in it), because the "AS2 implementation" replace all "singles" LF with CRLF, hence the change of content and the failed verification.

I compared my raw response and mendelson's raw file and they have the same content. diff between the two reveals that nothing changed...

BTW, I'm using b31 as.