Bug 1198 - An error occurred when verifying security for the message
Summary: An error occurred when verifying security for the message
Alias: None
Product: Class Libraries
Classification: Mono
Component: System (show other bugs)
Version: 2.10.x
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2011-10-03 11:58 UTC by Alexander Riman
Modified: 2011-10-26 11:06 UTC (History)
3 users (show)

See Also:
Is this bug a regression?: ---
Last known good build:

Mono Client (5.22 KB, application/zip)
2011-10-03 11:59 UTC, Alexander Riman

Description Alexander Riman 2011-10-03 11:58:13 UTC
Created attachment 559 [details]
WCF Service Host (run on Windows .NET)

I'm getting the exception "An error occurred when verifying security for the message" from the WCF server:
1) when I use both SymmetricSecurityBindingElement and BinaryMessageEncodingBindingElement

to test this use the following line in the sample project:
MessageEncodingBindingElement encoding = binaryMessageEncoding;

2) when I call method Activate2 with profile parameter that is not null. This occurs also when using TextMessageEncodingBindingElement.

File TestWcfHost.zip contains Windows WCF server.
File TestMono.zip contains sample client.
Comment 1 Alexander Riman 2011-10-03 11:59:10 UTC
Created attachment 560 [details]
Mono Client

Test client
Comment 2 Alexander Riman 2011-10-03 12:07:38 UTC
If I call Activate2 with null as a profile parameter, then I don't get the exception.
Comment 3 Alexander Riman 2011-10-17 10:40:13 UTC
On server side I get in trace log the next error for case 2:

System.ServiceModel.Security.MessageSecurityException: The signature verification failed. Please see inner exception for fault details. ---> System.Security.Cryptography.CryptographicException: Digest verification failed for Reference '#_6'.

at System.IdentityModel.Reference.EnsureDigestValidityIfIdMatches(String id, Object resolvedXmlSource)
at System.IdentityModel.StandardSignedInfo.EnsureDigestValidityIfIdMatches(String id, Object resolvedXmlSource)
at System.ServiceModel.Security.WSSecurityOneDotZeroReceiveSecurityHeader.EnsureDigestValidityIfIdMatches(SignedInfo signedInfo, String id, XmlDictionaryReader reader, Boolean doSoapAttributeChecks, MessagePartSpecification signatureParts, MessageHeaderInfo info, Boolean checkForTokensAtHeaders)

Reference '#_6'is a Body element.
Comment 4 Alexander Riman 2011-10-23 12:20:16 UTC
Case 2 occurs when we have any null value inside class parameter (string or some kind of Nullable<>). If, for example, set all string members to String.Empty, then we will not get this error.
Comment 5 Alexander Riman 2011-10-24 10:08:13 UTC
I have found how to fix this bug.
It is needed to change a file

change line 89 from
writer.WriteAttributeString ("nil", XmlSchema.InstanceNamespace, "true");
writer.WriteAttributeString ("i", "nil", XmlSchema.InstanceNamespace, "true");
Comment 6 Alexander Riman 2011-10-24 12:39:26 UTC
Regarding 1st case of this bug.
On the server I got the same error (when using binary encoding), but now for message part '#_4' - "a:ReplyTo" element.

When using binary encoding, server canoninalizes message and get the next xml:
<a:ReplyTo xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" u:Id="_4">
	<Address xmlns="http://www.w3.org/2005/08/addressing">http://www.w3.org/2005/08/addressing/anonymous</Address>

Mono canoninalizes this xml in this way:
<a:ReplyTo xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" u:Id="_4">
Also this xml is produced when using text message encoding (and it is correct on the server side).
Comment 7 Jeffrey Stedfast 2011-10-24 13:51:09 UTC
Hey Alex,

Can you try http://files.xamarin.com/~jeff/monotouch-5.0.dmg and see if that fixes the issue?

(this is actually latest git)
Comment 8 Jeffrey Stedfast 2011-10-26 10:59:33 UTC
If I understood correctly, Alex told me on IRC that this has solved his issue.
Comment 9 Jeffrey Stedfast 2011-10-26 11:02:34 UTC
Okay, Alex just told me I misunderstood. What he meant was part2 was fixed, but part1 is still an issue. Reopening until part1 gets fixed.

Sorry Alex!

Note You need to log in before you can comment on or make changes to this bug.