I'm creating a Windows Forms application that uses an embedded WebBrowser control to view an intranet web page. The page is provided via https, using a self-signed certificate. I want the certificate to be valid in the context of my application, but don't want to mess with the client's machine itself (by permanently installing a trusted certificate).
Is there any way to programmatically trust a certificate for the lifetime of an application, rather than for the system as a whole?
You can certainly do that. But you may need to do it in two steps. Make a https request first and get the Server certificate and create a truststore on the fly and import the certificate into the truststore. This would be a onetime activity. You may cache this truststore to the filesystem so that you need not do this everytime. Make another https request and use this truststore for validating the subsequent https requests that you will make.
Related
On a Certificate provider, StartSSL, when you register, you put in your email and a password. They generate a certificate (.pfx) which you need to download and install into your browser.
Which was pointed out in comments that it is a Client Certificate.
So when you click login, in Chrome for example, a window popups and asks you which certificate to use. I could have several client certificates and log into separate accounts based on what I select. They warn that if you loose the certificate then you can't log in to the site without them regenerating a new certificate.
I am would like to do this using C# - I would like to generate a client certificate and then use it later to log in as admin without typing in a password.
What are the mechanics of this? How can generate certificates and use them to log in to my site? I would like to do this on a MVC C# site. I don't mind if I need to generate self signed certificates, its only for my own use. At least it gets rid of password forms and brute force attacks.
This is fairly simple, the certificate requirement is an option of the SSL handshake.
First you need to go to SSL options on IIS and check the option to accept and require certificates. This is enough for browsers to automatically pop up the cert selection window and the communication is mutually secured by both server and client certificates.
https://technet.microsoft.com/pl-pl/library/cc753983%28v=ws.10%29.aspx
Then comes the request pipeline. You either need a httpmodule or you just provide a handler for the global application's AuthenticateRequest event. There, you refer to the Request.ClientCertificate
https://msdn.microsoft.com/en-us/library/ms524668%28v=vs.90%29.aspx
You read the certificate's unique properties, for example the thumbprint and you use your local database to find a user record that corresponds to the certificate and you set up the Principal for the request lifetime accordingly.
I'm building a .net app, and I'd like to make the web calls secure enough that its not easy to monitor the the traffic thru something like fiddler. I'd like to be able to know that the certificate from the server isn't as expected and then never send out a full request with the request data.
Twitter's iOS app does this. Someone I think would have to somehow make a copy of the twitter's https certificate and make that fiddler's certificate. I havn't done it myself, but i think that's how I understand it. What you see in fiddler is that the tunnel has been created, but no request was actually set out. Its same scenario when you don't have the fiddler's HTTPS certificate installed on the device and you open a browser to google.com / a tunnel is created and then the browser knows 'uhoh untrusted server' and displays a message to the user. I'd like to just make it more secure and only allow 1 certificate / my server's certificate.
Make sense? I think i figured out how to do it with making a separate full dummy request / but thats not ideal.
What you're asking is "How do I implement certificate pinning in my client application?"
The way to do that would be to attach a validation callback on the Service Point responsible for making your HTTPS requests. Your validation callback would override the default behavior ("Accept any certificate trusted by Windows") and would instead validate that the received certificate is EXACTLY the one you expect.
Now, before you go that route, keep in mind a few things:
An attacker with Admin or Debug privileges can easily change your code in memory to remove your validation. This is called the "Trusted client" problem.
Your validation will break if the code is ever run in a corporate environment where an security appliance is doing HTTPS inspection (e.g. BlueCoat, ISA TMG, etc)
Your validation will prevent "certificate agility" -- if the server cert needs to change, you will need to update the application. If you ever want to use a load-balanced configuration with multiple certificates, or a public HTTPS CDN, you would need to update your validation logic.
I am working on one project where we have to deploy two different application on server, one is Cognos website and other is .NET website.
Now, when request come to web server (IIS) it should asked for Client Certificate Selection, once you choose the client certificate it should go back and check where it is attached with any Active Directory Users or not.
basically i wanted to implement authentication using Active Directory and Client certificate using .NET.
Appreciate for any suggestion/direction.
This should work out of the box with no code.
First, turn off anonymous access and basic authentication for the website and turn on integrated windows authentication and certificate integration.
Then, in your asp.net application, set the auth mode to windows.
Then, turn on SSL for the website and check the option "require client certificate".
http://technet.microsoft.com/pl-pl/library/cc753983%28v=ws.10%29.aspx
From now on, when the browser supports certificate integrated authentication and the client machine has the certificate either in the user store (IE) or in the browser store (other browsers), the browser will automatically ask the user to pick up the certificate.
My advice is to start with integrated windows authentication over SSL but without certificates (do not check "Require client certificates"). Test with IE and configure the IIS until your users are automatically authenticated without any prompt for credentials.
This is the most troublesome part. If you have it working, you just turn on the requirement of client certificates.
I have a third party web application and now my manager wants to add smart card authentication to some of the pages (not the whole application) and return certificate information. What I'm thinking is to add buttons to those pages, and in the onclick event, I will do the client certificate authentication (where a certificate selection window will appear followed by the "PIN" window) and return certificate object for further processing.
I initially thought about a web service to do the client certificate authentication and return certificate information, which would be great because we might consider using that web service in other web applications (on different platforms). However, I couldn't find any code example that did this. Then I found the IIS solution.
I have now created a separate folder with a page that requires a client certificate. On the button click event, I redirect to that page. Then on that page, I retrieve the certificate information using the X509Certificate class. I don't think this helps me in what I'm trying to do, or at least I don't know how it helps.
So my question is (sorry for the long background description)
How can I redirect back from that page with the certification result?
If possible, any reference on how to build up a web service that does the client certificate authentication in the same way that IIS does?
Thanks
Update
I looked around and still don't have a clue on how to achieve this. I'm not sure how to code at SSL/TLS handshake stage for the web service. I don't know how to return the certification back to the page I invoke this function either. So what I'm trying to do now is to redirect from a protected page that requires client authentication. It seems the web server caches the authentication result. Here is my third question, I hope someone can answer.
How can I clean out the authentication result at the end of the page session so that each time the page is visited, it request client authentication (where a certificate selection window will appear followed by the "PIN" window)?
if your app is hosted in IIS then simply add (in web.config) a section that says client certificate is required for those pages. THe browser will then ask the user for a cert.
Windows has a caching feature which, by default, allows applications to access the private key for a limited time after the initial PIN prompt, or until the application is closed completely.
To disable, set this registry key. (Or use a GPO)
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography]
"PrivKeyCacheMaxItems"=dword:00000000
"PrivKeyCachePurgeIntervalSeconds"=dword:00000000
I have a .net 2.0 windows service application written in C# that access a non-soap web service via SSL with HttpWebRequest. My windows service runs under the NETWORK SERVICE account.
I am able to make SSL work by issuing a cert to the web server that my windows service talks to from a CA, then installing the CA's cert to the Local Machine\trusted root store.
What I would like to be able to do is to install the CA's cert to the "service account" trusted root cert store instead of the "local machine" store, and have this "just work."
In other words, it seems that the SSL authentication used by the .net framework is hard coded to check the current user store, and the local machine store for trusted roots when validating an SSL certificate, but is there any clean way to get it to check the "service account" store instead of (or in addition to) the other stores?
The only solution I can come up with is to override the ServicePointManager.ServerCertificateValidationCallback and then P/Invoke to the Crypto API to open the "service account" cert store in Win32, and manually search for the root in there. I'd rather not do that, since it would seem to be a pretty large performance penalty, having to wait for failure from 2 cert stores I don't intend to use anyway.
Possibly, i'm taking entirely the wrong approach here, but it really seems like I'm missing a simply way to solve my problem.
If your code controls the server it is talking to, then why dont you just return "true" from the CertValidationCallback? It is not as if the server cert will change every time you make a request?
Unless you really need the system to also verify other things related to the cert, for eg CRL, expiry etc, you might just make it work by implementing a custom cert validation callback.
If you really want to install the cert into the NETWORK_SERVICE a/c context, then there are tools from Microsoft to help you do that.
http://support.microsoft.com/kb/901183
http://web.asu.edu/community/installing-client-certificate-windows-machine
http://www.derkeiler.com/Newsgroups/microsoft.public.dotnet.security/2008-03/msg00011.html
good luck!