Is there any way to use WCF SSL with NetTcpBinding that would not require a client certificate to be installed on the client machine? (SSL V2 if i'm not mistaken).
we want the server certificate will be in the client's trusted store for authentication and Encrypting its message by the server's public key, which means, only the server machine will hold a private key certificate.
we're using a NetTcpBinding and not customBinding on both sides. If its can bo done, what's the correct configuration for it? (on client & server configs)
Thanks in advance.
here are my wcf Configs.
SERVER CONFIG:
<configuration>
<system.serviceModel>
<bindings>
<netTcpBinding>
<binding name="TcpSecureBinding">
<security mode="Transport">
<transport clientCredentialType="Certificate"/>
</security>
</binding>
</netTcpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceCredentialsBehavior">
<serviceDebug includeExceptionDetailInFaults="True" />
<serviceMetadata httpGetEnabled="true" />
<serviceAuthorization
principalPermissionMode="UseWindowsGroups">
</serviceAuthorization>
<serviceCredentials>
<windowsAuthentication includeWindowsGruops="true"
allowAnonymousLogons="false"/>
<clientCertificate>
<authentication certificateValidationMode="none"/>
</clientCertificate>
<serverCertificate
findValue="thumbprint"
storelocation="LocalMachine"
x509FindType="FindMyThumbprint"
storeName="My"/>
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="ServiceCredentialsBehavior"
name="ServiceModel.Calculator">
<endpoint address="net.tcp://localhost:8040/Calculator"
binding="netTcpBinding"
bindingConfiguration="TcpSecureBinding"
contract="ServiceModel.ICalculator" >
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
</service>
</services>
</system.serviceModel>
</configuration>
CLIENT CONFIG:
<configuration>
<system.serviceModel>
<client>
<endpoint address="net.tcp://localhost:8040/Calculator"
behaviorConfiguration="endpointCredentialBehavior"
binding="netTcpBinding"
bindingConfiguration="Binding1"
contract="ServiceModel.ICalculator">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
</client>
<behaviors>
<endpointBehaviors>
<behavior name="endpointCredentialBehavior">
</behavior>
</endpointBehaviors>
</behaviors>
<bindings>
<netTcpBinding>
<binding name="Binding1">
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
</binding>
</netTcpBinding>
</bindings>
</system.serviceModel>
</configuration>
im adding my current server & client configs. another questions:
at the authentication level we want the client to authenticate ther server's cert (i think server's public key should be in trustedPeople store) , is this possible?
do you recommend us use Transport Security Or Message?
if we want to authenticate client & server by NTLM (clientCredentialType=Windows) is it can be done in addition to the server's cert authentication or just one of them can be applied? till now, we've used NTLM authentication.
right now im getting exception: "The requested upgrade is not supported by 'net.tcp://servername:8040/**'. This could be due to mismatched bindings (for example security enabled on the client and not on the server)." i understand this error occured because the client is using Windows Security and server in om Certificate, but when im changing client security to Certificate also,im getting an error: "The client certificate is not provided". but i don't want to set client's certificate and thats part of my main problem.
we read that we can use for server's cert authentication this tags:
<identity> <certificate encodedValue="encoded certificate"/> </identity>
but, i think this authentication by identity is done by an encoded certificate when we preffer that the cert's identification will be performed by searching the server's public key in the client's store (trustedPeople). does this information really true? that this tags of identity are alternative to searching public key in client"s trusted store?
hope you will be able to assist in this manners, thanks again.
