The Almighty Certificate Authority

A certificate cannot certify itself. That is, by itself, a certificate cannot be trusted. Some entity has to mark the certificate as valid with a trusted seal of approval. The PKI model includes a CA, which essentially signs and validates a given certificate as being trustworthy. The CA is at the top of the PKI pyramid. The CA can be a company like VeriSign, Entrust, or Thawte who manages digital certificates for public Internet citizens. It can also be a government organization like the U.S. Postal Service, or a private company like the one you work for that wants to use certificates for employee identification purposes. Sometimes, a CA can even be an individual like you or me.

We are focusing on CAs that serve the public Internet community, even though any CA serves the same purposes. Many CAs can exist in a single country, and each can operate independently of the other. In many cases, a chain is formed where a large root CA is responsible for establishing a chain of trust between smaller CAs.

CAs have a huge responsibility. When all is said and done, anybody who uses this centralized system of X.509-based certificates is putting his trust in the CA. The CA takes all responsibility for the creating, distributing, revoking, redistributing, validating, and binding of the attributes of a certificate to a real identity. You, on the other hand, trust the CA to do a good job at it. After all, every time a certificate is used, it must be verified and validated with a CA that issued it or signed it.

Certificate Revocation List One big job the CAs have is managing the Certificate Revocation List (CRL). Because certificates can be stolen, lost, cracked, or compromised in other ways, they cannot always be trusted. Those certificates that can no longer be trusted are put into the CRL. It is your job to check the Certificate Authority's CRL when you are validating a particular certificate.

For the most part, CAs operate independently of one another. Each CA's main jobs are to manage the directory of certificates and the authentication services that are associated with them. The X.509 PKI system, which revolves around the CA (as opposed to a PKI based on something more grassroots and distributed, like PGP), actually involves three parties:

• Certificate Authority

• Subscriber

• User

The CA issues certificates to the subscribers in a way that the users can verify the certificates. A subscriber registers with a CA when he wants his own certificate. The subscriber could be a company, an individual, or some other real-world entity. Consider for a minute that Alice is the subscriber.

Alice goes to the Web site of a major CA such as VeriSign or Thawte. She registers to get a personal digital certificate that she can use for identification and secure e-mail. The CA processes her order, charges her a yearly fee, and gives her a certificate that expires in two years. As the subscriber, Alice has just created an online identity that anybody else can use to communicate with her.

Bob is a user who doesn't even own a digital certificate. Alice has given Bob her public digital certificate (as a computer file) because she intends to exchange secure e-mail with him in the future. Alice later sends an e-mail message to Bob and signs it with her digital certificate's public key. As a user, Bob queries the CA that issued Alice's certificate and public key. Because Bob's software is set up to trust the CA that issued Alice's certificate, it trusts the CA's response saying that Alice's certificate is valid. That's it. Alice sent a signed message to Bob, and Bob verified that it was authentic and valid.

Different Levels of Certificates

The CA will issue different levels, or classes, of certificates that indicate what role the certificate can serve. Some general-purpose roles of a certificate include the following:

• Server authentication and SSL

• Client authentication and SSL

• Secure e-mail

• Software code signing

In the case of server (running a Web site, for example) or client authentication and SSL, a digital certificate can serve multiple purposes. When you browse to an SSL-enabled Web site, that Web site gives your Web browser its digital certificate. Your browser verifies that it trusts that certificate if it is issued or signed by one of the CAs that are preinstalled into your browser. If the certificate is issued or signed by an unknown CA, your browser alerts you and asks you to make the choice of whether to accept it. If it is accepted, the server might ask your Web browser for your digital certificate. The process is similar; the server attempts to validate your certificate before continuing. When the certificates are validated, your browser and the server trust each other, having authenticated each other's identity. The next step is to use the public keys that are stored in the certificates to set up an encrypted SSL channel.

The validation process can be the same for e-mail and code signing. If you receive a signed e-mail message from your boss, your e-mail client attempts to validate the signature based on the CAs in the chain of trust. Additionally, the certificates can be used to send encrypted, private e-mail, similar to PGP. When a Web site asks your browser to download and install software on your computer, it might present a digital signature for that software. Your browser then goes through the process of validating that signature with a trusted CA before it decides to trust and install the software. If you have your browser configured securely, you will be made aware of the process.

The Root Certificates

The CA, or root authority, has a root certificate, which is distributed to clients, like you. The CA uses the root certificate to sign certificates that it issues or trusts. These root certificates are preinstalled into popular Web browsers such as Internet Explorer and Netscape Navigator. In fact, with Windows 2000 and XP, these certificates are preinstalled into the operating system as well. By storing these root certificates, your Web browser implicitly trusts any certificates that are issued by that CA. For example, let's take a look at Netscape Navigator 6.1's trusted root certificate list. To view the list of trusted certificate authorities that Netscape bundles with its browser, select Edit, Preferences, Privacy and Security, Manage Certificates. In the Certificate Manager dialog box, select the Authorities tab to see a screen similar to Figure 9.11.

In this window is the list of all CA root certificates with which Netscape Navigator 6.1 comes bundled. It is important to be aware of this list because it essentially takes the responsibility of validating a certificate out of your hands. The Web browser validates a given certificate if a CA in this list issues it. This might seem in violation of the function of X.509 PKI and the digital certificate architecture, which is supposed to leave the choice of whether to trust a certificate up to the end user. However, you really do have control over the decision of which certificates you will trust, which we cover in the next section.

Click the triangle symbol next to VeriSign, Inc. to see their root certificates that have been bundled with Netscape. Then click the VeriSign Class 3 Public Primary Certification Authority and click the View button. You are shown the details of this certificate, including its X.509 properties. If you click the Edit button, you see the Edit Certificate Trust window, shown in Figure 9.12.

In this window, you can edit the settings for which you want certificates issued or signed by this authority to be trusted. As an example, if you visit a Web site that holds a certificate issued by VeriSign Class 3 Public Primary Certification Authority, you trust the identity of that Web site because it can be verified with that CA. Likewise, you trust e-mail messages that are signed with a certificate from this CA, and you trust software, or code, that is digitally signed with a certificate from this CA. In the Edit Certificate Trust window, you can modify the things that explicitly define to Netscape what certificates issued or signed by this CA should be allowed to identify.

Let's take a look at how Internet Explorer manages the same certificate. In IE 6.0, select Tools, Internet Options. Select the Content tab and click the Certificates button. Then select the Trusted Root Certification Authorities tab to see the list of CAs that come bundled with IE (see Figure 9.13). Notice that Netscape and IE each come with some of the same but also some different CAs. Who is making the decisions to bundle which CAs? Not you.

Select VeriSign Class 3 Public Primary Certification Authority and click View to see the contents of the X.509-based certificate. Click the Advanced button to see the functions that certificates issued by this CA can fulfill, as shown in Figure 9.14. Whereas Netscape refers to these as the Trust Settings, Internet Explorer refers to them as the Certificate Purposes.

Remember how we mentioned that the same root authorities preinstalled into Internet Explorer are also preinstalled into the Windows 2000 and Windows XP operating systems? Let's take a look at just where those root certificates are stored and how you can view them. Microsoft has provided an interface for managing certificates on your computer, and it is accessible through the Microsoft Management Console (MMC). Select Start, Run, type MMC, and click OK. A rather empty-looking MMC is displayed. We actually have to add the Certificates snap-in to get to the certificates. Select Console, Add/Remove Snap-in, and the Snap-In Manager pops up. Under the Standalone tab, click the Add button. Highlight the Certificates snap-in and click Add. For the option that says This Snap-In Will Always Manage Certificates For, select My User Account, and click Finish. Click Close and OK to finish up. You see a screen similar to Figure 9.15. By expanding Trusted Root Certification Authorities and then Certificates, you can see all of the same CA root certificates that are used with Internet Explorer. From here, you can manage all of these and other certificates. You can add, delete, and modify the “intended purposes” of each certificate, as shown in the figure.