WCF service over https/SSL, svcutil, and a "localhost" trusted certificate


  • I have recently modified my WCF service from http to https. On our production server, which has a wildcard https certificate, this process has gone relatively smoothly.


    But I need to replicate this on my dev machine, and preferably without purchasing an SSL certificate for dev. I've used makecert to create certificates, following instructions from Michele Bustamante's article on the website, and also looked at the following books:

    * WCF Step by Step, chapter 4 + 5

    * Learning WCF, appendix A (certificate setup)


    The common problem that I'm seeing is this:


    I can create a trusted certificate for localhost (using the advice in the materials mentioned above) and that certificate will work. However, when I call my WCF service (eg. http://localhost/MyWCFService/Service.svc) from a browser, the page it returns doesn't display localhost, it displays the internal domain, something like: http://mymachine.ktc.nat/MyWCFService/Service.svc?wsdl.


    If I try and click on that link, the browser shows a certificate-not-trusted error (because it's no longer seeing it as localhost.)


    Where this becomes an issue is when I try and call the svcutil utility to generate my proxy. svcutil fails for the same reason: localhost was the originally submitted input, but svcutil calls based on what is returned, which is mydomain.ktc.nat--not the trusted certificate name.



    a) Is there a way to override the domain value that is returned to be localhost? (On our production machine, this value reflected the internal URL until I set the host header to the external URL, and then it displayed the host header value for its domain.) I get the impression that a certificate named localhost could never work successfully with svcutil for generating the proxy.


    b) I've tried creating a certificate for the machine name (mymachine) or the domain name (mymachine.ktc.nat) using makecert, but the certificates I created that way, while I could add them to the Certificates snap-in without any errors, caused IIS to stop serving up anything at all.


    Thanks for any suggestions on resolving this.

    Wednesday, June 25, 2008 12:33 AM


  • I have found the resolution to my question b) above: I am now able to generate a working trusted certificate for my dev machine's domain name (mymachine.ktc.nat in the above example).


    Thanks to this article ( for the resolution:


    The missing information that a lot of the information I've read doesn't seem to mention (perhaps because they are assuming I am working on a network where IT is providing a certification authority?) is that I needed to create 2 certificates: one to function as my root authority, and THEN the other to be the certificate used for the SSL, which references the root authority certificate.


    I created a root authority certificate using makecert (the article linked above provides this snippet):


    makecert -sv SignRoot.pvk -cy authority -r signroot.cer -a sha1 -n "CN=Dev Certification Authority" -ss my -sr localmachine


    Using the certificates snap-in I moved this root authority certificate into the Trusted Root Certification Authorities folder. I then created the SSL certificate using makecert, now referencing the root authority certificate (again, quoting the snippet from the article linked above, except that I switched the CN value from "localhost" to the machine name with WCF returns when its Service.svc service is called. In my case, that would be "mymachine.ktc.nat":


    makecert -iv SignRoot.pvk -ic signroot.cer -cy end -pe -n CN="mymachine.ktc.nat" -eku -ss my -sr localmachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12


    Both the above linked article, and the WCF Step By Step Chapter 4 recommend that the NEXT step is to set the SSL "thumbprint" from your newly generated certificate using the httpcfg command, which I did. (httpcfg is part of the Windows Server SDK, which I downloaded and installed from here: (


    Finally, I added that certificate to my Default Web Site from Properties>Directory Security, which is covered in detail in lots of the above documentation.


    The result: I can now call the Service from the https port, something like: https://mymachine.ktc.nat:8082/MyWCFSite/Service.svc and this returns the same domain name value of mymachine.ktc.nat. Therefore, svcutil works fine with it.


    Final comment: this information should be useful for anyone google-ing or LiveSearch-ing on the following svcutil error message: "Could not establish trust relationship for the SSL/TLS secure channel"

    Wednesday, June 25, 2008 5:14 PM