9.1 What Are Certificates? | Securing Windows Server 2003

Imagine that you need to communicate with a secure web site on the internal corporate LAN. This is not an uncommon occurrence, as many web sites provide sensitive data in your environment. In this case, you want to change your health benefits information with your human resources department. You must be sure of two things to be confident that this communication is protected: the data transmission must be encrypted, and the web server must be who it says it is. If the data transmission is insecure , a malicious user could capture the network traffic and obtain or modify the sensitive data. If the web server is replaced or spoofed, your communication is vulnerable to a man in the middle attack in which an attacker becomes the middleman between your computer and the intended server.

A man in the middle attack is also frequently referred to as a bucket brigade attack , referring to the historic method of firefighting by passing buckets.

By now you're thinking that authentication by a reasonably secure mechanism such as Kerberos can provide this assurance. However, we must remember we're talking about web traffic as a communications channel. There is no guarantee that the web server understands Kerberos at all, and even less of a chance that there is a safe integration between Kerberos and the web server. (Microsoft's technologies in this area actually do provide this integration, so this is just an example.) Also, remember that Kerberos provides tickets and proves authentication. It is not designed to provide generic keys for any requesting application, and it does not protect any network traffic but its own.

A public key certificate (just certificate for short) is simply a document that contains identification information about the holder (or subject) and the public key portion of the key holder's public-private key pair. A certificate is issued by a certification authority (CA), which also digitally signs the certificate with its own private key to guarantee the authenticity of the certificate. If the recipient of information protected by a certificate trusts the integrity of the certification authority that issued the certificate (in the example, if the recipient trusts the issuer of your certificate), the certificate ”and the information it protects ”can be trusted. Although private certification authorities within your organization are known to be trustworthy, others may not be and must be evaluated to determine whether you should trust them. Details about establishing trust and the criteria used to decide which public authorities to trust are provided later in this chapter.

Certificates are most often used for identity authentication and secure exchange of information over an untrusted network. Because they contain a public key, a sender can use that key to encrypt information that only the trusted holder of the corresponding private key can decrypt. For example, Alice can obtain Bob's certificate and use the public key it contains to encrypt data. Only Bob has the corresponding private key, so only Bob can decrypt that data.

Similarly, the holder of the certificate's private key can use that key to encrypt information such as a hash of a message, creating a digital signature. All holders of the certificate can use that public key to decrypt and verify the digital signature in the message and verify its authenticity. Bob, for example, may want to reply to Alice with nonconfidential information. However, he wants to prove that the information came from him. He can use his private key to encrypt a hash of the message and send that hash along with the message. When Alice decrypts the hash with Bob's public key (from his certificate) and determines that the hash is authentic , she knows two things: Bob sent the message, and the message hasn't been tampered with.

9.1.1 Certificate Concepts

As I've said earlier in the book, a certificate is a binding of a public key to an identity. Any certificate has three very important components: the public key, the identification information, and the digital signature of the certificate. These components provide enough information to complete our desired tasks such as authentication, encryption, and digital signature creation. Because it contains only essential information, a certificate tends to be rather small ”2KB or less is average. As we'll see during our discussion of certificate deployment later in the book, this small size is one element that makes certificate deployment a bit easier than if they were huge. And even when certificates are customized (for example, by use of a custom certificate template) to add additional information, they tend to stay small.

The four separate types of certificates are generally defined by their intended use and subject type ( subject is just a fancy word for the holder of the certificate):

End-entity or personal certificates: These certificates are issued to users and are used for commonly recognized certificate tasks such as authentication and digital signature creation. Because certificates may have different purposes and strengths, one user may hold several certificates. Each end-entity certificate is signed with the key of the CA that issued the certificate.
Server and computer certificates: Servers and many computers on a network must also prove their identity to other entities. In the Windows Server 2003 family, domain controllers must all have certificates to prove their identities. These certificates allow domain controllers to identify themselves to other domain controllers and aid in secure communication.
Software publishing certificates: These certificates are usually issued to one or more software developers for the purpose of digitally signing software before production or deployment. This digital signature allows the developer to prove that the software comes from a trusted source and that it is unmodified since its creation (e.g., uninfected by a virus). These certificates are usually owned by a role holder ”that is, someone or something that performs a specific task, such as software signing. It may be one or more people or one or more processes or may be transferred as roles change in a company.
Certification authority certificates: Certification authorities digitally sign all end-entity certificates before issuance. These certificates are signed with a specific private key corresponding to the public key contained in the certification authority's certificate. This private key is usually the most important component in a public key certificate environment, since compromise of this private key jeopardizes the trust of the certification authority. Even the certification authority's certificate is signed ”either by its parent in a hierarchy or self-signed in the case of root certification authorities.

Regardless of the type or intended use of the certificate, all certificates contain the same type of information. This information is simply used in a different way, depending on its type and the application using it.

Certificates are formatted in a regimented yet flexible manner. The definition of this format is contained in Request for Comments (RFC) 3280 ”Internet X.509 Public Key Infrastructure. This RFC defines the X.509 Version 3 (X.509v3) certificate , which is the current standard for public key certificates. A large number of associated standards precede and complement RFC 3280, and many technologies interoperate with data formatted to this standard.

This is an example of an X.509v3 certificate in base-64 encoding:

Notice two things about this certificate. First, you cannot read it. It is encoded for computer use ”not for security as much as for simplified use by the computer. This encoding normally employs the Public Key Cryptography Standard #7 (PKCS #7) format, as defined by RSA Labs. Plenty of programs are available to interpret this information for you. Second, notice how small it is. As I've said, one of the valuable properties of a certificate is its ease of deployment. Because this certificate is so small, it can easily be distributed by almost any means without consuming significant bandwidth.

The same certificate, when viewed through the Windows Certificates snap-in, looks much different. This is because Windows interprets the raw data contained in the certificate and presents it in a simple, readable format. Notice in Figure 9-1 the three tabs to display different information about the certificate:

General: Displays basic information including the state of the certificate, the entity (or subject ) that it was issued to, and the original issuer. This is a summary-style display of the information.
Details: Displayed in Figure 9-1, this tab contains the information from the certificate including the public key, cryptographic algorithm, and subject name .
Certification Path: Shows the certificate hierarchy that issued the certificate. Each CA in the hierarchy between the issuing CA and the root CA is shown with a status for each of those certificates.

Figure 9-1. Display of a public key certificate in Windows

9.1.2 Benefits of Public Key Certificates

Why would you want to use public key certificates in your corporation? Simply put, they are the best way to establish trust and provide a method for secure communication among users in your corporation.

Numerous applications use certificates for securing their data. In the appendix, I discuss how Microsoft Outlook uses certificates for data encryption and digital signature. But this is only one of a variety of uses. Applications of certificate-based cryptography can also include securing any data communication between users, providing authentication of users, and establishing trust that a user is who he says he is. Applications from Microsoft and other developers that take advantage of these features currently exist. You've already read about IPSec's use of certificates for authentication in Chapter 8. IIS also uses certificates for SSL-based communication and authentication and is covered in Chapter 13.

The one nice advantage that authentication through public key certificates provides is portability. Other online authentication protocols such as NTLM and Kerberos require extensive interaction and a reasonably chatty network protocol to provide their authentication. Public key-based authentication, on the other hand, is more processor intensive but far less interactive. An entity can prove its identity and establish a shared secret key with a minimum of network traffic and without involving many (if any) third-party authentication servers.

Any application has the ability to make use of certificates. As I'll discuss in the next section, a rich set of programming interfaces is made available in Windows Server 2003 to obtain, manage, and use certificates. Similar interfaces are available in many Windows client operating systems. Using these interfaces, custom applications that take advantage of the enormous security that certificates provide can easily be written. The only caveat is that an application must be written specifically to use this type of security. Trying to append public key certificate awareness to an existing application is usually unsuccessful , as the technology is not fully designed and integrated into the application.

9.1.3 Where Do Certificates Come From?

Certificates usually come from dedicated certification authorities. Though there are a few well-known public certification authorities such as Verisign and Thawte, there are as many certification authorities to choose from as there are snowflakes . However, one important question must be answered before selecting a certification authority: do I create my own certification authority within my enterprise, or do I obtain certificates from a third party? To use the correct terminology: do I use a private (internal) or a public (external) certification authority?

Certificates don't always come from certification authorities. Some applications may be unable to function without a certificate that's specifically configured for the application. Most of these applications will check to see if such a certificate exists, and if not, they will generate their own. These certificates are known as self-signed certificates. This is because the local computer ”as opposed to a certification authority ”provides the digital signature for the certificate. The Encrypting File System (EFS) is one example of an application that behaves in this fashion.

A self-signed certificate is useful for the application that generated it. It will contain the same information as a certificate from a certification authority, but it is its own root certificate. The benefit to this certificate is that it can be created easily and used to provide some application-specific security. However, you do not get the same level of assurance from a self-signed certificate, as it was not issued by a certification authority. There is no real binding of identity to the key.