wcf wshttpbinding certificate validation on client and detecting encryption. - wcf

I have a wcf service. The binding of the service is wsHttpBinding and the security type is message security. The service is hosted on IIS. The site binding on IIS is http(80). The service also has a certificate which is configured with a service behaviour.
Binding:
<wsHttpBinding>
<binding name="maksServiceBinding" maxReceivedMessageSize="2147483647">
<security mode ="Message">
<message clientCredentialType="UserName" establishSecurityContext="true" />
</security>
</binding>
</wsHttpBinding>
Behaviour:
<serviceCredentials>
<serviceCertificate findValue="xxxxName" x509FindType="FindBySubjectName" storeLocation="LocalMachine" storeName="My" />
<userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="xxx.xxx.xxxServiceUsernameValidator, xxx.xxx"/>
<!--<clientCertificate >
<authentication certificateValidationMode="ChainTrust" revocationMode="NoCheck"/>
</clientCertificate>-->
</serviceCredentials>
My service is working well but I have three questions:
1) How can I enforce my clients for these configurations:
certificateValidationMode="ChainTrust" revocationMode="NoCheck"
These configurations can be changed on client(ex: certificateValidationMode can be changed to None) but I do not want clients to change these configurations. (commented) does not work.
2) A client needs to add certificate to consume my service when the certificateValidationMode is ChainTrust. But if the client does not add certificate and change certificateValidationMode to None, client can consume the service. If I can not find a solution to prevent this, I will write custom certificate validation with X509CertificateValidator. Because the service messages can not be encrypted(unsecure).
3) I watch the requests and responses on the client side with fiddler2. I tried out two situations.
First; the certificate is added and certificateValidationMode is ChainTrust.
Second; the certificate is not added and certificateValidationMode is None.
The requests and responses for both of the situations are same. Here the questions come. Are requests and responses encrypted? If they are encrypted, how can the second situation be? Because there was no certificate on the client. Can the certificate be stored on somewhere else like cache?
Fiddler2 output:
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" 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">
<s:Header>
<a:Action s:mustUnderstand="1" u:Id="_2">http://nvi.gov.tr/adres/IMaksCrudBusinessOf_Bina/Read</a:Action>
<a:MessageID u:Id="_3">urn:uuid:e1ef9b1b-14c4-4952-b535-ff84a11b18b4</a:MessageID>
<a:ReplyTo u:Id="_4">
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1" u:Id="_5">http://umuts/MaksServices/MaksBinaIslemleri.svc</a:To>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="uuid-fcbcbde5-ec92-4e46-9a7b-f541ed9e62c8-11">
<u:Created>2013-03-10T17:54:01.744Z</u:Created>
<u:Expires>2013-03-10T17:59:01.744Z</u:Expires>
</u:Timestamp>
<c:SecurityContextToken u:Id="uuid-e4d1e34d-0fe2-4a44-a5f7-b94ab0e4d33c-5" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
<c:Identifier>urn:uuid:ced2f798-d488-405d-9e4d-a9bce5acc8f5</c:Identifier>
</c:SecurityContextToken>
<c:DerivedKeyToken u:Id="uuid-fcbcbde5-ec92-4e46-9a7b-f541ed9e62c8-9" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
<o:SecurityTokenReference>
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct" URI="#uuid-e4d1e34d-0fe2-4a44-a5f7-b94ab0e4d33c-5"/>
</o:SecurityTokenReference>
<c:Offset>0</c:Offset>
<c:Length>24</c:Length>
<c:Nonce>vUN53uBYs3XxRkW30IRUGg==</c:Nonce>
</c:DerivedKeyToken>
<c:DerivedKeyToken u:Id="uuid-fcbcbde5-ec92-4e46-9a7b-f541ed9e62c8-10" xmlns:c="http://schemas.xmlsoap.org/ws/2005/02/sc">
<o:SecurityTokenReference>
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/sct" URI="#uuid-e4d1e34d-0fe2-4a44-a5f7-b94ab0e4d33c-5"/>
</o:SecurityTokenReference>
<c:Nonce>cJDYx++Xl28SaS57RPr/Og==</c:Nonce>
</c:DerivedKeyToken>
<e:ReferenceList xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:DataReference URI="#_1"/>
<e:DataReference URI="#_6"/>
</e:ReferenceList>
<e:EncryptedData Id="_6" Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<o:SecurityTokenReference>
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk" URI="#uuid-fcbcbde5-ec92-4e46-9a7b-f541ed9e62c8-10"/>
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>Awdg0bBuWmrYzddiVm2TztRIvytluR/wUVfe329DiPk2kNVO1NI5RE4/Gol/3dyObGXbvBO9eFR1Y84gOAw6gwVue+BVRMqIlYxuVkSijXsWzp/Cz84nJN+paGnKtXMIlefdRC3y3G3AcN3TX8hzwoPM1BQttJ8YJQV8PK7Lbgv2YXX/9XzgIteeIgz5KzMWp+rJ0egGxdsKLkwE3jFbj+ncfiKX7qWoFhQgCz53FbNXvPMQ/QE7LBaqhEereX/U2+Dc8ku+D/eep9g5i6v9p0RPv2g5K4dT5UeLXIh5Whqh8fx9xSZY1WsV+RegePNIyXEf/meeN3FnnC8dyJENoxfKny0tWfkiXyLxtF6SHHAUh50VKPnsrdpJh+9yIfprCpLRSLqIAaRGPjiK+oZEnDSNI7q/ipFB8KHeJKi+b38VrfBC/4IqUL+BQ+AHfWyRS2yYsAXGBWsIBLzUU7AFsslpJb3Z5Q2Z7g5FpRNUKiIbvhPZ+1dLBdthYAP0JuiawX4WCq4Ew0UB6Rh6bH1OD5eqfEbetRzr4KJt/9VW585x/Opx24wAfP2ktC5Tl//Az6jz1PAOhotHDXUN6FCW5oG9ah93S2i/fHNpqeiJoVCWEOBR+v8ExJcgbC/EtH01TaoyMHS+UlpbzWZk1h5sC21rtqHVrWjy4s0ZupBiPWabfVwKzz0VJ4DCTbnnHdNcyryvAM6kS+6qOgZbf6pWDx5MqRp00l2+N3yFJWoOCjPWzCqRcL0WUHucrJhRvCzpzKy16mQuFyFrZwXJjYmSBFv41V1lP/uyV+1+WMRcAdezqDDaYOyRb15jizMXZD9YYRau89nre64UzsCDNpmt4heD+tqOIivsId4tteKg64umY3xPRRaD0beZDrfBm8SpXsgt7U1K/wd2R2Q4U0fVFKgYJPH/1W6ZgONd/skg6AZ1tRK4y2nDiQk+yV8F99j9ipk2iMgjhDxlNN20yA2Svz85i3wJqUp3Qh+Eksmre2rcuClE1GZPadAOWumJVuL8FsNjZ50jeTWwYUE3jYKxCFIs+05jeiRbBRrbhVCDSze/47to9sNNXyGrR0yxIYE5QI+fE7zbjalWXdSISD68cpuGUg+ne/+ABa3DMlxmj1DOD3DwlHpWFxWC4F2E/nQvd5cDczyru+hpEw6kObR1RhlZR8AWY1FDP7YotugGM3imPelrRR91+vYPjY74pz0XZX6KqIlUS70as8tKodrZejMxqK542pmsc1r1/NyOmr669++6EEt1U5gikO8LLuUyKw7IpI6cxqyIN1aKoMhpZktS3NS4paQdWxtJqS1mT0FgvpyxVurPliWh5nreb8/5/txrfVxvNjmbEEVDTdHIa4IzefPpX19ZQwYnWea5hGGBSS7q20VA3gXkQGmHxjyZl9Vm6xCqTXqI8HLk7+zOncUuzo8rsk6k/LoEhLKkVpSliwrMMZdOvAyY9mgpn55KWDpD4cTxli4KhosltOmZ4S+8cErMSwBUVqiB2DEMj2nPsOjM9wA1LnPsWj7yva84Fc5/zwLS+hUN40MFohtsu3+wj5eyXnoIbDmTGTLq4W/p8DFxZfgE50DLtNmy06TAz06lOzpXYViFwC/gJnhNrmn/a3l79QCIl+ldyOqbrsosSSCXqk7aLx6IvLiw5AugiH3lQXH6bjtPd3KoYXZiTbSdTNNDy+Q8d1uO8lDAsXClXdRqUuss8pPQJhVHUdvffr0AF//mpfiC1O5kSppTpJCjyhpZ7B+uHLKeehXuhvuGxyIsdb4NzPD+cjDhxwwdEFH2nUCOYLdIsqzSCluF3hovAFnCQ00wdqS2s/GTu+p+8d7VrYaau6Fv+B8/N3pBLBWIPjmEbKlmX70KaBAT2y3CEUG+nGmiqI649UXJ492A7s0bdTBVmetdTyAyvRsFucDi/ZswbTr4D4LrDNouYn+cI0cUoXOAJ5zv3xFGuYdeqsyaLIHP2y06P9RSHCACBvjZHwW3Kl4BUZOneTCAquFPgFdc8gcwXmx8uGaIgwdTx9H20FOq+VIacpr2sThZ4yxZdz6SPIejlOOyrL/oxgaqRi9Rkt+N91Z6U7/dK3Rl8SHjc0LQT3czL0MOtzwY5lq05FXhnSzpkXauQ9K8Qy83Nxfx5s8DT3tOyFOdTe308melK/3uRlvyQ5wJFqcd6u7+fQNqCsDJ3hQmHJqZCwRawJPcS1B9zlpo+9sT86Gz0HwUpSILHEHF0iBLg9X1yz6jZfeWc8qW1noFvnRI0aNkiypQSEbC/nR4AJp7KPsaD6bwK7+H3yX+p6Tqydyj4ckVQBP9jV3w0dfk5wQNaQIXyVEzr4/x9Jg4fb4CGK8gCTSFx8jPta8vjWRirf/LpYoFwF02S6llSGRJERIc/hR1FPLTn3gfx5sl5bqkpmk2U3hHSO0OR1fYU8Dcw2YJduxC3e8aHXOMVrkHx4N6hLT6a5EJy8N4W79vqo+6964ZC9nKxQk/l7UkgcEtogw5pnuZZn39elk4pAK51FsrAgnzNIpFoepOfBP3hLj3xGFSUDHmt50G+cAlxgl04Y2i/isecXDOxzMxWN7wpJjcgr25tju93Y2Bt+sR4Zs+mg4A2cSQ4LSrXrfQSPuKL0KeU60u9wJmQda/zT5NNOIVFL4fTl9yNOBugpESbTIF/ceg4KW9rOeyqJJQg16GRVLG1Xayu6GXdjSuxVfoInccNJQJZpzaeMZolYeHnQVWcP9D1QmBBuJL/OnKrsvDpZt61qn9lCXcYF+UiTl+tZOOQry9ASKnNZFHIIymUyFb26Gzgydzud5b/HCfy6T4YxKO</e:CipherValue>
</e:CipherData>
</e:EncryptedData>
</o:Security>
</s:Header>
<s:Body u:Id="_0">
<e:EncryptedData Id="_1" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<o:SecurityTokenReference xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<o:Reference ValueType="http://schemas.xmlsoap.org/ws/2005/02/sc/dk" URI="#uuid-fcbcbde5-ec92-4e46-9a7b-f541ed9e62c8-10"/>
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>xgJK91cn2sLm4FvnVJZoueexPXVExJaA/gCoBdZK2nLlBLvIFnQz/Y6okzRfh0jugF6Vrx5aj+0i3T6V6TfNnBkFuLsKnDeyL2D/cawlBqM=</e:CipherValue>
</e:CipherData>
</e:EncryptedData>
</s:Body>
</s:Envelope>

Related

Digest Value ,trust store, Certificate validation mode

I am connecting to an external java webservice using WCF. I have no control over the service.
The supporting tokens are 2 x509's and one username token, sign and encrypt only the body. I am able to generate a 100% compliant request as per vendor soap request sample.
WCFClient uses a custombinding to generate the outgoing request. I am getting a problem with Digest Value in the response. How do I even check, verify this?.
The server log says the following :
Signer status: 'Extracted the certificate chain from the BinarySecurityToken having format x509'
Reject set: Hash values do not match.
Hash values do not match: 'l6kqP048t5INzJT3W8gxVSXplaE=', which is the Digest value in the Signature.
<e:EncryptedKey Id="_0" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<o:SecurityTokenReference>
<o:Reference ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" URI="#uuid-63c0b13f-8368-4bc9-a493-b362c67ac14b-1" />
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>REMOVED=</e:CipherValue>
</e:CipherData>
<e:ReferenceList>
<e:DataReference URI="#_2" />
</e:ReferenceList>
</e:EncryptedKey>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="#_1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>l6kqP048t5INzJT3W8gxVSXplaE=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>gCwFapZ3D/vUXsvAShTQwNWJoA23ad54NRmUWXR7IBFbsr75HBdZUG5lO1Af+ncShzwJA2a6jJXJmw/1gKswyAP9QuZsa9D+6fGh8jwcVqjm5v/Sh9rgQxWjL6U1kkovP0IAqEjafRu6YgmauFVCHUrJ2QfIN96WYTPnYm9Puvs=</SignatureValue>
<KeyInfo>
<o:SecurityTokenReference>
<o:Reference ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" URI="#uuid-63c0b13f-8368-4bc9-a493-b362c67ac14b-2" />
</o:SecurityTokenReference>
</KeyInfo>
</Signature>
As per my knowledge I am not doing anything special
Custom binding does all of this
Would it be an issue with trust stores. Working soap UI sample has a truststore cacerts with a pwd changeit. I think this ships with javakeytool.
I am using the following custom binding and chain trust
AsymmetricSecurityBindingElement secBE = AsymmetricSecurityBindingElement.CreateMutualCertificateDuplexBindingElement();
secBE.AllowSerializedSigningTokenOnReply = true;
secBE.DefaultAlgorithmSuite = SecurityAlgorithmSuite.TripleDesRsa15;
secBE.MessageSecurityVersion = MessageSecurityVersion.WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;
X509SecurityTokenParameters x509ProtectionParameters = new X509SecurityTokenParameters();
x509ProtectionParameters.RequireDerivedKeys = false;
secBE.InitiatorTokenParameters = x509ProtectionParameters;
secBE.RecipientTokenParameters = x509ProtectionParameters;
secBE.MessageProtectionOrder = MessageProtectionOrder.SignBeforeEncrypt;
secBE.RequireSignatureConfirmation = false;
secBE.IncludeTimestamp = false;
CustomTextMessageBindingElement enc = new CustomTextMessageBindingElement(Encoding.UTF8.ToString(), "text/xml", MessageVersion.Soap11);
HttpsTransportBindingElement b = new HttpsTransportBindingElement();
b.RequireClientCertificate = true;
CustomBinding be = new CustomBinding();
be.Elements.Add(secBE);
be.Elements.Add(enc);
be.Elements.Add(b);
-----------------------------
proxy.ClientCredentials.ClientCertificate.SetCertificate(StoreLocation.LocalMachine, StoreName.My, X509FindType.FindBySubjectName, "Usercert");
proxy.ClientCredentials.ServiceCertificate.SetDefaultCertificate(StoreLocation.LocalMachine, StoreName.My, X509FindType.FindBySubjectName, "ServerCert");
proxy.ClientCredentials.ServiceCertificate.Authentication.RevocationMode = X509RevocationMode.NoCheck;
proxy.ClientCredentials.ServiceCertificate.Authentication.CertificateValidationMode = System.ServiceModel.Security.X509CertificateValidationMode.ChainTrust;
Updated to show working both the working request and the faulty one
Both are the same as per my knowledge. One difference is the order
Working one has BST, UST, BST
Mine has BST, BST, UST.
Working Soap UI Request
<soapenv:Envelope xmlns:mhs="http://org/emedny/mhs/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header><wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="6BB387229F4FD6E3FC13753868206455">MIIDFjCCAn+gAwIBAgIBDzANBgkqhkiG9w0BAQUFADA2MQ8wDQYDVQQKEwZlTWVkTlkxIzAhBgNVBAsTGnJQcmQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDIxNjA1MDAwMFoXDTEzMDgyMDAzNTk1OVowYzEPMA0GA1UEChMGZU1lZE5ZMRQwEgYDVQQLEwtlTWVkTlktUFJPRDEPMA0GA1UECxMGZVBhY2VzMREwDwYDVQQLEwhlU2VydmVyczEWMBQGA1UEAxMNRFBNZWRzSGlzdG9yeTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqdOQyIej9kENyppOOeOPF5olvolfZz2GUG4eYEkJtBH0WBDahM5Pm3N7U52Sm+YYPXkPMe+NTOWXUvGOdrp3mMJlN/+A5N4oEM9WwXzDhdsIXufzW5s1zJOW1xKrWgb2/hHXAyNIciCrtsFVBZ8S6c1iibZecrmdkQyiNZsXntMCAwEAAaOCAQUwggEBMA4GA1UdDwEB/wQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwgY8GA1UdHwSBhzCBhDBNoEugSaRHMEUxDzANBgNVBAoTBmVNZWROWTEjMCEGA1UECxMaclByZCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwM6AxoC+GLWh0dHA6Ly93d3cuZW1lZG55Lm9yZy9lUGFjZXMvY2FjZXJ0cy9DUkwxLmNybDAdBgNVHQ4EFgQUs60iHpMc/Jz2F4lt/lHnLVtZco0wHwYDVR0jBBgwFoAUwbo3tXRFck0wN5g2DPS+/+xVHnQwDQYJKoZIhvcNAQEFBQADgYEAKzRgS2QNHW5f2R348N3+jRRbtlJdS/kM974rsnvoNHb2QatSLWxwa5dr7ASaDUXiED7jzB51HzbehyfE8afdq7OByuMN/J8yXK2B3Dv6y3F6uDHYP9H7JDGXoq2kdexpVD1oY4UEi5QOkdhtL8URJ355A3Fr/faIC8fGF4miq04=</wsse:BinarySecurityToken>
<xenc:EncryptedKey Id="EK-6BB387229F4FD6E3FC13753868206454" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<wsse:SecurityTokenReference>
<wsse:Reference URI="#6BB387229F4FD6E3FC13753868206455" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference></ds:KeyInfo>
<xenc:CipherData>
<xenc:CipherValue>e5nL8OsjXRBtVrkV6eb4W5KhgOas2UL3C26BmcAArBZNk+yBVQoCIRTBMXYomvLeHFB/oNO3RqXEd8NTrSTnC8ydH/BEf9vKSGqsyQzaEkk4oV93fgWtMgE4DErUS/8oBS2DcgvtJle1tpoNR7FNp7iBif0idmGyL6L2lBT9HmM=</xenc:CipherValue></xenc:CipherData>
<xenc:ReferenceList>
<xenc:DataReference URI="#ED-4"/></xenc:ReferenceList></xenc:EncryptedKey>
<wsse:UsernameToken wsu:Id="UsernameToken-3">
<wsse:Username>USERID</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">PWD</wsse:Password>
<wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">Vjjuy4+O3TwT7BmMACfLQA==</wsse:Nonce>
<wsu:Created>2013-08-01T19:53:40.446Z</wsu:Created></wsse:UsernameToken>
<wsse:BinarySecurityToken EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1" wsu:Id="X509-6BB387229F4FD6E3FC13753868202121">MIIE4zCCAmcwggHQoAMCAQICAQAwDQYJKoZIhvcNAQEFBQAwNjEPMA0GA1UEChMGZU1lZE5ZMSMwIQYDVQQLExpyUHJkIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wOTA1MTEwNDAwMDBaFw0yMTAyMTAwMzU5NTlaMDYxDzANBgNVBAoTBmVNZWROWTEjMCEGA1UECxMaclByZCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMT0hW0sdDEmMBxg9Ye7TsHERFsAWzw7td+rAjTng0NRWiEGDDBzMiJGHnyWMdt3lUywLjKH2RNYep0D4rQkULtCsnaQ0I2M/+AgoDsR3+RGV3xGwU5TbvBQ56mzZzkfLWRKg0medA9q8Ia7rXAvVlm6Uhy1KW3xsrskEu9sLFOpAgMBAAGjgYQwgYEwPwYJYIZIAYb4QgENBDITMEdlbmVyYXRlZCBieSB0aGUgU2VjdXJpdHkgU2VydmVyIGZvciB6L09TIChSQUNGKTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUwbo3tXRFck0wN5g2DPS+/+xVHnQwDQYJKoZIhvcNAQEFBQADgYEAET5poNE2QeZNUjQ4u9PzNBkY4AO+5pFxHHp4AnbU6XzTrClHcn2QJlUAo2b9ryVgC2L8R+h6tJA1/2EQIVmmsCSegulzcOScNyDL0sm67GRwmx28zQ22y/9F3nAKSSsQwWz89vnXKQQSrpWPHEuMNVt/9fRTdUcWDWMW6LX3B3IwggJ0MIIB3aADAgECAgIAoDANBgkqhkiG9w0BAQUFADA2MQ8wDQYDVQQKEwZlTWVkTlkxIzAhBgNVBAsTGnJQcmQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEzMDQyNTA0MDAwMFoXDTEzMTAyNzAzNTk1OVowYDEPMA0GA1UEChMGZU1lZE5ZMRQwEgYDVQQLEwtlTWVkTlktUFJPRDEPMA0GA1UECxMGZVBhY2VzMRUwEwYDVQQLEwxlUGFjZXMgQ2VydHMxDzANBgNVBAMTBkxNV0FSRDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAkylE6EOuNVakw/ud2s3Rx/DH7JtlzHOK9BEpKRvzeorKAF3QkY2ck2oNe6+lru815uWjDavrd9xvXd3r/Yb87SSkKpYXmdaBzPRZmr/uDr8UkM9C3DkPE47ENqTjDQssLlpo3PZWDdvqsUObeURbKU+A8hhpiPOhza7DzytTsaUCAwEAAaNnMGUwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBQEpxRjV1ZWlWPEmCM9oEqO7wQLKDAfBgNVHSMEGDAWgBTBuje1dEVyTTA3mDYM9L7/7FUedDANBgkqhkiG9w0BAQUFAAOBgQBUzaHqesbXbqclwHq9cRZPc/7FJp5udrzQ6nQgbXaBcuBKUql/v7C1/ZwkV/Rxi9BqGTMBDoKBaUpvyQ30drpCON9nQGfrQhMshpUxx6S/mfuLDazCjvhtdCxJE9uET4Fwi1bhifjHKNO1NnB8JMnm4avMMRnbi8Kr5+eoRD9mzA==</wsse:BinarySecurityToken>
<ds:Signature Id="SIG-2" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="mhs soapenv" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:CanonicalizationMethod>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI="#id-1">
<ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="mhs" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transform></ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>FchA3vEpfP7i3adziwVpYnrI/BQ=</ds:DigestValue></ds:Reference></ds:SignedInfo>
<ds:SignatureValue>ZnEgibHIj1B+Gk+m8THvgNownzH8eCfymugLIHM+EyZsPz+xyOAd+IR43LAo/LcuAVZK8lBrtFKc
DJO2zETYXv9gXnQP4Z8kAirkOtWuE6nPPwooSBlGXRr/j2zOp6ekdCoyqI7Hlhljh0NVaIbwzAsS
yfrsYGw0I0zJzfI3Hkc=</ds:SignatureValue><ds:KeyInfo Id="KI-6BB387229F4FD6E3FC13753868203372">
<wsse:SecurityTokenReference wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1" wsu:Id="STR-6BB387229F4FD6E3FC13753868203413" xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd">
<wsse:Reference URI="#X509-6BB387229F4FD6E3FC13753868202121" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1"/></wsse:SecurityTokenReference></ds:KeyInfo></ds:Signature></wsse:Security>
</soapenv:Header>
<soapenv:Body wsu:Id="id-1" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<xenc:EncryptedData Id="ED-4" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/><ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<wsse:SecurityTokenReference wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd">
<wsse:Reference URI="#EK-6BB387229F4FD6E3FC13753868206454"/></wsse:SecurityTokenReference></ds:KeyInfo>
<xenc:CipherData><xenc:CipherValue>IMyfgrFU0VZZV+buomWUGAmPr2TXGlNETpECX7jF5xrQcJAk6Ql/eGv70ttFaFulwyuNmtM8u+KT7CM0/xhmwyrB6X5iUYCjZp+aL7XAs+hOPHcd/lSZmAOyV2DBH7B/PopiDuE7hgmQQn0zhV4WommQbe3ss77mmdQQlQv8RhqvIg2xs4k70eB8QaYUdQ6sa6BxYPnc3SkxFXb24/3s7CZVPj8vecfLwiAVLhIk55rVR9eyYeGD97haM3YeuBRMA2xNNgItvsqK8m0ePxKNT/KrQlAeivRRLwfSY8+sIisdk9Q3ioXgkZ0quM+fjlHrH816swbeY9IVFBvoDA+jWqkjbriOezMHa5SJB/ubjxpS+UMld6EOP/71Btts6FGwUoJjygzbwCVYUIS9/rMCOvJf+q1gK8SbjTwTmiozoo3mIxb7cfGmN4/Y7B2zeFilKfDbPBPESIR7QW+c08Uyyr6P4C0rAJ6+NL5Lr8g+eEsVjCpFUtbzmupk2hfqsySnmWjPx3CfOBnaRrtlTYI3J3yK7Il4lQ4P3qvBT9vGNr8nnQ7ziS4OhTD6PTzmB1FDpv3Nb416xD5tIBVtAkhC3yDRqF9TAAmb8V+8ynxrkjgZOpmTp//PgrIMZmzLh2udttBSzAHTc4Waq1+baSimoRRwL/SxOOmRgjji2lp/yoSeMBIDDLoXRE67HSD1dtUdTab9kEu4Rqr1D/g1PXNZZA7qIXu1Gdg5zIN0kxRWWDERz/D8FtEFxCDb6VOlSkthBT3y/HD3EO67dtabqnKdSSCItcr9UuqrEs+B+SHujZv9DnsGFL6UAm2WMfqnGuvNk2tXYZAvtJCbcExmWm5olb2WdRiEyP0G6Tpnja+/VmMaJg1qVUwwuOcQRq0U1mZujkIX1Z1Rpbk3j/7g0Ck4Qn4jnAqaMqeLDu1WUBUZa41RuS55V9xhoVz7/zKXP9pqsf0Fv7bQ1LPspsV7pb5sWup+GzPvMJDG/LUDhEvFXGy7cEXvPypE+n88IY2i815xxNXKZgW3hoht3sESH8eqjCPoBJJ4CciDvzb9STjKBO3Cj6TcibLZU60LDDvMaJNXH2fN/VOOc4LY42tdgrvyZi9sipjOisp+r6qYg1uW5v+tAqA8hoY0UH8dD66sD6FHS02eAsMkwudAK7m9qmHfzU0BML1H9/rCF9hgUjsJet2wZgWs6ROulo2lT7qnFncOv+uRyN3yStRqsbSIk3WZAOAX8LKMpX8sgFvXWyqUDdSyJ4YJuB2G65G5Ijq75PbuQZZUaJMsWSQBDsbp+E4a7rZHigBEWc5WroktfptCuBwZvCbXC7v3VyzvlCswk5kBUCGfl0AgUjQ=</xenc:CipherValue></xenc:CipherData>
</xenc:EncryptedData>
</soapenv:Body>
</soapenv:Envelope
Below is the request which my custombinding generates. It fails at the Signature-Digest Value
<s:Envelope xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<ActivityId CorrelationId="2297e645-5077-443d-a7d2-d9af74ddb07e" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">00000000-0000-0000-2400-0080020000f7</ActivityId>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<o:BinarySecurityToken u:Id="uuid-63c0b13f-8368-4bc9-a493-b362c67ac14b-5" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">MIICdDCCAd2gAwIBAgICAKAwDQYJKoZIhvcNAQEFBQAwNjEPMA0GA1UEChMGZU1lZE5ZMSMwIQYDVQQLExpyUHJkIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0xMzA0MjUwNDAwMDBaFw0xMzEwMjcwMzU5NTlaMGAxDzANBgNVBAoTBmVNZWROWTEUMBIGA1UECxMLZU1lZE5ZLVBST0QxDzANBgNVBAsTBmVQYWNlczEVMBMGA1UECxMMZVBhY2VzIENlcnRzMQ8wDQYDVQQDEwZMTVdBUkQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJMpROhDrjVWpMP7ndrN0cfwx+ybZcxzivQRKSkb83qKygBd0JGNnJNqDXuvpa7vNeblow2r63fcb13d6/2G/O0kpCqWF5nWgcz0WZq/7g6/FJDPQtw5DxOOxDak4w0LLC5aaNz2Vg3b6rFDm3lEWylPgPIYaYjzoc2uw88rU7GlAgMBAAGjZzBlMA4GA1UdDwEB/wQEAwIE8DATBgNVHSUEDDAKBggrBgEFBQcDAjAdBgNVHQ4EFgQUBKcUY1dWVpVjxJgjPaBKju8ECygwHwYDVR0jBBgwFoAUwbo3tXRFck0wN5g2DPS+/+xVHnQwDQYJKoZIhvcNAQEFBQADgYEAVM2h6nrG126nJcB6vXEWT3P+xSaebna80Op0IG12gXLgSlKpf7+wtf2cJFf0cYvQahkzAQ6CgWlKb8kN9Ha6QjjfZ0Bn60ITLIaVMcekv5n7iw2swo74bXQsSRPbhE+BcItW4Yn4xyjTtTZwfCTJ5uGrzDEZ24vCq+fnqEQ/Zsw=</o:BinarySecurityToken>
<o:BinarySecurityToken u:Id="uuid-63c0b13f-8368-4bc9-a493-b362c67ac14b-4" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">MIIDFjCCAn+gAwIBAgIBDzANBgkqhkiG9w0BAQUFADA2MQ8wDQYDVQQKEwZlTWVkTlkxIzAhBgNVBAsTGnJQcmQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDIxNjA1MDAwMFoXDTEzMDgyMDAzNTk1OVowYzEPMA0GA1UEChMGZU1lZE5ZMRQwEgYDVQQLEwtlTWVkTlktUFJPRDEPMA0GA1UECxMGZVBhY2VzMREwDwYDVQQLEwhlU2VydmVyczEWMBQGA1UEAxMNRFBNZWRzSGlzdG9yeTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAqdOQyIej9kENyppOOeOPF5olvolfZz2GUG4eYEkJtBH0WBDahM5Pm3N7U52Sm+YYPXkPMe+NTOWXUvGOdrp3mMJlN/+A5N4oEM9WwXzDhdsIXufzW5s1zJOW1xKrWgb2/hHXAyNIciCrtsFVBZ8S6c1iibZecrmdkQyiNZsXntMCAwEAAaOCAQUwggEBMA4GA1UdDwEB/wQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwgY8GA1UdHwSBhzCBhDBNoEugSaRHMEUxDzANBgNVBAoTBmVNZWROWTEjMCEGA1UECxMaclByZCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxDTALBgNVBAMTBENSTDEwM6AxoC+GLWh0dHA6Ly93d3cuZW1lZG55Lm9yZy9lUGFjZXMvY2FjZXJ0cy9DUkwxLmNybDAdBgNVHQ4EFgQUs60iHpMc/Jz2F4lt/lHnLVtZco0wHwYDVR0jBBgwFoAUwbo3tXRFck0wN5g2DPS+/+xVHnQwDQYJKoZIhvcNAQEFBQADgYEAKzRgS2QNHW5f2R348N3+jRRbtlJdS/kM974rsnvoNHb2QatSLWxwa5dr7ASaDUXiED7jzB51HzbehyfE8afdq7OByuMN/J8yXK2B3Dv6y3F6uDHYP9H7JDGXoq2kdexpVD1oY4UEi5QOkdhtL8URJ355A3Fr/faIC8fGF4miq04=</o:BinarySecurityToken>
<o:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<o:Username>USERID</o:Username>
<o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">PWD</o:Password>
<o:Nonce>19sRmzQElHKqxL6ICMzpJf7NOU8=</o:Nonce>
<o:Created>2013-07-31T09:24:00.933Z</o:Created>
</o:UsernameToken>
<e:EncryptedKey Id="_0" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<o:SecurityTokenReference>
<o:Reference ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" URI="#uuid-63c0b13f-8368-4bc9-a493-b362c67ac14b-4" />
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>XQQjLvSY5VJ4BYkDxdsIUYYFRz+eleKaiU5bSFpUMblIm7ssKXOLJJsLBbNHREycIV8u5LR9ZixI7nI5BeacKYT+nlEikPREgUwEbvsGMb6LxkquUsIDhicpY5lKMhijbYtrE8O0Ee1TX3kT6hRb6QnvWZSGjnDhfLZvu3SO9cY=</e:CipherValue>
</e:CipherData>
<e:ReferenceList>
<e:DataReference URI="#_2" />
</e:ReferenceList>
</e:EncryptedKey>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="#_1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>l6kqP048t5INzJT3W8gxVSXplaE=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>gCwFapZ3D/vUXsvAShTQwNWJoA23ad54NRmUWXR7IBFbsr75HBdZUG5lO1Af+ncShzwJA2a6jJXJmw/1gKswyAP9QuZsa9D+6fGh8jwcVqjm5v/Sh9rgQxWjL6U1kkovP0IAqEjafRu6YgmauFVCHUrJ2QfIN96WYTPnYm9Puvs=</SignatureValue>
<KeyInfo>
<o:SecurityTokenReference>
<o:Reference ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" URI="#uuid-63c0b13f-8368-4bc9-a493-b362c67ac14b-5" />
</o:SecurityTokenReference>
</KeyInfo>
</Signature>
</o:Security>
</s:Header>
<s:Body u:Id="_1" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<e:EncryptedData Id="_2" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<e:CipherData>
<e:CipherValue>pkVTvAXkNSAw49UQaR8xjz3N9BLM3fS2k9j9JKUwLfg1hynpnDZMme5P4xwfDjnhYtx/ftIc3lnN9fDnECeMG+V8dPPD/nRqCsaExYbIgyY9KBmCBRx0OgrbJQEYX6Jq5n24sWDZb9yk7JEKmh3sZOnzWm6k/GaTv8UYzY0/rEBmS4m1W7kP/asCw11QzM2daolIerQ0OOYSecnk/NjmiEmK21dq4yIBVbUGn5UPllD5fIHtL5PQk8kcp9S8snfaAkKQhSQqokv8s0R9uLIKBYlmX4r+uFJLKXFIKdDZLb39U2MOWacOmQQ/KlEuBWZibhxvRfUnBote74dI7rfYjKCHpJZ9LoQN+/3R5CNfsJmlyEKGvp7pCZfPABtkjTQgKBJkL0zj8xA0149g1m0mSPN1AfUeRlFHw/T90qknYwQ5JTX4vVP1HKStieFf7raMocT4poNkm3Anqik+IDFPNNsH85TnVJgCOeemnM8ZoWRTsnAIhmTSEiRaDE+bAi2+vNJHBxIwpoR65rgk1N8DcEPfQkWAPgiy76lyXyTk/kPqZgepnZdghcdZ6u7tl1eLv0IscJVXJpQtFHgWur/AIBaUEUyfiMSPVIWfJdd/W4E3/BCFEdqfJwOqmxULS+w2GQMvUHrQJ9S3+8o2ajBBCUqxjYBKgcoDrdvopDaPzaBALQJUqECUz3grCCTiqiEzGyWiGjqwHVl9JQTNJesfxOATlEDjRu8lPdeM/c0OlM8JOdG8CiTx1x0TuUTGGsGXmfr25tanwoA5iEEms6oP0sUhB2o65BvuGPUSdJRmlfM2p9kEohShUDYR/hHnvFhKPd/dnPHP/q1kIiAybgWUaXQ9BsQajKEt1ZsW+zJ2T0vqiSrZkJOJSirSFOOsz4vFzOtEM/lMy80n6ltF4GHPxJHNK9zv14CHoTGUCK18+uvFCcA2DKgaPnJBXmBwpPjAW2jAVIFE7RgA3kGJomPygyV88A8TkkPs+7h2v+mLpj2B+9ev62g9Lws+At74b0DFU5D70SFazVNnRHGXPHHSr0L2XRDlHg6A9ZW884cGmRftGyPuWZotCfaBfCI4gWjak0W2Zu3TSdU1HHxWKW8jOvsSr8pdMjnzMAsPRAyjlPfE69eODRh1J+FAcJg+jVpAvpwWfpo81GRn9F7RcpkfySh7hKufNMsKOTZg5ciXl+N4dBCJ186Q5eqCAItEqwkxwGiXWB3W/QQGdinCdwz8gA==</e:CipherValue>
</e:CipherData>
</e:EncryptedData>
</s:Body>
</s:Envelope>
Messages look very similar, a little disappointing that the server rejects WCF. You should be prepared that this can take some time to troubleshoot. I would try debug this with the following different approaches:
Based on the error message I assume the challenge is in the digest calculation. See how the soap UI has this element "". This element is an instruction to the signature signer/validator. Maybe the server hard codes this value into its signer in some way so the fact that WCF does not have it affects the digest. WCF cannot be configured to have this (usually it is not a problem not to have it). See if there is any configuration in SOAPUI where you can also not use it and see if it still works.
replace SignBeforeEncrypt with EncryptBeforeSign
setup a WCF service for the same WCF client and see if it works (though it probably will, so this is a long shot).
Try to contact the service from clients in other platforms, see how the server reacts.
Try to remove complexity from the service - e.g. remove the encryption and just use signature. See if that works. This can help pinpoint the problem.
The brute force way would be to find the service code that calculate the xml canonicalization and the digest and debug it viz-a-viz to the .Net code. But at that stage you would probably seek to bypass the problem in some other way.

WCF Server & TIBCO Client - Decrypt Digital Signing Web Service Soap Message

I have created the WCF web service which uses messageprotectionorder as "SignBeforeEncryptAndEncryptSignature". I have also developed the .net client to consume this web service. I am able to successfully able to connect and receive response from my WCF web service. But, my client is trying to consume WCF web service from TIBCO java client where TIBCO does not have concept of "MessageProtectionOrder". The sample signed soap request is as follows
<MessageLogTraceRecord>
<HttpRequest xmlns="http://schemas.microsoft.com/2004/06/ServiceModel/Management/MessageTrace">
<Method>POST</Method>
<QueryString></QueryString>
<WebHeaders>
<Connection>Keep-Alive</Connection>
<Content-Length>7895</Content-Length>
<Content-Type>text/xml; charset=utf-8</Content-Type>
<Expect>100-continue</Expect>
<Host>comp118</Host>
<SOAPAction>"https://XXX.XXX.XX.XX/APISIGN/IAPI/EnquireTransaction"</SOAPAction>
</WebHeaders>
</HttpRequest>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<VsDebuggerCausalityData xmlns="http://schemas.microsoft.com/vstudio/diagnostics/servicemodelsink">uIDPowY5/i7l8ZdOl4B6x1uzACIAAAAA1re1c/La5kK2h1tnd2ijrMveD45HGZtHvanrpR7sXroACQAA</VsDebuggerCausalityData>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="uuid-34291a98-4feb-43eb-8f91-f182297d086b-21">
<u:Created>2013-06-17T07:16:53.671Z</u:Created>
<u:Expires>2013-06-17T07:21:53.671Z</u:Expires>
</u:Timestamp>
<o:BinarySecurityToken>
<!-- Removed-->
</o:BinarySecurityToken>
<e:EncryptedKey Id="_0" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns="http://www.w3.org/2000/09/xmldsig#"></DigestMethod>
</e:EncryptionMethod>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<o:SecurityTokenReference>
<o:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509SubjectKeyIdentifier" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">wc18MSP1B9qEKFLe8ji4H5tlIHQ=</o:KeyIdentifier>
</o:SecurityTokenReference>
</KeyInfo>
<e:CipherData>
<e:CipherValue>aQ4FENLuKcZvQGhiNPINr0c8BmTbCaLmXACs3ZFcsnRFVmGRMWUEIXCWCivJCxOIc9kYeftMxGADr6EbAJ6A3Bi/EcgLYnAulxZUcwMQrYwBTsbjFIOzJJBo9Ru5cz3RX+E/MgsroN9VFcOCzFfxlGiOi0ZmEqgfedzDlWBrRtUddA/mE9t6ZZBxsRDq1zzYu0bhY3oRtGe/RI0iYhZuAeS/UAk7g1PnIbr39lLI1XcYZG2gLGFlaxYGT76n+Zmph2tYW1usBnvHVXOpLc3Q8DN9CJ7lZJ8f+euTqIuDSApRLCHciauonQ6rPguPpSQQhLYf1CroqIeMr/nyStR0jQ==</e:CipherValue>
</e:CipherData>
<e:ReferenceList>
<e:DataReference URI="#_2"></e:DataReference>
<e:DataReference URI="#_3"></e:DataReference>
</e:ReferenceList>
</e:EncryptedKey>
<e:EncryptedData Id="_3" Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"></e:EncryptionMethod>
<e:CipherData>
<e:CipherValue>+VJi2EwCmK4ovTULaBd+.....</e:CipherValue>
</e:CipherData>
</e:EncryptedData>
</o:Security>
<To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">https://comp118/API_WCF_UAT/API.svc</To>
<Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">https://XXX.XXX.XX.XX/APISIGN/IAPI/EnquireTransaction</Action>
</s:Header>
<s:Body u:Id="_1">
<e:EncryptedData Id="_2" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
<e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"></e:EncryptionMethod>
<e:CipherData>
<e:CipherValue>r0ktDG7sauaw7R2PEowODZFaC7Y5Gj3WWuctwOwiewZ.....</e:CipherValue>
</e:CipherData>
</e:EncryptedData>
</s:Body>
</s:Envelope>
</MessageLogTraceRecord>
I would like to understand what values are signed and encrypted in the following tags
EncryptedKey tag -> CipherData -> CipherValue what value is
encrypted here.
For Signature encryption, AES256/CBC algorithm is
used.
What is the Key and IV value for AES algorithm? 3) Instead of
"rsa-oaep encryption method" in request message, algorithm "rsa-1_5"
can be used? If yes, where to specify this?
Kindly someone reply at the earliest.
Thanking You,
Bhavin Shah.

Mutual authentication with message protection in WCF

I'm trying to communicate with a web service that implements WS-Security with SOAP 1.1 and requires the client to sign both the body and the timestamp in the request. On the client-side, I'm using WCF and have no control over the service. The proxy interface has its ProtectionLevel.Sign-attributes where they should be.
The client is also required to negotiate the service certificate (TLS/SSL) and to validate the service signing certificate according to some custom rules.
So far, my best attempt to get a connection is with this binding:
var b = new BasicHttpBinding(BasicHttpSecurityMode.TransportWithMessageCredential);
b.Security.Message.ClientCredentialType = BasicHttpMessageCredentialType.Certificate;
b.Security.Transport.ClientCredentialType = HttpClientCredentialType.Certificate;
b.Security.Message.AlgorithmSuite = SecurityAlgorithmSuite.Basic256Sha256;
b.TextEncoding = new UTF8Encoding();
It results in the request below, where only the timestamp signed - not the body. The service responds that the signature is invalid.
I've tried using CustomBinding and the SecurityBindingElement.CreateCertificateOverTransportBindingElement-function to create a security element, but it yielded the same results.
Using the SecurityBindingElement.CreateMutualCertificateBindingElement-function, both the body and timestamp were signed, but now WCF required me to specify the service certificate, which should be negotiated during the TLS/SSL handshake.
The request:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="_0">
<u:Created>2013-03-11T15:41:19.744Z</u:Created>
<u:Expires>2013-03-11T15:46:19.744Z</u:Expires>
</u:Timestamp>
<o:BinarySecurityToken u:Id="uuid-75db13c1-3c82-4e31-8dbf-75af257850ac-1" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">..REMOVED..</o:BinarySecurityToken>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<Reference URI="#_0">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>z2Q9Bb/I1Mo7DJFZ3uXA42JSH0AJJguvIfnYMxlKBAg=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>FgvpaSy+Zg3PHul6q2//Wc1lp+z+tuPCFKcLFp5edYvApb8yDwVDhuRuYPfn5K2TdGpQQekV095WZofIpIUV5aA+VBzf0/qVMP9hvOCqloyjJF3FWiMC829yFE8ePrYT3c1VXWSZi1172E7iRTNetz5ZmRYKAlcy6t7MaIq++q6MlM0gkK/w/W5qWVLIvopf2MQc+V+PBBmx7nWKGzF4SxIgdD4JeGOUzIND68OozBYD7jrvHLeYUjUzmBCkrLKm2bXDDksrV9rJHZdoizKrC7C59uRPh+gG5pl2pMLYtimFnwot3L4lvysBG0apAftxXat091c5a4JtKAvuDiWOFQ==</SignatureValue>
<KeyInfo>
<o:SecurityTokenReference>
<o:Reference ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" URI="#uuid-75db13c1-3c82-4e31-8dbf-75af257850ac-1"/>
</o:SecurityTokenReference>
</KeyInfo>
</Signature>
</o:Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Request xmlns="http://theurltotheservice">
<Value>123456789</Value>
</Request>
</s:Body>

MustUnderstand attribute in WCF response causes error for Java/Axis client

We have developed a WCF4 service with usernameToken authentication that is being consumed by a Java/Axis client (that we have no control over).
I can see that the body of the request coming in looks like this...
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wss:Security xmlns:wss="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wss:UsernameToken>
<wss:Username>username</wss:Username>
<wss:Password>password</wss:Password>
</wss:UsernameToken>
</wss:Security>
</soapenv:Header>
<soapenv:Body>
{snipped}
</soapenv:Body>
</soapenv:Envelope>
and the response we are returning looks like this...
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Header>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="_0">
<u:Created>2012-05-02T01:23:12.711Z</u:Created>
<u:Expires>2012-05-02T01:28:12.711Z</u:Expires>
</u:Timestamp>
</o:Security>
</s:Header>
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
{snipped}
</s:Body>
</s:Envelope>
The problem is the s:mustUnderstand="1" attribute in the response. This is causing a "Must Understand check failed" error in the Java/Axis client.
Does anyone know how to configure WCF to remove this s:mustUnderstand attribute or at least set it to "0" instead of "1"?
The solution we came up with to overcome this interop problem was to change to a custom binding and specify the includeTimestamp="false" attribute. By doing this the timestamps (Created and Expired) were not added into the response and therefore the whole security header dissapeared - including the mustUnderstand attribute which was causing all the problems.
<customBinding>
<binding name="customBindingConfig">
<security authenticationMode="UserNameOverTransport" includeTimestamp="false" />
<textMessageEncoding messageVersion="Soap11" />
<httpTransport />
</binding>
</customBinding>
So the response now simply looks like this...
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
{snipped}
</s:Body>
</s:Envelope>

Adding WS-Security Credentials to SOAP headers using WCF

I am trying to communicate with a Java web service that I have no control over, and I'm trying to create a binding that'll work.
Timestamp is not allowed in the header, so in order to use the includeTimestamp="false" attribute, I have to use a <customBinding>.
They are using MTOM, so I have to use the <mtomMessagingEncoding> element.
Here is my <bindings> element:
<bindings>
<customBinding >
<binding name="MyBindingName" >
<mtomMessageEncoding />
<transactionFlow />
<security authenticationMode="UserNameOverTransport"
includeTimestamp="false">
</security>
</binding>
</customBinding>
</bindings>
The SOAP web service requires that the message header be in the following format:
<soap:Envelope ... >
<soap:Header ... >
<wsse:UsernameToken>
<wsse:Username>doo</wsse:Username>
<wsse:Password Type="wsse:PasswordText">fuss</wsse:Password>
</...>
</...>
</...>
The closest I have come is:
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
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">
<s:Header>
<a:Action s:mustUnderstand="1"></a:Action>
<a:MessageID>urn:uuid:a368e205-a14d-4955-bf75-049cdd3a78c0</a:MessageID>
<a:ReplyTo>
<a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address>
</a:ReplyTo>
<a:To s:mustUnderstand="1">https://blablabla</a:To>
<o:Security s:mustUnderstand="1"
xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<o:UsernameToken u:Id="uuid-0f1e399b-31a8-4e00-a57f-277c21e94879-1">
<o:Username><!-- Removed--></o:Username>
<o:Password><!-- Removed--></o:Password>
</o:UsernameToken>
</o:Security>
</s:Header>
I am sure I'm missing something trivial and stupid here, but for the life of me i can't figure out what it might be.
You must also configure message version because by default it uses WS-Addressing:
<bindings>
<customBinding >
<binding name="MyBindingName" >
<mtomMessageEncoding messageVersion="Soap11" /> <!-- or Soap12 -->
<security authenticationMode="UserNameOverTransport"
includeTimestamp="false">
</security>
</binding>
</customBinding>
</bindings>
TransactionFlow element is not needed at all.
Btw. message you showed is not valid usage of WS-Security token because it must be inside Security element so if it is really what Java service expects it doesn't conform to WS-Security specification and you will have to use custom message header instead.