We're looking at exposing some of our internal application data externally via a website. The actual details of the website aren't that interesting, it'll be built using ASP.NET/IIS etc, that might be relevant. With this, I'm essentially I'm looking for a mechanism to authenticate users viewing my website.

This sounds trivial, a username/password is typically fine, but I want more. Now I've read plenty about SSL/x.509 to realise that the CA determines that we're alright, and that the user can trust us. But I want to trust the user, I want the user to be rejected if they don't have the correct credentials.

I've seen a system for online banking whereby the bank issues a certificate which gets installed on the users' computer (it was actually smartcard based). If the website can't discover/utilise the key-pair then you are immediately rejected!

This is brutal, but necessary. Is there a mechanism where I can do the following:

  1. Generate a certificate for a user
  2. Issue the certificate for them to install, it can be installed on > 1 machine
  3. If their certificate is not accessible, they are denied all access
  4. A standard username/password scheme is then used after that
  5. SSL employed using their certificate once they're "in"

This really must already exist, please point me in the right direction! Thanks for your help :)

1 Answer 1


There absolutely is a mechanism that exists for doing this: HTTPS.

(I know what you're thinking--read to the end of the post before you decide it is not what you want!)

First, HTTPS is merely HTTP built on top of SSL, so having an in depth understanding of SSL will be beneficial.

Normally, SSL connections used on the web are only concerned with authenticating the server. However, there is a way that the server can authenticate the client as well by being its own CA and issuing a certificate to the client. This feature was built into the SSL protocol as an optional step in the event that you want 2 way authentication (much like what you are requesting).

Here's a BROAD picture of how it works:

  1. The client initiates a connection with the server, requesting its certificate.
  2. The server responds by sending its certificate back to the client. An optional part of this step is that the server can also challenge the client by requesting a certificate. Most websites do not do this. This is what you want to enable on your site.
  3. The client authenticates the server's certificate is valid by using the CA's public key to decrypt the certificate (if the data matches, then it is known that the certificate had to come from the CA, as only the CA has the private key to generate certificates).
  4. The client sends a symmetric key to the server (encrypted using a public key within the server's certificate). If the server requested a certificate, the client also sends its certificate to the server.
  5. The server authenticates the client. Usually this occurs by the server itself assuming the role of the CA and determining that the certificate did in fact come from this server. This step only occurs if the server challenged the client.
  6. Using the encrypted symmetric key that the client sent, the server determines what the symmetric key wil be and sends a confirmation back to the client.
  7. At this point the handshake is done. All further correspondence occurs using a simple symmetric key encryption algorithm.

Now comes the question: How does the client get the certificate in the first place? First of all, you need a secure way to issue a certificate. You mentioned smart cards (which can be good. A simple jump drive is good too as long as you are certain it will not fall into the wrong hands). If we are talking CIA-level security, then there is no easy (or cheap) answer to how to distribute the certificate--you will have you use your own judgement and do your homework on this one.

Once the user has the certificate, every major operating system has mechanisms for installing the certificate so that your computer will be smart enough to respond automatically with the correct certificate. Finding information on how to do this shouldn't be tough (I did it before and don't remember too many problems finding information on the subject).

Unfortunately, I have only ever dealt with being a client when working with this, but these links (and anything else that shows up under a google search for "SSL Client Authentication") should help you out:

I assume that you already know that this will bring headaches to your clients, so only do this if you are 100% certain that a simple web login with the more basic HTTPS encryption is not what you want.

Best of luck, and hope this helps.

  • This is excellent and annoyingly straight forward! Step 2 seems to highlight the process that I just haven't been able to find anything out about. I'll digest the rest then see if I can knock a prototype together and get back when I'm done (unfortunately, the whole website itself is a low priority in the work schedule so it might be a while...). Thanks again!
    – Tom
    Nov 15, 2011 at 9:35
  • @Tom, I've found this site (developer.mozilla.org/en/Introduction_to_SSL) to be very helpful when learning the ropes. It is harder to get through, but covers everything in more depth. Best of luck.
    – riwalk
    Nov 15, 2011 at 16:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.