SSL/TLS certificates: What you need to know

Firefox's new way of handling SSL/TLS certificates is fueling significant debate due in large part to misunderstanding the SSL/TLS certificate process. I'd like to help clear up the confusion by explaining what SSL/TLS certificates are and how they work. 

Let's face it, SSL/TLS (HTTPS) is vital to user security and privacy on the Internet. Which is why recent news about SSL/TLS certificates and articles like my last one about surf jacking, "HTTPS: Surf Jacking Makes It Vulnerable," are troublesome.
The problem, quite simply, is that human intervention is required to verify the authenticity of certain types of certificates. This became apparent when Mozilla changed how its newest Web browser (Firefox 3) handles Web sites with expired or self-signed SSL/TLS certificates. The article "New SSL Policy in Firefox Hurting Tens of Thousands of Sites" on Pingdom's Web site does an excellent job of explaining the changes:

"If you visit a Web site with either an expired or a self-signed SSL/TLS certificate, Firefox 3 will not show that page at all. Instead, it will display an error message, similar to any other browser error (for example a "page not found" 404 message). To get past this error page, users have to go through four different steps before they can access the Web site, which from a usability standpoint is far from ideal."

The error occurs because Mozilla has decided to take SSL/TLS Web page security to the next level, challenging any certificate that isn't in the Web browser's certificate database, has incorrect information, or is expired. This is a good thing; it will make Web browsing and online commerce a great deal safer. In order to understand why, let's take a quick look at the SSL/TLS process.

SSL/TLS processes

SSL/TLS consists of two important and independent processes: authentication and data stream encryption. With today's tough Internet environment, it's vital to have strong encryption to protect the data packets as they travel to their destination. Thank goodness that using a SSL/TLS VPN is secure and working properly. The weak link, I'm afraid, is part of the authentication process, so I'd like to focus on that.
Authentication is all about digital certificates, so it might be best to start by describing what a digital certificate is. A digital certificate is a data file that contains information about the Web site's certificate holder and is used to verify that the Web site is indeed what it portrays to be. The Web server's host name, issue and expire time, and the public key for the Web server are just a few of the details contained in a certificate. To look at certificates installed on your computer, use the following paths:

• Internet Explorer: Tools | Internet Options | Contents | Certificates
• Firefox: Tools | Options | Advanced | Encryption | View Certificates

The following image shows certificate details:

I can hear everyone saying that's nice, but it doesn't help me at all. I'm happy to say that understanding the exact details isn't important, but the overview explanation will help make the following concepts easier to fathom. Just remember — digital certificates verify the identity of the Web server to the Web browser that's trying to set up a SSL/TLS connection with the Web server.

Different types of SSL/TLS certificates

There are two major categories of certificates, trusted and untrusted. Trusted certificates are those residing on the Web browser and signed by a trusted certificate authority (CA). In order to understand this, let's say I want to create a trusted Web server SSL/TLS certificate that's signed by VeriSign, a well-known and respected CA. The following example will show the steps I need to take:

1. I create a certificate request on my Web server for www.mpksecuresite.com; doing so initiates a PKI key chain consisting of a private/public key combination.
2. I create a certificate request required by the signing CA, which in this case is VeriSign. The request includes domain name (distinct DNS name) of the Web server, distinct IP address, the public key (needed for signing and verification), and locality information. VeriSign will also ask for very specific information as it tries to verify that I'm the rightful owner of the domain.
3. The Web server signs the request with the private key, and it's sent to VeriSign.
4. Responsible CAs such as VeriSign then go through a great deal of effort to make sure the request is valid. Once satisfied, VeriSign also checks the validity of the key pair, since the request contained the public key and was signed using the private key (both developed in step 1).
5. Everything checks out, so VeriSign adds its pertinent information to the certificate and signs the request using VeriSign's private key.
6. VeriSign sends the certificate back to me, and I install it on my Web server.

Now my Web server has all the required components to set up a SSL/TLS connection with Web browsers. So let's take a look at how a Web browser goes about the SSL/TLS certificate exchange.

Web server/Web browser certificate exchange

Begging your indulgence, I'd like to continue using the above example to explain the certificate exchange between the Web server and Web browser. Since everything is now in place in the example, I can set up a test SSL/TLS connection. Let's see what happens by following the certificate exchange steps during a SSL/TLS connection setup:

1. I open my Web browser and type the URL https://www.mpksecuresite.com. Through the normal TCP/IP process, the Web server for www.mpksecuresite.com receives the Web page request.
2. The Web server for www.mpksecuresite.com responds by returning the certificate for mpksecuresite.com back to my Web browser.
3. My Web browser runs several checks, including certificate expiration and host name on the certificate.
4. My Web browser notices that the certificate from the mpksecuresite.com Web server was signed using VeriSign's private key. My Web browser immediately checks its certificate database to see if it has VeriSign's certificate information.
5. The Web browser locates VeriSign's certificate information. My Web browser then uses the public key found in VeriSign's certificate information to validate the signature on the certificate sent by the mpksecuresite.com Web server. Please remember that the certificate from the mpksecuresite.com Web server was signed using VeriSign's private key.
6. The certificate signature checks out. My Web browser knows VeriSign is a trusted CA, so it now trusts the mpksecuresite.com Web server as well.

That's how a SSL/TLS certificate exchange works. If you remember anything from the above process, it should be step 4 and the reasons why my Web browser trusted www.mysecuresite.com:

• My Web browser lists VeriSign as a trusted signing CA.
• VeriSign verifies that www.mysecuresite.com is what it claims to be, so my Web browser trusts the Web site as well.

It's vital to realize there's a pre-installed list of trusted certificates on every Web browser. This is done to set up a "chain of trust." This chain of trust starts with the Web browser developers, who include this list of trusted signing CAs in the Web browser installation program. So, it's automatically installed and presumed to be secure and accurate.
Therefore, if everything is as it should be (Web sites using certificates signed by trusted signing CAs) the whole SSL/TLS connection process is automatic. In fact, so automatic that we tend to become complacent about whether or not the connection is indeed encrypted and authenticated. When the automated process breaks, we get into trouble as exemplified by the new Firefox Web browser.
Self-signed certificates aren't automatically trusted Self-signed certificates are the next most widely used certificates and belong to the untrusted category. This type of certificate requires manual approval and installation on the Web browser. It might be best to walk through a SSL/TLS certificate exchange with a Web server that's using self-signed certificates:

1. I open my Web browser and type the URL https://www.mpkselfsign.com. Through the normal TCP/IP process, the Web server for www.mpkselfsign.com receives the Web page request.
2. The mpkselfsign.com Web server sends the self-signed certificate for www.mpkselfsign.com back to my Web browser.
3. My Web browser runs several checks, including certificate expiration and host name on the certificate.
4. My Web browser checks its certificate database to see if it has certificate information for www.mpkselfsign.com.
5. Since I have never been to this Web site, there isn't a certificate in the Web browser database. So the process stops right here and a window (like the one below) pops up asking me what I want to do.

This is where it gets complicated. I have to decide whether I trust this site or not. I can look at all the certificate information and make a decision from that or I can do further research to increase my confidence that the certificate is real. The only way to truly validate the certificate is to get a copy of the self-signed certificate via some other trusted method (fax, e-mail, or even snail mail) and manually verify the electronic certificate with the one you asked for.
I realize it's very cumbersome, but it's the only way to positively determine the validity of a self-signed certificate. I also know that once the window pops up asking whether to accept the self-signed certificate or not, most people automatically accept the certificate. They want to get to the Web site, all the time wishing this window would just go away.
Firefox 3 and raising the bar It doesn't take much effort to visualize the potential attacks that can be precipitated by malicious self-signed certificates. This is why the people at Mozilla took a stance, and I agree with them. Just raising user-awareness of what it means to automatically okay a self-signed certificate is a huge leap forward.
Final thoughts Thanks for reading through yet another long article. It's a tough topic to understand completely, but that's not required. Everyone just needs to know what his or her options are when the "Unknown Authority" window pops up in the Web browser.