Thursday, December 4, 2008

WCF & the IIS Require secure channel (ssl) setting

After turning on "Require secure channel (SSL)" on the IIS 6.0 Directory security tab (secure communications dialog), I lost several hours today trying to figure out why my WCF services stopped working and started giving me this error:
[System.ServiceModel.ServiceActivationException] = {"The requested service, '' could not be activated. See the server's diagnostic trace logs for more information."}

I tried a variety of things, but when I finally broke down and ran the diagnostic trace I got the following:
The service '/DoIt/MyService.svc' cannot be activated due to an exception during compilation. The exception message is: Could not find a base address that matches scheme http for the endpoint with binding MetadataExchangeHttpBinding. Registered base address schemes are [https]..

All my services use https to send data; however, my metadata exchange binding, which I intended to remove/comment out later, use http. When I changed all my metadata exchanged end points to use mexHttpsBinding instead of mexHttpBinding and all my behaviors to use <servicemetadata httpsgetenabled="true"> instead of <servicemetadata httpgetenabled="true">, everything started working again.

I figured that the http endpoints would just be ignored or if accessed permissioned denied because all addresses must use a secure channel (https). It appears that I was wrong and that it causes a compilation error.


Jeff said...

Thanks you saved me a bunch of time. After I made the same changes in my project I was able to get past the issues I was having.

Jose JoaquĆ­n � said...


Simple solution that worked for me.

Thank you Dave!

Best regards. Jose J.

streak said...


I am Also Got same problem,when i deploy Silverlight WCF Service application,How can i Resolve it,
Can u Give Brief Explanation and Sample Coding

Error Is:

system.servicemodel.serviceactivationexception the requested wcf service could not be activated

Unknown said...

Thanks Dave for the quick reply. Yes we are storing local time and not UTC time.