What Are Digital Certificates?

A digital certificate is supposed to be the computerized equivalent of a passport. It proves a person's identity online and provides a means of legally valid signatures in some cases. In today's society, you might have many forms of identification, including a passport, driver's license, membership card, or similar type of ID card. Just as you can have many ID cards for many different purposes, you can have many digital certificates to serve you. A certificate is used to identify a person or a thing. It is a digital document, which is really a file stored on a computer that can be used to identify a person, server, or company. A server that is running a Web site usually has a digital certificate for your Web browser to authenticate the server and verify its identity. The digital certificate also contains the server's public key for use in establishing encryption.

The concept of digital certificates has been around since before the earliest days of the Internet. VeriSign made an early attempt at issuing digital certificates, thus marking its place as an identity authority on the Internet. Early on, VeriSign was primarily concerned with issuing certificates to identify Web servers for use in SSL connections. Since then, certificates have spread into use by government, businesses, and netizens (citizens of the Internet community).

The most popular systems of digital certificates today are based on three things:

• Public Key Infrastructure

• X.509

• Certificate Authorities

Public Key Infrastructure (PKI) is a system of creating, maintaining, distributing, and validating digital certificates. As a model of trust, the PKI system of X.509-based digital certificates can be thought of as a pyramid. At the top of the pyramid is the Root Certificate Authority. This Root Authority has ultimate responsibility for validating the trustworthiness of all certificates that it issues, as well as certificates issued by other Certificate Authorities beneath it. The Certificate Authorities, including the root, are also the central directories of certificates. They are the actual entities responsible for carrying out the goals of the PKI: creating, maintaining, distributing, and validating digital certificates.

A PKI does not have to refer to a system that uses CAs as the trusted authorities. In fact, the OpenPGP system can be considered a PKI in which responsibility for validating certificates is distributed among the people who use the system. Within a close group of friends, it might be easy to maintain trustworthy public keys. On a larger scale, trustworthy public keys and certificates depend on their acceptance within the Web of Trust (described more in Chapter 8).

When you hear people talk about digital IDs, digital certificates, and the like, they are usually referring to what is known as X.509. The many names all point to a single set of recommended practices known worldwide as the X.509 standard. X.509 is a recommended standard to which most digital certificates conform. The X.509 recommended standard has been actively developed by the International Telecommunications Union (ITU). The ITU, established in 1965, consists of members from countries across the world who have a mission that includes developing international telecommunications standards. Because the X.509 standard has not been officially approved beyond just a recommendation, companies and organizations use it as a framework but modify it to suit their needs. For this reason, the X.509-based digital certificates in use worldwide across the Internet do not all contain the same types of information.

PKIs are still maturing, and no agreed-upon PKI system or standards for PKI operations currently exist. Industry standards are still developing. Companies, individuals, and governments alike might choose to set up PKI systems in different ways. Many states have been developing legal frameworks for the use of digital signatures, most of which have been based on Utah legislation from 1995. Drafts have been written of a federal PKI system to dish out the passport equivalent of digital certificates.

Some people think that PKI and digital certificates are the answer to most of the Internet's security problems. Even the domain name system (DNS) can be secured using certificates. DNS is the protocol that translates host names (www.privacydefended.com) into IP addresses (172.16.2.100). The DNS serves as the phonebook of the Internet; you look up a name, and DNS gives you the number. The fact is, you use the DNS (or rather your software does) every time you surf to a Web site, send an e-mail, or do anything that involves traveling across cyberspace. Securing the DNS is just one example of digital certificates' answer to Internet security problems. Of course, digital certificates are used in SSL, e-mail, and other transactions requiring a high level of trust.

On the other hand, many people see the whole PKI, Certificate Authority, and X.509-based certificates as a complex solution that carries its own bag of problems. How will something riddled with loop holes, security problems, and arguable standards give us trustworthy solutions and answers? Some of the problems surrounding the use of digital certificates are discussed in the later section of this chapter, “Problems with Certificates.”

The Purpose of Digital Certificates

As mentioned previously, a digital certificate is supposed to serve as a valid identification for a certain entity, be it a company, a Web site, or an individual. Besides performing the role of an Internet passport, a digital certificate can provide some core security functions:

• Identification

• Encryption

• Authentication

Identification is achieved because a certificate is issued from a central authority that signs the certificate, essentially saying “Yes, this certificate has been verified as belonging to Bob.” Bob's certificate represents him on the Internet, and he can use it when exchanging e-mail with his mother, so she knows that it was really Bob who sent the e-mail, and not some imposter.

Bob's certificate can also be used for encryption. The certificate carries Bob's public key with it so that people can send him encrypted and private e-mail. If Alice wanted to send Bob a private e-mail message, she would find Bob's certificate either from a CA or from another trusted source, and encrypt her e-mail message with Bob's public key (contained in the certificate) before sending it. When Bob receives the message, he decrypts it with his private key. This functionality is based on the concept of public key cryptography, which is discussed more in Chapters 8 and 12. It is no different from the encryption and privacy that PGP provides.

Bob's certificate can also be used to authenticate him. If Bob needs access to a Web site that contains confidential company information, that Web site might require that Bob present his digital certificate. After Bob presents the certificate, the Web site validates the trustworthiness of the certificate by checking with a Certificate Authority that issued it.

Digital certificates carry a tangible value these days: legal nonrepudiation. For example, they can be used to sign a lease online safely and legally.

What Is in a Digital Certificate?

All this talk of PKI, X.509, and CAs can seem like nonsense until you have seen something tangible. The certificates are typically files that are stored on your computer, one of which is a public file that you can share with other people. Let's get inside an X.509 certificate and see what kind of information it contains.

We will look at one of the digital certificates for Foundstone, Inc., which has been issued by Thawte Consulting. By visiting the Foundstone Web site at https://www.foundstone.com with Internet Explorer 6.0, our Web browser downloads the Web site's digital certificate and validates its authenticity with the issuing CA, Thawte Consulting. Keep in mind that this process is the same for any Web browser, and the contents of the X.509 certificate which we are about to discuss will be the same whether viewed through Netscape Navigator, Opera, or any other Web browser. Although each Web browser might present the contents in different ways, it cannot change the contents.

After we have loaded the page for https://www.foundstone.com, we can select File, Properties in Internet Explorer 6.0 and then click the Certificates button. We will see the General properties of the certificate, as shown in Figure 9.8. These General properties summarize some of the contents of the certificate, which we will see in more detail under the Details tab. The main things we are concerned with are presented here under the General tab. We know that the certificate is valid, or else it would appear with a red circle and slash over the certificate symbol, denoting that it could not be validated. We see that the certificate has been issued by Thawte Server CA, which happens to be one of the CA certificates that comes bundled with Internet Explorer and Netscape Navigator (see the later section “The Almighty Certificate Authority”). Because Thawte Server CA is one of the CA roots that we trust, our Web browser was able to automatically query the CA to validate the Foundstone certificate. The process was transparent to us; the decision of trust was left to Internet Explorer more so than it was to us. We see also the valid timeframe for this certificate, which is from 8/15/2001 to 8/21/2002. It is quite typical for server or Web site certificates (and even personal certificates) to be valid for one to two years. By expiring certificates and renewing them, the owner takes less of a risk that the certificate will get lost, be stolen, or otherwise be compromised by an attacker.

If we want to see more details about this certificate, we can click the Details tab, shown in Figure 9.9. This displays what can be considered the raw X.509 properties. This is best explained when you consider the basic structure of an X.509 certificate. Table 9.2 describes some of the core fields with which you might be concerned.

Table 9.2. A Basic Description of What Makes Up an X.509 Digital Certificate

X.509 Field Name	Description
Version	This is the version of X.509 certificate that is being used.
Serial number	The CA that issued the certificate is responsible for giving it a serial number to distinguish it from other certificates that the CA creates.
Issuer	This is the name of the CA, or other entity, that signed this certificate. In our example, the issuer is Thawte Server CA. Anybody who wants to use this certificate must trust the entity that signed it. Root CAs sign their own certificates, essentially telling you “Here, this certificate is mine, I signed it, trust me.”
Valid from and Valid to	Certificates are valid for finite periods of time. The strength of the private key that is used to sign the certificate and the amount of money a subscriber pays for the certificate are some of the factors that determine a certificate's lifetime. A validity period is described by the date when a certificate becomes valid and the date it is valid to.
Subject	The subject gives the name of the subscriber to which the certificate has been issued. In our example, Foundstone is the subject. The subject name is intended to be unique across the Internet by breaking the name into components such as the following: CN—The subject's common name OU—The subject's organizational unit O—The subject's organization C—The subject's country
Subject public key	This is the subject's public key.

X.509 certificate can contain more fields, such as the Certificate Revocation List. However, the major pieces of information have been described here.

The path that the certificate took when it was originally created is also of interest. By selecting the Certification Path tab, shown in Figure 9.10, we can see who the issuing CA is for the certificate, and any other CAs or entities that might have signed it before it arrived at your Web browser. In our example, we only have one signing CA, which happens to be the same CA that issued the certificate. Thawte Server CA is at the top of the list because it is the first CA to have signed this certificate. A CA signs a certificate with its own private key to mark it with a seal of trust. That seal can be traced back to the CA, and is actually what you are checking on when you validate a certificate.