I am dabbling with WCF and SSL and have hit a bit of a problem.
I have a self-hosted WCF service and a basic client which connects to request a token.
I have it set up on my development machine it appears to communicating over SSL just fine.
But when I set it up on a different machine to test the deployment the client keeps getting nothing back from the service.
I assume it has something to do with the certificates I have set up as this is the only thing I think could be different.
I have used the netsh command to associate my port with an existing certificate that was already on the server. And it appears the same as my dev machine (where I created the certificate with makecert manually.
I initially tried to follow the same steps on the deployment server but failed as there was already a certificate with a common name of the server, so eve though the certificate generated when ever I tried to use the cert hash thumbprint of the newly generated certificate I was being given the :
SSL Certificate add failed, Error: 1312
A specified logon session does not exist...
The only way I could get the netsh http add to work was by specifying the cert hash of the existing certificate.
Is this my problem or a red herring? How do you debug issues like this?
Personally I just configure WCF tracing. It usually provides more user friendly info about a problem. Here's a how to link Configuring Tracing
Hope it helps!
Related
I have been trying to get my MSMQ to pass messages over HTTPS without success. All outgoing messages sit in a queue with status "Waiting to connect".
This is not the case for messages over HTTP, they are received without issue.
I've created a Certificate Authority on the receiving machine, downloaded the cert chain and CA cert, installing under Trusted Root (Local Computer and Current User profiles).
I then exported the CA cert and installed that on the sending machine (under TRCA - Local Computer and Current User)
I have been able to navigate to the target MSMQ using internet explorer, this usually give a 501 not implemented error.
I don't really know why this isn't working and it's pretty fraustrating.
What other approaches can I take to get this to work??
Cheers
Niall
The screenshot shows that the server isn't properly accepting the HTTPS connection from the client.
You'll need to add more information to your question, including details of how you attempted to bind the Server Authentication certificate to the endpoint on which your server is listening.
I am having the same issue with client certificates that many people have reported, but none of the solutions I've seen have worked for me. I have a client I wrote in VB.Net (using VS 2010 and .Net framework 4.0) that needs to connect to a web service running on Apache Tomcat/5.0.27. It works fine with SSL when client certificates are not required, but as soon as client certificates are required, it fails with “THE REQUEST WAS ABORTED: COULD NOT CREATE SSL/TLS SECURE CHANNEL”
Testing it with Internet Explorer (8, 9 and 10, on XP and Win7x32), when SSL is enabled (configured on Tomcat by setting sslProtocol="TLS" secure="true" scheme="https" in the system.xml file), but client certificates are disabled (clientAuth="false"), IE is happy after the CA certificate and the server certificate are installed on the client PC. (IE will complain without the certificates, but you can tell it to ignore the warning. When the certificates are installed, it connects without any warnings.) When client certificates are required (clientAuth="true"), IE will not connect. After I import the client certificate file, it still does not connect. IE shows that the client file is installed, and it shows the certificate is ok and it trusts the CA, but it shows it in what seems to be the wrong store: Intermediate Certificate Authorities, and client authentication is not ticked under Purpose. The MMC certificates snap-in shows the client certificate is in the Personal - Current User store.
The certificate was issued to us by the owners of the web service, so in theory it has to work. The properties look ok, and the purpose shows "All application policies".
I need to get this to work with my .Net client. I use a Web Reference to create the connection to the web service. I set PreaAuthenticate=True, and attach the certificate file to the web reference, and can see it attached in the IDE. Using Network Monitor, I can see that the server sends certificates to the client (in two large packets), but the client doesn't seem to send any back to the server.
I have tried various recommendations, e.g. setting ServicePointManager.Expect100Continue = true and
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3, but this makes no difference.
I have disabled firewalls and proxy servers, so nothing should be blocking the traffic.
I'd appreciate any help.
Ok, it turns out there is a problem with the certificate they supplied, or it is somehow incompatible with the client. I found instructions on using OpenSsl to create a certificate, and it works with their server. They used java's keytool to make the certificate, so either it creates an incompatible certificate, or they didn't use the right procedure, and the procedure I used with OpenSsl is the correct one.
The steps in OpenSsl are to create a private key file (client.key), create a certificate request (client.req), sign the key (client.pem) then export it (client.pfx).
I have a WCF service that I want to secure with Client Certificates but I cannot get it to work on Azure.
I removed Azure from the equation by hosting the service on a standard Windows Server on Amazon. I installed both the service and client certificates (none are self-signed) into the Local Machine 'Personal' store on this server including the chained certificates and it all worked as expected, called from my local PC, with the client cert set against the binding/behavior. It did not work without the certificate being specified so it definitely worked correctly this way.
I then deployed the service to Azure. The client and server certificates are uploaded to the portal and set in the config against "Local Machine/My" and the CA and root certificates are uploaded and I tried them in various stores including "My", "Trusted" and "CA". Every variation I try, I continue to get "The HTTP request was forbidden with client authentication scheme 'Anonymous'" called from exactly the same program locally with the only change being the client endpoint address.
As another detail, I can get it to work without certificates so there is no problem with the web service but I am unsure how to work out what is actually happening with the certificate handshake between client and service.
I have finally got it to work, and have written a guide here: Blogspot.co.uk
I'm not sure what I had got wrong before since I have not done anything too weird to make it work. I think perhaps I had a small defect somewhere in configuration that I eventually fixed by starting again. Anyway, it DOES work and provides some useful security on Azure.
See my answer to this SO post - bottom line, cert in LocalMachine/My and run with elevated privileges in csdef file add:
<Runtime executionContext="elevated" />
Scenario: calling a client web service over SSL (https) with mutual SSL authentication. Different service endpoint URLs and certs (both keystore and truststore) for test vs. production environments. Both test and production environments run tomcat / JBoss clustered. Production environment has load balancing / BigIP, runs Blade and non-Blade machines.
Truststore is set (using -Djavax.net.ssl.trustStore=value) at startup. Keystore is set using System.setProperty("javax.net.ssl.keyStore", "value") in Java code. Web service call made using Axis2. All works fine in test environment, but when we moved to production environment (6 servers), it appears certs are not being forwarded for the handshake. Here's what we've done:
in test environment, handshake using test versions of certs has been working all along, with no ssl debugging enabled
confirmed in test environment that handshake with client production
endpoint succeeds (production certs,
both ours and theirs, are fine) --
this was done using
-Djavax.net.debug=handshake,ssl
confirmed that the error condition occurs on all 6 production servers
took one server out of the cluster, turned on ssl debugging for
just that one (with a restart), hit
it directly, handshake works!
switched to a different server without the debugging turned on,
handshake error condition occurs
turned debugging on on that second server (with a restart), hit it directly, handshake works!
From the evidence, it seems like somehow the debugging being enabled causes the certificates to be properly retrieved/conveyed, although that makes no sense! I wonder whether somehow the enabled debugging makes the system pay attention to the System.setProperty call, and ignore it otherwise. However, in local and test environments, handshake worked without debugging enabled.
Do I maybe need to be setting keystore on server startup like I'm setting truststore? Have been avoiding that because the keystore will differ for each of our test environments (16 of them).
Turns out that the debug setting was a red herring. What actually bit us was that there was an existing client with an SSL/basic authentication web service we call when one of their users logs in. Since in that context the keystore wasn't relevant, the javax.net.ssl.keyStore property doesn't get set -- but the SSL exchange still tries to load a keyStore (which ends up not loading any certs). Since, unfortunately, even if the javax.net.ssl.keyStore value is changed, it does not get reloaded, calls to the other client's web service sent along no keystore certs.
The solution was to set the keyStore property at server startup rather than at the point of the web service call. If at some point in the future we need to be able to use different keyStores in different contexts, it looks like we'd need to implement a custom SocketFactory.
I have a self-hosted service that I want to add transport security to.
I've set WSHttpBinding.SecurityMode to Transport and the ClientCredentialType to HttpClientCredentialType.None.
I've created a certificate and set it to my host with
ServiceHost.Credentials.ServiceCertificate.SetCertificate()
I've also registered it using
netsh http add sslcert ipport=127.0.0.1:80 certhash=[MyCertHash] certstorename=MY appid=[TheGuidOfTheAppTahtRunsTheService] verifyclientcertrevocation=disable
I'm getting the following error message whenever I try to call the service:
"Authentication failed because the remote party has closed the transport stream."
Does this mean the the client and server try to authenticate each other? How can I disable it?
To make things clear, I do not want to install a certificate at the client, I'm not looking for any authentication atm, just securing the messages content, if that's even possible.
This MSDN post may help solve your problem. The initial request in the post is to configure a different security mode than yours but they switch to Transport mode for troubleshooting and that info should apply to your situation.
If what you describe is all you've done to install the certificate then you're missing a few steps. The post outlines the process to get a valid certificate installed. Good luck!!
Certificates can be a pain in the ass some times to get working. First thing you should always do with WCF is turn on tracing:
http://msdn.microsoft.com/en-us/library/ms733025.aspx
Then, you can use SVCTraceViewer to view the exceptions that your service is generating behind the scenes and get a little insight into what is happening, which is a must with many WCF problems. 9 out of 10 times, the trace will tell you everything you need to know.
Also, make sure that both the client and the server have the certificate configured, since the certificate needs to be installed on both machines.
I was trying to track down this same error, and came across this post. WCF tracing doesn't help as the error appears on the client side in the HTTP stack, and on the server side the request is rejected before it ever makes it to the WCF layer.
I found that I wasn't being thorough enough. Make sure all the following conditions are met. I had some but not all of these properly set up:
The server's certificate issuer has a valid and matching issuing
trusted root CA on the same machine.
The server certificate subject name matches the machine name
exactly, and the machine name the client is accessing matches as well ("localhost" vs the server's Environment.MachineName value)
The server certificate's thumbprint
has been set by an Administrator
using the following command (use
netsh equivalent for newer versions of Windows)
httpcfg set ssl -i 0.0.0.0:{port} -h {thumbprint}
This client also has the same valid issuing root CA certificate on the client machine.
Here's a good reference: SSL with Self-hosted WCF Service.