A number of Countries have implemented electronic id cards, that their citizens can use to securely access online facilities like banking.
I am interested in learning how to support these cards, but tracking down documentation on how to do this from an IIS hosted website is a real PITA: In MSDN for example the bulk of the smartcard documentation covers the end to end scenario of linking smart cards to domain logins in a corporate environment.
I am just trying to authenticate the holder of - for example, a Spanish DNI-e card and perform an OSCP validation of the card via http://ocsp.dnie.es/
Now, its seems that, rather than explicitly detecting the smart card insertion, I need to create a login page on the server with SSL client authentication forced - but how do I configure one request to require ssl client authentication and to pick the correct client certificate?
Indeed, configure your server to require client certificate authentication. You will receive the client authenticator details in the headers.
You can force to only accept specific certificates by configuring the public root certificate of those client certificates on the server and removing all others that you are not interested in. In the authentication request going from your server to the browser, only the root certificates are listed that are trusted on your server system. The client browser will only offer client certificates that are somehow related to that root.
In an Microsoft environment you would configure your IIS to require SSL on your login page. Additionally, require SSL client authentication using a certificate.
Related
I’m building a web application where users can create their own websites. Users have the option to point their own domain names at these sites. A prototype for the application already exists; Apache accepts requests on all hostnames and the actual domain mapping and resolution happen at the application level (a simple database lookup grabs the site that matches the requested hostname).
Where I’m stuck is how users’ SSL certificates might fit into this equation. What steps would I need to take to allow a user to upload their SSL certificate such that the application could successfully handle secure HTTP requests to their hostname? Is this even something the application alone could handle?
I think you cannot handle this in your application alone.
It's a CA problem, except you are an intermediate CA company, or you cannot get the user's domain SSL certificate and sign for user's domain.
The typical user, and IMHO even more the user's who are going to create a web site of this system as opposed to setting up their own WordPress or other site on their own server (or their own paid shared server hosting account), will have absolutely no idea how to setup a proper SSL certificate, so getting it to your securely so that you can install it wouldn't even be an issue because they will never get that far.
However, you should be able to use Let's Encrypt to do exactly what you need. As part of the process of adding a domain, once the domain is pointing to your server (the users will have to figure out how to do that with their domain registrar), you can create a Let's Encrypt certificate and validate it. My favorite web hosting company (I won't name it as that is not relevant - anyone can do this with some effort) provides this capability as part of their Control Panel. They also provide paid certificates with a few of the big issuers, as they have for many years, but for most small sites Let's Encrypt works very well and is totally free. The setup literally takes only a minute. The key is that you have to give the user an IP address or CNAME first so that they can point the domain. Once the domain is resolving to your server, you can get the Let's Encrypt certificate.
I'm trying to authenticate login of a web app with three elements:
Userid of web app
Password of web app
Client Certificates installed on user's PC. I see a client or machine certificate as a long string or key which is stored in Windows registry.
I'm planning to put those three elements together in a table, so when user intent to login, it will send those three elements to server side and they will be checked.
For example, if user loads web app in a PC which has not be assigned to him, then server will validate that userid and password are correct, but client certificate does not belong to user, and will reject login.
I haven't yet installed a client or machine certificate in every client PC nor installed a CA in IIS. But according to Microsoft, an asp.net web app will send automatically a client or machine certificate to server and asp.net can get it. Also I have found another program example for doing that.
How is that possible? I allways thought that an asp.net web app can't read client resources and if you want to read client resources, then you should use something like ActiveX with all its complications.
Your are right, ASP.NET can't read any client resources. ASP.NET has nothing to do with getting a client certificate from the the user's PC.
What you do is to tell your Web Server (IIS) to request or require a client certificate. The server is adding a special http header to tell the browser to send a client certificate. The Browser asks Windows for one, or uses its own store (Firefox). The browser then sends the public part of the client certificate to the server.
Your ASP.NET can ask IIS whether the browser has sent a certificate and access that information for authentication purposes.
We have Web API 2 application exposed to outside vendors for various integrations. We're adding a new one with DocuSign through their Connect service and they will be signing their requests with their X509 certificate. I would rather not install the certificate on the server itself because we add new servers and deployments often based on load.
Here is my plan, and I'd like to know what the security risks are with it (assuming it will work at all).
DocuSign provides their X509 certificate for download. I want to place that *.cer file in my Web API application's ~/App_Data folder, along with any other certs from any other vendors. I will use a DelegatingHandler to grab the client certificate from the Request. I would then use the X509Chain class as described here to load all certificates from the ~/App_Data folder and to verify the request certificate.
From there I would map the certificate subject to a role and add that to the current thread to provide authentication for specific routes.
I've gathered from my research that this method would be less secure than installing DocuSign's certificate to the server's root store - is that correct? And how much less secure?
At the end of the day I'd like to (1) verify that the request is coming from who it says it's coming from, and (2) add roles based on the verified requester for authentication.
I am a developer working on an ASP.Net Web Application that uses forms authentication.
In my experience I have always worked in an environment where we use SSL to protect the web pages according to permissions.
In my new company my manager has asked me whether we need SSL and can we do without it.
We are using a private network for the application and do not anticipate any heavy duty hackers.
However it is useful that permissions protect webpages from unauthorised users.
So what is the best way of tackling this?
That depends on your security needs :-).
If you trust everyone who has access to the network (this includes people like cleaning staff and external contractors) not to install sniffing software and do bad things with the passwords and personal data they sniffed, then you can do without TLS. Otherwise you need it. That's up to your manager to decide.
If it's a private network (i.e. Intranet and everyone is 'trusted') then like #sleske mentions you don't have to use SSL for anything.
That being said my question is what is the manager's reasoning for not using SSL where it makes sense? If it's cost then you could have your own (company) CA rather than using a commercial CA. Most places I've worked have setup a CA on one of their server's (which may or may not be trusted by VeriSign or one of the other commonly used CA's) and that was used to issue certificates to internal web servers. All computers on the Domain were setup to trust the company's internal CA.
As far as SSL/permission protection of your pages/content:
SSL protection is a separate topic from 'permission' protecting your pages. SSL is just encrypting the http traffic from the client (browser) and the server. Protecting your pages is up to you using permissions and checking that the user is authenticated, the mechanisms for this don't change based upon (not) using SSL.
I’m developing an Intranet application and I want to make a secure authentication.
One approach can be use “https”. The problem is that the server doesn’t have a trusted certificate, therefore is a bit annoying for the client because the browser doesn’t trust in the certificate and complaints with a scary message.
Using http will compromise the user password but it can be combined with “Digest access authentication”
What do you think?
As of November 2015 you can't buy certificates for internal domains so as far as I know the only option is to pre-install the certificates on clients. Not a great solution.
Another possability if you want to keep your internal domains private is to create a public domain: mycompany.com, and then run your own DNS server internally that resolves your internal domains: accounting.internal.mycompany.com, hr.internal.mycompany.com and so on. Then I believe you can use a wildcard certificate for mycompany.com. I haven't tested this solution.
These are (y)our options:
If you have mostly Windows hosts, you can Distribute Certificates
to Client Computers by Using Group Policy | Microsoft
Docs
and use your own self-signed certificate in this way.
Non windows users or Windows machines not in the domain will have to
go through the hoops and warnings of either installing the
certificate properly manuallly or allowing the self-signed certificate.
A bad user experience.
You use a proper domain name, a real certificate and a messy DNS
configuration where www.mycompany.com resolves to an external site,
but wiki.mycompany.com is an internal site (But please, please don't put the internal
address for wiki.mycompany.com in an externally visible DNS record!)
You don't use HTTPS at all and use HTTP. Possibly by inventing your
own security for login pages (Yikes!)
They all suck.
Especially if you want to distribute an enterprise-ready onsite app, and you don't know the customer's network and DNS configuration beforehand.
Purchase a domain and trusted certificate? They are really not that expensive anymore if you shop around.
Having said that, digest access authentication is reasonably safe for authentication. Using http rather than https, all of the information you send across the wire will be plain text even if the password is not. Anyone that can plug a laptop in to your intranet running an application such as WireShark can view all of the information sent back and forth. If you care about that information not being compromised, http will not meet your needs.
You have these options:
Purchase a trusted certificate.
Or, generate your own root certificate, install it in browsers on all intranet computers (you should be able to do it since it's intranet), generate your own server certificate signed with your own root certificate. This is actually what companies often do.
Note: Digest access authentication is not helpful if you want to have form authentication (a HTML form with user, password, login page using the visual style of your app, nicer wrong-password error reporting, possibly additional features such as "remember me" or "forgot password").
If you need it to be a fully secure, you should purchase the SSL certificate.
From the wiki link you provided:
Disadvantages
Digest access authentication is intended as a security trade-off; it is intended to replace unencrypted HTTP Basic access authentication which is extremely weak. However it is not intended to replace strong authentication protocols, such as Public key or Kerberos authentication.
I think there's your answer :)