I was battling with the WCF services at work the other day, trying to get a our services to function on our test server that was using a multi-domain certificate. I could not get the multi domain certificate to work with message security.
It kept on giving the following error message.
Identity check failed for outgoing message. The expected DNS identity of the remote endpoint was ‘domain1’ but the remote endpoint provided DNS claim ‘domain2’. If this is a legitimate remote endpoint, you can fix the problem by explicitly specifying DNS identity.
For privacy and security reasons i have replaced the domain names in the message.
Now “domain1” and “domain2” was both actual domain names listed in the multi domain certificate . My client endpoint was using “domain1” but it was saying that the DNS returned address containing “domain2”. I could not understand where it was getting “domain2” from as it was not listed anywhere in my configuration.
<endpoint name="IApplicationDao_netTcp" binding="netTcpBinding" bindingConfiguration="Company_Generic_netTcpBinding" address="net.tcp://domain1:9500" contract="Company.Contracts.DataAccess.ServiceContracts.IApplicationsDao"/>
After many hours of struggling to figure out why i found that it was a known Microsoft WCF bug. When using a multi-domain certificate the WCF code only matches the incoming request with the last domain entry in the certificate. if the incoming request address does not have a domain matching the last entry of the certificate it will always fail validation. The work around is to supply the dns identity that wcf will find in the last entry of the certificate as in the example below.
<endpoint name="IApplicationDao_netTcp" binding="netTcpBinding" bindingConfiguration="Company_Generic_netTcpBinding" address="net.tcp://domain1:9500" contract="Company.Contracts.DataAccess.ServiceContracts.IApplicationsDao"> <identity> <dns value="Domain2"/> </identity> </endpoint>
For the record we were using Visual Studio 2012 Pro with .net 4.5 on Windows 7. I was able reproduce this on Windows Server 2008 R2 and on Windows server 2012.
The official bug report can be found here.
and here is a related link.
I hope i save someone a few hours by posting this and linking the related articles.