How can I use an ssl wildcard certificate to mutually authenticate multiple WCF servers through X509?
I have two WCF servers, both on mydomain.com domain (dummy example and IP below!), Named server1 and server2 respectively.
They are both accessible via their public IPs (foo.1 and 2), but also from the private LAN they are on (i.e. 192.168.0.1 and 192.168.0.2)
I have a wildcard ssl certificate for * .mydomain.com. It is installed correctly in the respective stores (e.g. Personal for encryption and trusted clients for authentication).
I would like both of my servers to connect to each other at their local network addresses using my wildcard certificate for authentication purposes.
I have updated the C: \ Windows \ System32 \ drivers \ etc \ hosts file to look like this:
192.168.0.1 Server1.mydomain.com
192.186.0.2 Server2.mydomain.com
These are not the IPs I get if I resolve to Server1.mydomain.com (better to get foo.1 - 2)
I also edited the connection specific DNS suffix for local IPV4 interfaces for "mydomain.com"
My certificate is mentioned in my Server.config files (I removed all non-authentication parts)
<behavior name="ServerToServerBehavior" >
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="PeerOrChainTrust" revocationMode="Online"/>
</clientCertificate>
<serviceCertificate x509FindType="FindByThumbprint" findValue="13a41b3456e431131cd461de"/>
</serviceCredentials>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="myServerAsClientBehaviorConfiguration">
<clientCredentials>
<clientCertificate x509FindType="FindByThumbprint" findValue="13a41b3456e431131cd461de" storeLocation="LocalMachine"/>
<serviceCertificate>
<authentication certificateValidationMode="PeerOrChainTrust" revocationMode="Online" trustedStoreLocation="LocalMachine"/>
</serviceCertificate>
</clientCredentials>
</behavior>
</endpointBehaviors>
This works fine on my own development machine with locally generated X509 certificates, but in my production environment, here's what I get:
Server.Connect: Failed to connect to server Server2: System.ServiceModel.Security.MessageSecurityException: Failed to validate message id. The expected DNS ID of the remote endpoint was 'server2.mydomain.com', but the remote endpoint submitted a DNS claim to 'Mydomain.com'. If this is a legitimate remote endpoint, you can resolve the issue by explicitly specifying the DNS ID 'mydomain.com' as the Identity EndpointAddress property when creating the proxy channel.
I tried to get the server to respond to Server2.mydomain.com and not just mydomain.com with no success. Any hint on how to do this?
I've also tried the solution suggested in the error message, but that doesn't seem to have any effect (other users seem to have the same problem and I haven't found a solution yet). Any idea on how to fix this?
Edit: I checked with the certificate provider that I can actually use it for X509 authentication.
source to share
I eventually figured out why my Identity field is being ignored.
My endpoint was built like this:
DistantServer = new ServiceReferenceServerToServer.ServerToServerClient("myServerBinding", "net.tcp://server.mydomain.com/Server");
when the uri parameter is provided, the DNS id field (defined in app.config) is also overridden (even if it's empty, which happens when we use a string instead of a real URI object).
the solution is to install it programmatically using the following code:
System.ServiceModel.EndpointAddress uri = new System.ServiceModel.EndpointAddress(new Uri("net.tcp://server.mydomain.com/Server"),new System.ServiceModel.DnsEndpointIdentity("mydomain.com"),new System.ServiceModel.Channels.AddressHeader[0]);
DistantServer = new ServiceReferenceServerToServer.ServerToServerClient("myServerBinding", uri );
source to share
I think the DNS override error says it will be specified on the client side and not on the server, so you don't open anything while making this change, except that your client can successfully connect to any server in your domain (if he listened). The error you are seeing does not look like the security equivalent of the hostname mismatch message on the certificate. I got message protection to work with wildcard certificates after multiple validations, but you might have to do some kind of special validation as your certificate probably doesn't have a specified use of client authentication.
For what reason are you not using transport security? MUCH is easier to work with if you don't have Layer7 intermediate routing ...
source to share