Who Are Certificate Authorities? | IIS 6: The Complete Reference

Any Windows 2003 server can serve as a CA. For a public web server that is going to offer a secure area, you will not want to use certificates from your own CA, though, because the visitor's browser will not recognize your authority as a CA and the certificates you issue will be rejected. If your certificate is for a web server that serves a large amount of people, that's probably not a good thing, because most web browsers will pop up with an error message. For this sort of situation, you'll need to go to a commercial CA.

The following table lists some of the commercial certificate authorities out there:

Verisign	http://digitalid.verisign.com/
Thawte	http://www.thawte.com/
Globalsign	http://www.globalsign.net/
InstantSSL	http://www.instantssl.com/

If you want to create your own certificate, Windows Server 2003 has a certification authority that you can install. We'll get to that in 'Choosing Which Type of CA to Install' a little later.

Note

A $600 certificate and a $50 certificate appear the same to your browser. The browser's only requirement is that a commercial CA be trusted.

How Server Certificates Work with SSL

The SSL handshake is what brings authentication, encryption, and verification together. The following occurs during an SSL handshake:

The client sends the server the client's SSL version number, cipher settings, randomly generated data, and other information that the server needs to communicate with the client using SSL.
The server sends the client the server's SSL version number, cipher settings, randomly generated data, and other information the client needs to communicate with the server over SSL. The server also sends its own certificate.
The client authenticates the server as described in the Certificate Authorities and Trusts section.
With the information gathered so far, the client creates a premaster secret for the session, encrypts it with the server's public key, and sends it to the server.
Using the premaster secret, the server follows a series of steps to create the master secret; this occurs on the client.
The client and the server use the master secret to create the session keys.
The client sends a message to the server stating that the next message will be encrypted with the session key.
The client sends an encrypted message to the server stating that the handshake process is finished.
The server sends a message to the client stating that the next message will be encrypted with the session key.
The server sends an encrypted message to the client stating that the handshake process is finished.
The process is now finished. The client and the server use the session keys to encrypt data with symmetric-key encryption.

So, the client first authenticates the server using the certificate. After authentication, the client uses public-key encryption to send information that is used to created a shared key (the session key). Then the session key is used to perform the more efficient symmetrical-key encryption on the rest of the data. The shared key is specific to this session and is never used again.

How Client Certificates Work

If you want to authenticate a user who is accessing your secure site, you can use client certificates. From your CA, you can issue certificates to any client computer or to any user you like. Once a user has a client certificate installed on their machine, they can securely authenticate to your server without using passwords.

Authenticating a client using certificates adds a few steps to the SSL handshake. Let's look at the SSL handshake one more time-this time with client certificates. The added steps are in italics:

The client sends the server the client's SSL version number, cipher settings, randomly generated data, and other information that the server needs to communicate with the client using SSL.
The server sends the client the server's SSL version number, cipher settings, randomly generated data, and other information the client needs to communicate with the server over SSL. The server also sends its own certificate.
The server requests the client's certificate.
The client authenticates the server as described in the Certificate Authorities and Trusts section.
With the information gathered so far, the client creates a premaster secret for the session, encrypts it with the server's public key, and sends it to the server.
Again using the information gathered so far in the handshake, the client signs a piece of data. The client sends this signed data and its certificate along with the premaster secret.
The server attempts to authenticate the user using the same steps the user used to authenticate the server.
Using the premaster secret, the server follows a series of steps to create the master secret. This occurs on the client.
The client and the server use the master secret to create the session keys.
The client sends a message to the server stating that the next message will be encrypted with the session key.
The client sends an encrypted message to the server stating that the handshake process is finished.
The server sends a message to the client stating that the next message will be encrypted with the session key.
The server sends an encrypted message to the client stating that the handshake process is finished.
The process is now finished. The client and the server use the session keys to encrypt data with symmetric-key encryption.