Why is it much more difficult to enable SSL (transport security) through net.tcp than HTTP?

Question

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

Implementing a web service that uses transport-level security with WCF on top of net.tcp is quite complicated: WCF with NetTcpBinding transport security and certificate

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

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

In the case of HTTP, you do not even need to mention the certificate on either the client or the server. In the case of NET.TCP, you must store, locate, and indicate the certificate on both the client and server in most of the sources that I read.

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

Answer 1

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

EDIT

On the client side, you still have another piece of software. When viewing a website via SSL, the browser handles all this for you. SSL over HTTP has a standard negotiation pattern because it is part of the HTTPS protocol. For TCP, which is not part of the protocol, so the client must take care of this himself.

Answer 2

I also struggled with this, and now, finally, I feel like an idiot. This is good because it means that I really understand what I just hacked before.

When implementing the service, your goal is to provide SSL connectivity. You should be able to generate your reference.cs file in a visual studio. The problem is that you are also adding metadata exchange under SSL binding. Code generation tools do not allow you to configure the necessary netTcpBinding configuration sections for calls that are made to retrieve metadata when they are used to generate the reference.cs file.

In netTcpBinding, you must create two separate binding configurations, one for your service:

 <security mode="TransportWithMessageCredential"> <message clientCredentialType="Certificate"/> </security> 

config inside and another using:

 <security mode="None" /> 

instead of this. Make sure that all other parameters match, and the endpoint for your services points to ssl bindingConfig, while the metadata endpoint indicates no SSL binding. Then you can read the metadata and update the help service again.

It should be noted that you must use metadata binding for any prod releases. This ensures that you do not expose anything that is not related to SSL.