We were researching for a mobile client to connect to a wcf service running at one of our servers. The requirement is that transport is secured by using HTTPS protocol.

The first problem was creating a client side proxy. Since the SvcUtil doesn’t work for the CF we had to look for an alternative. After some googling we found the netCFSvcUtil which is basically the same as the svcutil, but it generates a proxy specifically for CF. You can find it as part of the Power Toys for .NET Compact Framework 3.5. For more on this you can read this excellent blog post by Andrew Arnott

When you get this generated client proxy there is another problem. It expects that you are using HTTP. Since we need HTTPS that’s a problem. Thanks to Damir Dobric we found how to make the proxy use https instead of http.

System.ServiceModel.Channels.CustomBinding binding = new
    System.ServiceModel.Channels.CustomBinding();
binding.Elements.Add(new System.ServiceModel.Channels.TextMessageEncodingBindingElement
   (System.ServiceModel.Channels.MessageVersion.Soap11, System.Text.Encoding.UTF8));
System.ServiceModel.Channels.HttpsTransportBindingElement https =
   new System.ServiceModel.Channels.HttpsTransportBindingElement(); 

https.RequireClientCertificate = false;
binding.Elements.Add(https);

This way your client proxy is now HTTPS enabled.

Another problem we had was that the disco file was downloaded from the “wrong” location. We have a wildcard certificate in place for our HTTPS like *.domain.com. We were accessing the service using https://laptop1.domain.com/wcf/service.svc. Although this url works fine when we browsed to it, there was an issue when we tried to generate a client proxy. It seemed that both svcutil as netcfsvcutil were trying to download the DISCO file from https://laptop1/wcf/service.svc?Disco. When we browsed to this link it worked just fine. The problem is in the url and the wildcard certificate. Since the disco url didn’t include the domain.com part in its url the utils were not able to establish a trust relationship over ssl with the web server. This is perfectly normal since it does not correspond with our wildcard certificate.

The solution is to update the https binding in IIS by giving it a host header. Now this is something you can’t do in the IIS control panel. There are 2 ways of doing this: Using scripting or using the metabase explorer that can be found in the IIS 6.0 resource toolkithttp://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/993a8a36-5761-448f-889e-9ae58d072c09.mspx?mfr=true

A last advice don’t fall into the same trap by thinking that a wshttpbinding is required to do HTTPS, it’s perfectly possible by using a basichttpbinding where the security mode is set to transport.