7.5 Certificates for the WWW

There are several types of certificates in use on the WWW. For example, every CA that issues certificates must have a certificate. This certificate, in turn , is either self-signed or signed by another CA. Next, every SSL/ TLS-enabled Web server must have a server or site certificate to authenticate itself to browsers. Similarly, if certificate-based authentication is required by the server, each user must have a personal certificate. Finally, many software publishers use certificates to digitally sign code distributed over the Internet. As discussed next , the four types of certificates are named differently by different software vendors . For example, Figure 6.4 illustrates the Certificate Manager of Microsoft s Internet Explorer. The Certificate Manager can be used to manage certificates that belong to the actual user of the browser, other people, intermediate CAs, and trusted CAs. In this terminology, the former two classes of certificates refer to personal certificates, whereas the latter two classes refer to CA certificates. As illustrated in Figures 6.5 and 6.6, the Opera browser does only distinguish between personal and CA certificates.

7.5.1 CA certificates

A CA certificate certifies that a public key actually belongs to a CA. As mentioned above, such a certificate may either be self-signed or signed by another CA.

In the first case, the certificate is signed with the private key that belongs to the public key that is certified and that is attributed to the certificate owner (i.e., the CA). Note that every CA can issue a selfsigned certificate, and that the assurance such a certificate provides is not very convincing (to say the least). In fact, a self-signed CA certificate says something like ˜ ˜I am CA such and such. My public key is such and such. Trust me.
In the second case, the certificate is signed with the private key of another CA. To verify the certificate, however, the public key of the other CA is needed. To make sure that this key is in an authentic and integer form, it should be provided as part of a public key certificate. Again, this certificate can be self-signed or signed by another CA. Consequently, the verification of such a CA certificate leads to a recursion. The recursion continues until a root certificate is found (i.e., a certificate that is trusted by default).

In practice, it is common to distribute software that makes use of CA certificates with a preconfigured list of trusted root certificates. Assurance then results from the way this list is managed by the software developer or distributor. For example, in Microsoft s Internet Explorer, the trusted root certificates that are preconfigured and come along with the software distribution can be found in the trusted root CA tab of the Certificate Manager (as illustrated in Figure 6.4). The list includes several dozens of commercially operating CAs. Similarly, in the Opera browser, the trusted root certificates can be found in the ˜Certificate authorities panel (as illustrated in Figures 6.5 and 6.6). In either case, it is possible to import, export, and delete trusted root certificates.

The fact that browsers are packaged and shipped with lists of preconfigured and trusted root certificates must be considered with care. A user who does not alter this list in his or her browser will automatically and implicitly trust all certificates that are issued by any CA from that list. This is transparent to him or her. Sometimes this level of trust is appropriate, but sometimes it is not. For example, if you go through the list of trusted root certificates in your browser, you will see that there are some root certificates you would not immediately trust if you were asked off hand. To make things worse , trusted root certificates tend to have unreasonably long lifetimes. ^[20] Some of them will expire not before 2028 or 2036. The preferred way to ship browsers would be to package them with empty lists and to have users import certificates from the CAs they trust. Unfortunately, this is not likely to happen anytime soon ( mainly because it is uncomfortable for the user).

7.5.2 Server or site certificates

In the previous chapter we saw that the SSL and TLS protocols require that a server authenticates itself to a browser using a public key certificate. Such a certificate is called a server or site certificate. Every SSL/TLS-enabled Web server must be equipped with a server or site certificate, and there are many companies that provide such certificates. ^[21]

If a Web server provides a certificate that is issued by a CA found in the browser s list of trusted CA certificates, the certificate is silently accepted. If, however, a Web server provides a certificate that is issued by a CA not found in the list, the user is prompted whether he wants to accept it and proceed accordingly . For example, Figure 7.2 illustrates the Security Alert panel that Microsoft s Internet Explorer pops up when a server provides a certificate that is not signed by a trusted CA. In this example, the server certificate is valid (i.e., it has not expired yet) and the certificate matches the server s domain name . The only problem recognized by the browser is the fact that the certificate is digitally signed by an unknown and untrusted CA. In this situation, the user is asked whether or not he or she wants to proceed, and whether he or she wants to view the certificate s details, respectively.

Figure 7.2: Microsoft Internet Explorer s Security Alert panel, which is displayed if the browser does not know or trust a server or site certificate. ( 2002 Microsoft Corporation.)

Unfortunately, users tend to click ˜Yes buttons whenever they appear simply to continue their work as soon as possible. There is hardly any user who carefully reads messages that appear in security alerts. Against this background, any browser that automatically displays some relevant details about server certificates is advantageous from a security point of view. For example, the Opera browser does so and automatically displays information about the server or site certificate, such as the certificate name and its issuer. Consequently, the user is automatically confronted with some information that may help to make more intelligent decisions about the validity of server or site certificates.

7.5.3 Personal certificates

Each user can have zero, one, or several personal certificate(s) to authenticate himself or herself to SSL/TLS-enabled Web servers that require client authentication. For example, in Microsoft s Internet Explorer, the Certificate Manager can be used to select a personal certificate.

As illustrated in Figure 7.3, this certificate can then be looked at in a special panel. In this example, the certificate is issued by VeriSign for Rolf Oppliger. ^[22] The certificate expired on December 16, 2001. Further information about the certificate is available by clicking at the Details and Certification Path tabs (as illustrated in Figures 7.4 and 7.5). The certificate s details show the fields of the X.509 certificate, whereas the certification path illustrates the certificate chain that is used to verify the certificate. In this example, the certificate of Rolf Oppliger is issued by the VeriSign Class 1 CA, and the certificate of this CA is issued by the VeriSign Class 1 Public Primary CA.

Figure 7.3: Microsoft Internet Explorer s Certificate panel. ( 2002 Microsoft Corporation.)

Figure 7.4: The ˜Details tab of Microsoft Internet Explorer s Certificate panel. ( 2002 Microsoft Corporation.)

Figure 7.5: The Certification Path tab of Microsoft Internet Explorer s Certificate panel. ( 2002 Microsoft Corporation.)

7.5.4 Software publisher certificates

As will be discussed in Chapter 10, code signing is getting increasingly important to protect the authenticity and integrity of software distributed over the Internet. A digital signature computed for and distributed with software is sometimes also referred to as ˜ ˜digital shrink-wrap . It provides a feature similar to shrink-wrapped software packages (meaning that it is difficult to modify the software without giving the recipient a possibility to detect the modification).

Digitally shrink-wrapping software basically means that the software publisher must compute a digital signature for the software, and that the software must be distributed together with the digital signature. Anybody in possession of the corresponding public key can verify the digital signature and authenticate the source of the software accordingly. Again, it is important to distribute the public keys that are necessary to verify the digital signatures in an authentic and integer form. This is where software publisher certificates come into play. A software publisher certificate basically certifies the authenticity and integrity of a software publisher s public key. Such certificates are typically issued by commercially operating certification service providers.

^[20] Note that browsers do not currently check the revocation status of any certificate at all. The only time a browser knows that a site certificate has been revoked is when it eventually expires . It is possible and very likely that this behavior will change in the future, and that certificate revocation checking will be adopted in one way or another.

^[21] The long lifetimes are due to the fact that it is very uncomfortable to have trusted root certificates that expire. This has motivated certification service providers to use root certificates with very long lifetimes.

^[22] Some of these companies are mentioned at the end of the chapter.