Why is it so much harder to enable SSL (Transport security) over net.tcp than HTTP?

Question

Implementing a web service that uses Transport-level security with WCF over HTTP is pretty easy: Enable SSL for my WCF service

Implementing a web service that uses Transport-level security with WCF over net.tcp is pretty hard: WCF with netTcpBinding and Certificate transport security

... and the net.tcp solution usually involves something like this on both the server side and the client side:

 <serviceCertificate
       findValue="MyServiceCertificate"
       storeLocation="LocalMachine"
       storeName="My"
       x509FindType="FindBySubjectName" />

In the HTTP case, you don't need to even mention a certificate on either the client or the server. In the NET.TCP case, you have to store, locate, and specify a certificate on both the client and the server in most of the sources I've read.

What is the thing doing the magic that makes you not have to worry about the certificates in HTTP mode? And, why is this magic not available to you when using net.tcp?

Answer 1

Because when using WCF over HTTPS; IIS manages the negotiation with the certificates (Just like plain SSL). Since there is no IIS server with that built in for TCP, you have to do it yourself. You are still doing stuff with certificates + WCF for HTTPS, but the configuration is done at IIS.

EDIT:

For client side, you still have another piece of software. When browsing a website over SSL, the browser is handling all of that for you. SSL over HTTP has a standard negotiation pattern because it's part of the HTTPS protocol. For TCP, that isn't part of the protocol so the client has to take care of that itself.