0

This should be a snap for anyone who's done it before...

I'm trying to set up a self-hosted WCF service using NetTcpBinding. I got a trial SSL certificate from Thawte and successfully installed that in my IIS store, and I think I've got it correctly set up in the service - at least it doesn't exception out on me!

Now, I'm trying to connect the client (this is still all on my dev machine), and it's giving me an error, "Message = "The X.509 certificate CN=ssl.mydomain.com, OU=For Test Purposes Only. No assurances., OU=IT, O=My Company, L=My Town, S=None, C=IL chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider."

Ooookeeeey... now what?

Client code (I want to do this in code, not app.config):

var baseAddress = "localhost";
var factory = new DuplexChannelFactory<IMyWCFService>(new InstanceContext(SiteServer.Instance));
factory.Endpoint.Address = new EndpointAddress("net.tcp://{0}:8000/".Fmt(baseAddress));
var binding = new NetTcpBinding(SecurityMode.Message);
binding.Security.Message.ClientCredentialType = MessageCredentialType.UserName;
factory.Endpoint.Binding = binding;
var u = factory.Credentials.UserName;
u.UserName = userName;
u.Password = password;
return factory.CreateChannel()

Added Bounty I've just got myself a new trial certificate from Thawte, installed it with the "issued to" set to mydomain.com, and I'm still getting the error above. I'm a newbie to web security, so I'll need detailed instructions how to get a client to connect to my website and accepting the security certificate. (BTW, what does "No assurances" mean?)

Shaul Behr
  • 36,951
  • 69
  • 249
  • 387
  • Can you confirm that the X.509 cert details in the error message correspond to the service SSL certificate you have described installing? Which line of the code throws the exception? What is the exception stack trace? – Chris Dickson Jan 02 '11 at 19:04

4 Answers4

3

If the certificate is for ssl.mydomain.com you need to acces the server at that adress. It seems like you are trying to acces it through localhost, which obvisouly is not the same.

Richard L
  • 1,211
  • 7
  • 10
  • +1 Thanks, I didn't know that! So how should I do this in my test environment, in such a way that when I'm testing it runs on localhost, and when I'm running live it uses the mydomain.com certificate? – Shaul Behr Jan 02 '11 at 19:10
  • I don't think this suggested answer explains the exception you are seeing, which concerns an attempt to validate the trust chain associated with the certificate detailed in the exception. – Chris Dickson Jan 02 '11 at 19:15
  • @Chris of course it could be something more that is not correct. I havent tried using a "real" ssl certificate in development enviroment. But using self signed certs my most common error is that I try to access it with the wrong name. – Richard L Jan 02 '11 at 19:29
  • I've added a bounty; if you could help me out some more with this I'd really appreciate it... – Shaul Behr Feb 20 '11 at 13:18
3

The problem seems to be that the server certificate you have installed on your server is not trusted by the client.

For it to be trusted the root CA certificate of the server certificate needs to be in the "Trusted Root Certification Authorities" store of the user running the client. If you get a "production" level server certificate from Thawte or some other similar CA it will already be trusted by most machines in the world.

However, judging by the error message (where the subject distinguished name of the certificate contains "OU=For Test Purposes Only. No assurances.") your certificate is a test certificate and you therefore need to add the CA certificate to your "Trusted Root Certification Authorities" store manually. The root certificate can usually be downloaded from the CA's (Thawte in your case) website.

Yhrn
  • 1,063
  • 7
  • 16
  • Here's a way to install the SSL certificate programatically for your self-hosted WCF service: http://stackoverflow.com/questions/3140526/wcf-https-vs-http/5278171#5278171 – Mike Atlas Mar 11 '11 at 21:03
1

The problem is the issuer of your certificate is not trusted.

WCF will try to verify the chain of certificates. One solution is to make sure the certificate used to issue the one you have is stored in the trusted issuers store of the server.

You could also add a custom certificate policy to bypass validation on your development env (as explained here)

You could also put your certificate in the 'Trusted People' stored and set the certificateValidationMode to ChainOrPeerTrust. This will try to validate the complete chain unless you put the certificate into the 'Trusted People' store. This would allow you to leave the configuration and code untouched for the deployment to production env. You will simply put your certificate in the 'Trusted People' store in your development env.

Johann Blais
  • 9,389
  • 6
  • 45
  • 65
  • Thanks for the info. I put my certificate in the "Trusted People" store of my server, but I don't understand how a client certificate works. The client app could be installed anywhere - that's the whole point! How do I know what certificates the client does or doesn't have installed? The client is, in effect, anonymous - but I want the communication to happen over https so nobody else can listen in. How do I do that? – Shaul Behr Feb 21 '11 at 09:14
  • Is it possible that it's not working because it's a "trial" certificate? If so, what's the point of having a trial certificate, if you can't test using it? – Shaul Behr Feb 21 '11 at 09:53
0

in .net core 2.0 we have to do this from nuget package manager search for System.ServiceMode you can use System.ServiceModel.primitives.

updated as of april 2018

kishore tvk
  • 31
  • 4