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.
Related
My Azure VM (Win 2008 R2 Datacenter) runs IIS 7.5 and hosts a half-dozen Web sites. I obtained and installed a certificate to enable SSL on one site. I tested the certificate with the downloaded SSL Diagnostics tool, and all appears great. The tool sent a sample SSL handshake with perfect results (diagnostic info along with the contents of the tiny test web page).
However, the web page is unobtainable using https://... from a browser on either the server or client. Localhost:443 or the server IP address:443 in a browser on the server also fails. No error messages are received, the browser just waits and waits.
What could it be?
If I use a browser on the server and input https://ip address without 443, I get this error in the browser: ERR_CERT_COMMON_NAME_INVALID. "Your connection is not private. Attackers might be trying to steal your information..." and it shows the info from the certificate, like the issuer etc. What's the deal?
Ugh. I needed to open port 443 in the Azure Portal, in my Network Security Group. Another question on StackOverflow steered me to that solution!
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!
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" />
Background:
I am updating an internal application to a two-step authentication process. I want to add a client certificate authentication process (via a smart card) on top of a traditional username/password form. The application is written in C#, hosted on IIS7, and targeting Chrome and IE8.
Problem:
I am having issues with getting the application to prompt the user for a client certificate. I have been debugging the application with the help of Fiddler. When I have a test client certificate saved in Fiddler's user's directory (C:\Documents and Settings\USER\My Documents\Fiddler2), the application works as expected. I am prompted for a PIN number protecting the smart card, and, when entered correctly, takes me to the login form. When I close Fiddler, the application throws a 403 Forbidden error instead (since Fiddler is no longer running and pointing to its certificate). What I haven't been able to figure out is why the application won't prompt for a certificate normally.
Current Server Setup:
Self Signed Certificate was created
443 Binding is pointing at Self Signed Certificate
Anonymous Authentication is Enabled
The Self Signed Certificate was added to both the Trusted Root CA and Intermediate CA (I read that another person had it in both rather than just the Trusted Root CA and that solved their issue, though neither set up has worked for us).
I cleared out the rest of the certificates in the Trusted Root CA that I didn't need (I read elsewhere that having too many certificates would cause SSL to choke).
I am out of ideas to try other than starting from scratch on another server. Does anyone know what the issue might be? This seems like it should be fairly straight forward and that I'm missing something minor. Any ideas are welcomed.
Update:
After spending more time with this issue today, I strongly believe it has to do with IIS7 not being configured correctly (I did not set up it originally). I think this because I enabled Failed Request Tracing, looked at the subsequent .xml files being generated, and saw that a 500 error was being thrown.
Chrome is throwing a "Access to the webpage was denied" message rather than a "403 - Forbidden: Access is denied". I don't know if this helps. I do know that when I do not make certificates required, the site will work as intended. Requiring a certificate is where it fails.
The Application Pool is set to .Net 4.0 | Classic | Network Service.
Your problem is that the browser doesn't either get the request to provide client certificate or there is a security related option to block it from happening. IE offers certificate only if the web site is in correct zone (intranet or trusted sites). Please check this before everything.
If that doesn't help then see this answer for next step. The netsh documentation says:
clientcertnegotiation
Optional. Specifies whether the negotiation of certificate is enabled or disabled. Default is disabled.
Enable that and even the dumbest browser should notice that it is supposed to offer certificate for authentication. To diagnose your problem further you can use WireShark to see the negotiation in action.
In every browser I've seen, the browser will not prompt you to select a certificate if it does not have any certificates signed by a CA the server trusts. So make sure your server is configured with the correct CAs. As Boklucius suggested, you can use openssl to examine the list of trusted CAs your server is sending to clients and see whether the CA you have signed your client certificates with is among them.
Try openssl s_client -connect yourip:443 -prexit
And see if the CA (your self signed cert) is send to the client in the Acceptable client certificate CA names.
you need to install openssl first if you don't have it
I'll throw in a "try restarting the browser" suggestion, particularly if you installed the certificate while the browser was running.
To add a rather painful lesson to the mix: Make sure you quit Skype (or any other application) that eats port 443.
So the idea here is if you are running a dev environment on the same machine (both client and IIS), and your team uses Skype or some other app to communicate.
Watch the hours go by as you try and debug this problem, seemingly doing everything "right", netsh http sslcerts and such, even rebooting but to no avail. Well, turns out Skype will eat 443 so turn it off and "poof" there goes your certificate prompt.
Then feel free to throw things at the wall, shout obscenities or just "Rage, rage against the dying of the light".
Also, make sure Fiddler isn't getting in the way. If you have it decrypting the SSL, it'll corrupt the message back to IE, and it doesn't have the certificate installed, so it can't offer it. Turn off fiddler, and voila, the certificate prompt appears.
In Firefox, if you press 'Cancel' the first time you're prompted for a certificate, and you left the sneaky 'Remember this decision' box checked, then Firefox will remember that and never offer it again.
You can view and delete your previous remembered decisions in Firefox Preferences -> Privacy & Security (about:preferences#privacy), View Certificates, and check the Authentication Decisions tab.
Just connecting to my VPN and trying showed me the certificate prompt. Needs to be done only the first time.
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.