The scenario is this: there are 2 WCF Web Services, one a client (WCFClient), one a server (WCFServer), deployed on different machines. I needed certificate communication between the two of them.
On the server WCF I have set the binding to use certificates as client credential type.
<security mode="Message">
<message clientCredentialType="Certificate" />
</security>
Also, in the behaviour section, among other settings, I have
<serviceBehaviors>
<behavior name="Server.ServiceBehavior">
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="PeerTrust"/>
</clientCertificate>
<serviceCertificate findValue="Server"
storeLocation="LocalMachine"
storeName="TrustedPeople"
x509FindType="FindBySubjectName" />
</serviceCredentials>
</behavior>
</serviceBehaviors>
On the client WCF Service I added this endpoint behaviour
<endpointBehaviors>
<behavior name="CustomBehavior">
<clientCredentials>
<clientCertificate findValue="Client"
x509FindType="FindBySubjectName"
storeLocation="LocalMachine"
storeName="TrustedPeople" />
<serviceCertificate>
<authentication certificateValidationMode="PeerTrust"/>
</serviceCertificate>
</clientCredentials>
</behavior>
</endpointBehaviors>
When I wanted to test my services, I had an error message:
The service certificate is not provided for target 'http://blablabla...'. Specify a service certificate in ClientCredentials.
So I started checking things out on the Internet. After trying many things, the only thing that actually worked is adding this on my client:
<serviceCertificate>
<defaultCertificate findValue="Server"
storeLocation="LocalMachine"
storeName="TrustedPeople"
x509FindType="FindBySubjectName" />
<authentication certificateValidationMode="PeerTrust"/>
</serviceCertificate>
As you might think, yes, this means I need the Server certificate on my client machine. Which is clearly a very bad thing.
It works for my testing purposes, but it is an unacceptable for deployment.
I would want to understand what really could cause that error message and what the solution may be.
Later edit: In this project the client must not have the server certificate (even without having the private key). This is the specification of the system and it's quite difficult (in bureaucracy terms) to go beyond this.
There will be multiple clients, each with the client WCF service running, and each should know nothing more that their own certificate. The server will know the server certificate and all the clients certificate.
Looking here it reads,
When considering authentication, you may be used to thinking primarily
of the client identity. However, in the context of WCF, authentication
typically refers to mutual authentication. Mutual authentication not
only allows positive identification of the clients, but also allows
clients to positively identify the WCF services to which they are
connected. Mutual authentication is especially important for
Internet-facing WCF services, because an attacker may be able to spoof
the WCF service and hijack the client’s calls in order to reveal
sensitive data.
The service credentials to be used depend largely on the client
authentication scheme you choose. Typically, if you are using
non-Windows client authentication such as username or certificate
authentication, a service certificate is used for both service
authentication and message protection. If you are using Windows client
authentication, the Windows credentials of the process identity can be
used for both service authentication and message protection.
It looks to me that you do need the server certificate on the client machine, and that this is a good thing, not a bad thing. Note that you do not need (and should not put) the server's private key on the client machine. The private key is not contained in a certificate -- only the public key is.
Having the server certificate on the client machine means only having the server's public key on the client machine. The benefit is that the client now knows that it is talking to the real server.
I'm not familiar with WCF services, but this seems fine as far as the use of certificates.
why is it bad to have the service certificate on the client machine? it is only the public portion of it, not the private key.
if you use wshttpbinding you can set negotiateServiceCredential=true in which case the client will get the server cert dynamically. The price is a little bit of performance hit, and this endpoint will not be interoperable to non .net clients.
I actually forgot about this question, but at that time I have found the solution.
My actual problem was that I was using a basicHttpBinding for the communication I wanted to secure. basicHttpBinding implies ussing that serviceCredential part.
http://msdn.microsoft.com/en-us/library/ms731338(v=vs.85).aspx
Because of the system requirements I had, I changed the binding to wsHttpBinding. Now I don't need to put the server certificate on the client machine.
Related
I'm working on a WCF service that is to be consumed by a client that is not developed by me and also it's not .NET (possibly Java).
In any case, the service should support mutual SSL authentication, where both the service and the client authenticate with certificates X.509 certs at the transport layer. The certificates have been exchanged between parties at a prior moment.
My problem is that I cannot seem to get the right WCF configuration such that client certificate authentication works correctly. What I expect is that, as part of the TLS handshake, the server also includes a Certificate Request, as seen below:
Following this, the client should answer with a `Certificate Verify' among other things:
The (latest) service configuration is this one. I'm using a custom binding, with authentication mode set to MutualSslNegotiated.
<bindings>
<customBinding>
<binding name="CarShareSecureHttpBindingCustom">
<textMessageEncoding messageVersion="Soap11" />
<security authenticationMode="MutualSslNegotiated"/>
<httpsTransport requireClientCertificate="true" />
</binding>
</customBinding>
</bindings>
...
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceMetadata httpGetEnabled="false" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" httpHelpPageEnabled="false" />
<serviceCredentials>
<serviceCertificate findValue="..." storeLocation="LocalMachine" x509FindType="FindByIssuerName" storeName="My" />
<clientCertificate>
<certificate findValue="..." storeName="My" storeLocation="LocalMachine" x509FindType="FindByIssuerName"/>
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
The Server Hello part of the handshake looks like this for all service configurations I have tried, with no CertificateRequest.
Other things I should mention:
The service is self hosted and listening on a non-default port (not 443). The server SSL certificate has been bound to this port.
I have also tried a basicHttpBinding and a wsHttpBidning with security mode set to Transport and client authentication set to Certificate, with no results (same results actually).
Any ideas would be appreciated.
OK, after a few more tries I figured it out. Posting this in case others run into the same issue.
I should continue by mentioning that this behavior really needs to be mentioned somewhere on MSDN, in a location that is really visible for anyone looking for WCF security information and not buried deep in some tool's documentation.
The platforms where I've been able to reproduce and fix this: Windows 8.1 x64 and Windows Server 2008 R2 Standard.
As I mentioned, my issue was that I could not configure WCF security such that the service would require client certificates. A common confusion that I noticed while looking for a solution is that many people believe that the client can send the certificate if it has it, unchallenged. This is, of course, not the case - the server needs to ask for it first and, moreover, specify which CAs are allowed through a CertificateRequest reply.
To summarize, my situation was:
Service is self-hosted.
Service runs on HTTPS, on a non standard port (not 443 but 9000).
This meant that I had to create an SSL certificate binding for port 9000 by using netsh.exe http add sslcert. Well, the binding had been created but there was a catch. I only found the issue after running netsh http show sslcert just to check on my binding:
IP:port : 0.0.0.0:9000
Certificate Hash : ...
Application ID : ...
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
-->Negotiate Client Certificate : Disabled
The culprit was the last property of the binding, "Negotiate Client Certificate", documented here. Apparently, by default, this property is disabled. You need to enable it explicitly while creating the binding.
Recreating binding with the statement below solved the issue:
netsh.exe http add sslcert ipport=0.0.0.0:9000 certhash=... appid=... certstorename=MY verifyclientcertrevocation=Enable VerifyRevocationWithCachedClientCertOnly=Disable UsageCheck=Enable clientcertnegotiation=Enable
Prior to checking the bindings I tried hosting a simple WCF service in IIS and enable client certificate authentication from there. It was very curious to see that although there was no CertificateRequest issued by IIS, it still failed with a 403.7. Even IIS didn't create the binding with the appropriate parameters.
Anyway, now it works and this is how you can fix it.
Not to forget, the service configuration changed as well (the binding security) in order to allow certificate negotiation:
<customBinding>
<binding name="CustomHttpBindingCustom" receiveTimeout="01:00:00">
<textMessageEncoding messageVersion="Soap11" />
<security authenticationMode="SecureConversation" requireSecurityContextCancellation="true">
<secureConversationBootstrap allowInsecureTransport="false" authenticationMode="MutualSslNegotiated" requireSecurityContextCancellation="true"></secureConversationBootstrap>
</security>
<httpsTransport requireClientCertificate="true" />
</binding>
</customBinding>
I had the same issue when my bosses were questioning why was our IIS hosted WCF service which implemented "2 way SSL" (mutual certificate authentication) not observed to be sending "Certificate Request" in the TLS handshake. After some investigation, we finally found that the certificate port binding configuration for Negotiate Client Certificate is disabled.
Get the current binding information by running the below.
netsh http show sslcert
Get the certificate hash and the application GUID from the first record (or the relevant SSL port), then run the following netsh command using an administrator console on the IIS server.
netsh http add sslcert ipport=0.0.0.0:443 certhash=xxxx appid={xxxxx} clientcertnegotiation=enable
Note that if an existing binding already exists for the IIS address and port, the following error will be reported.
SSL Certificate add failed, Error: 183 Cannot create a file when that file already exists.
Run the delete command to remove the existing binding before retrying to add it back again.
netsh http delete sslcert ipport=0.0.0.0:443
After the reconfiguration, the observed Wireshark TLS handshake became as expected. However, in my opinion, this setting doesn't matter in the end as the client certification is used for authentication whether during the initial handshake or afterwards within the encrypted exchange and 2 way SSL is achieved.
I'm trying to setup a self hosted WCF service, exposed in endpoint with https address, and I want just certain clients can call the service.
Client authentication should be done by certificate provided by client.
I'm in a corporate network, all certificates are issued by same authority, so i'm using certificateValidationMode="PeerTrust" in server side to identify authorized clients.
The server certificate binding to port is done.
Service binding configured as:
<security mode="Transport">
<transport clientCredentialType="Certificate" />
</security>
Service behaviour configured as:
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="PeerTrust" trustedStoreLocation="LocalMachine"></authentication>
</clientCertificate>
</serviceCredentials>
The client certificate is in windows trust (trusted people) in server side.
The server certificate is in windows store (trusted people) in client side.
Communication between client and servers works OK so far...SSL handshake OK...
but, when I remove the client's certificate from Trusted People on server side, the client still can call the service, and I'm expecting just the opposite:
"If client's certificate not in server trusted people store, then dont accept call."
all cache already removed, server restarted... client app still can call the service from same previously authorized client workstation.
any suggestions ??
I have a WCF service that uses net.TCP binding, and this service can be consumed inside the LAN or through internet.
I have read that net.TCP by default use transport level security, but this security is point to point, I think that if I use my client out my LAN, through internet and the communication use many points, perhaps some of this points does not transmit the message without security. Is this correct?
So if I need message security too? I can use a ssl certificate x509 to encrypt the each message and that only can be decrypt by my service that has the private key?
Is there some document that explain how to use certificates with net.TCP binding? Can I use open ssl to create my certificate and use it with WCF?
Thanks.
First of all, both approaches are secure and will suffice for 90% of cases. Transport security secures your channel of communication, but doesn't encrypt your actual message. Message security encrypts your actual message, so servers that the message is passed through can not see the message contents and will need a private key to decrypt your messages. So one could argue message security is safer, at least its more suitable for internet communication. Some good links on WCF security:
Message Security in WCF and patterns & practices Improving Web Services Security Guide
netTcpBinding uses Transport security by default, but that doesn't mean you can't use Message security with it. Transport security has less computation overhead than Message security (where each message is encrypted) thus it has better performance. One caveat of using netTcpBinding over the internet is that it may not be guaranteed to work at all times (in the past I have successfully set up netTcpBinding over the internet though) since it uses some ports for message transmission that are not always guaranteed to be left open by network routers and firewalls (over the internet, your messages will be going through many routers and firewalls.) For internet communication, consider one of the HTTP bindings such as basicHttpBinding or wsHttpBinding which also supports message security.
You can use Message security like in other bindings:
<netTcpBinding>
<binding name="securedBinding">
<security mode="Message">
</security>
</binding>
</netTcpBinding>
and then set the bindingConfiguration on your endpoints to securedBinding.
And on the machine hosting your service (the server):
<behavoirs>
<serviceBehavior>
<behavior name="securityBehaviour">
<serviceCredentials>
<serviceCertificate
findValue="serviceCert"
storeLocation="LocalMachine"
storeName="My"
x509FindType="FindBySubjectName" />
</serviceCredentials>
</behavoir>
</serviceBehavior>
</behavoirs>
<services>
<service name="Service1" behaviorConfiguration="securityBehaviour">
<endpoint address="" binding="netTcpBinding" contract="IService1" bindingConfiguration="securedBinding">
</endpoint>
</service>
</services>
If you have limited clients and you know who they are, you can use self signed certificates. However if you want optimal security with many unknown clients consuming your service you're best off buying one from a known CA. You then need to install the server certificates on the server machine. Here is an article on how to secure your services with certificates, the blog also has some other useful WCF security articles that you may want to read.
WCF is extremely extensible and has a lot of ready-to-use features, however I continue struggling with some topics and the more documentation I read, the more I get confused.
I hope to get some answers from the community. Feedback on any assumption or question is extremely welcome.
For the record: to really accept a single answer I should divide this post in multiple questions but it would lead to even more confusion.
I am pretty sure there are some real WCF experts online who can answer the few questions in this document all at once so I can accept a single answer as the real deal to setup clientcertificate authentication using IIS the right way.
Let me sketch the situation and partner request:
1: The partner requirement and the question to use a client certificate.
Partner X needs to call an API on my backend and they have the clear requirement to use Clientcertificate authentication.
They created the clientcertificate and provided us the certificate with only the public key since it seems only logic they keep the private key actually private and in their own system(s).
The certificate was imported on the local computer account and looking at the certification path this is valid. All intermediate certification authorities and in the end the root certification authority are trusted.
2: Our WCF serverside configuration
I have a serviceBehavior configured as such:
<behavior name="ClientCertificateBehavior">
<serviceMetadata httpsGetEnabled="true" />
<serviceCredentials>
<serviceCertificate findValue="<serialnumber here>" x509FindType="FindBySerialNumber" />
<clientCertificate>
<authentication certificateValidationMode="PeerTrust" />
</clientCertificate>
</serviceCredentials>
</behavior>
I guess I made a first mistake here and should use ChainTrust to actually validate the certificate using its certification path. What do you think?
The service is configured as such:
<service behaviorConfiguration="ClientCertificateBehavior" name="<Full service namespace and servicename>">
<endpoint binding="basicHttpBinding" bindingConfiguration="Soap11CertificateBasicHttpBinding"
contract="<The interface>"></endpoint>
</service>
The binding looks like this:
It is a basicHttpBinding to force SOAP1.1 (according to the partner's specifications).
<binding name="Soap11CertificateBasicHttpBinding">
<security mode="Transport">
<transport clientCredentialType="Certificate" />
</security>
</binding>
3: Hosting the WCF service in IIS and the IIS configuration
We host our WCF services in IIS7.
We configured the folder in which the services reside to require SSL and to accept Client certificates.
Authentication-wise anonymous authentication is enabled.
The thing is that communication from the partner works and we were confident that everything was OK, however toggling the IIS-setting to 'require' client certificate shows us that all of a sudden it is no longer possible to successfully call our service.
Am I correct to assume that following things are not done correctly:
The serviceCerticate in the serviceBehavior is not really necessary. This is a setting used by the client. Or is it necessary to provide this certificate information for the service endpoint to match the certificate that's being send by the client?
For clientcertificate authentication to really work in IIS the certificate needs to be mapped to a user. This user should be granted permissions on the folder containing the services and all authentication mechanisms (anonymous, windows,...) should be disabled.
This way IIS will handle the actual handshake and validate the servicecommunication.
Or is it more a matter of extra security mapping the certificate to a user?
By setting 'Accept' on IIS we bypass the actual certificate validation between client and server.
All authentication mechanisms like 'anonymous' and 'windows' have to be disabled on IIS for the folder which holds the services.
In your scenario, you don't need to configure certificates in WCF, IIS handles those for you. You can clear the entire <serviceCredentials> block, because:
The <serviceCertificate> of <serviceCredentials> specifies an X.509 certificate that will be used to authenticate the service to clients using Message security mode, which you do not use, and the <clientCertificate> of <serviceCredentials> defines an X.509 certificate used to sign and encrypt messages to a client form a service in a duplex communication pattern.
See here how to map client certificates to user accounts.
I'm trying to understand WCF and all of it's (complex) security options. I have developed a Wcf webservice with wsHttpBinding on localhost. I'm creating a Console Application that I will distribute to a few clients. Each client has it's own username and password which I will validate against my own database. To do so, I've followed the following tutorial on codebetter.com: http://codebetter.com/petervanooijen/2010/03/22/a-simple-wcf-service-with-username-password-authentication-the-things-they-don-t-tell-you/
I got the selfsigned certificate, and granted permissions
I got the server & client all setup and running perfectly on localhost to localhost.
Question 1:
I added the svc service using VS2010 Add Service dialog and it added the folowing tag to my app.config:
<certificate encodedValue="AwA<...>" />
For learning purposes, I changed that value a couple of times, but it did not had any effect. It kept working perfectly. I use Fiddler to see the encrypted communication.
Question 2: Deploy on Test server with SSL
I've deployed the Webapplication, hosting WCF service, on a Test server with IIS7.5 and SSL configured. When I tried the client application to connect to the test-server, it threw a generic error. I discovered that when I changed from https:// to http:// it worked. Fiddler showed nice http communication with encrypted values.
But I also want to use HTTPS, together with my message-level encryption. I think this is not possible. I got it all working, just set the Security Mode to "TransportWithMessageCredential" and it's done. But when I do that, I can remove all certificate info on the client, and it still works. Therefore I can make the conclusion that Transport security (kind of) overrules the Message security.
So am I making the right conclusion:
Don't got https Transport security? Use certificates (pfx on server, cert on the clients)
Got https Transport security? Don't use the certificates, SSL is enough.
I hope I make myself clear :). Many thanks in advance.
Below a few (anonymized) configs:
Server
<bindings>
<wsHttpBinding>
<!--The maximum size, in bytes, for a message that is processed by the binding-->
<binding name="Binding1" maxReceivedMessageSize="4194304">
<readerQuotas maxDepth="32" maxStringContentLength="10485760" maxArrayLength="10485760"
maxBytesPerRead="10485760" maxNameTableCharCount="10485760" />
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName" negotiateServiceCredential="false" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="ApiWcfCustomBehavior">
<serviceMetadata httpGetEnabled="true"/>
<serviceCredentials>
<userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="CustomUserNameValidator, SupplierAPI"/>
<serviceCertificate findValue="xxxxApiv3" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName"/>
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
* Client *
var endPoint = new EndpointAddress(new Uri(apiUrl), EndpointIdentity.CreateDnsIdentity(endpointDnsEntity));
var binding = new WSHttpBinding();
//binding.Security.Mode = SecurityMode.TransportWithMessageCredential;
binding.Security.Mode = SecurityMode.Message;
binding.Security.Message.ClientCredentialType = MessageCredentialType.UserName;
binding.Security.Message.NegotiateServiceCredential = false;
using (var client = new SupplierServiceClient(binding, endPoint))
{
client.ClientCredentials.UserName.UserName = supplierUID;
client.ClientCredentials.UserName.Password = supplierPassword;
client.ClientCredentials.ServiceCertificate.SetDefaultCertificate(
System.Security.Cryptography.X509Certificates.StoreLocation.LocalMachine,
System.Security.Cryptography.X509Certificates.StoreName.My,
System.Security.Cryptography.X509Certificates.X509FindType.FindBySubjectName,
endpointDnsEntity);
}
I'm trying to do something similar right now (SSL, Message encryption, username/password authentication), and I'm also starting to think it's not possible, at least not without some hacking that I don't know about. If I understand this post correctly, when your client machine connects directly to your service machine over SSL you'll have a point-to-point connection meaning it's secured via SSL, and the authentication (username/password values) are secured with WS-Security.
An interesting analogy used in that post is online banking over SSL. Since the client and Server have a point-to-point connection, you'll have a secure channel.
this is just what I've found, so if someone thinks it's incorrect please let me know.