Chapter 6: Designing a Public Key Infrastructure with Certificate Services

---

The Internet is full of all kinds of people and companies that you have never personally met. Some may claim to be somebody they are not to fool you into revealing information about yourself, into allowing them to access your network, or into running their code. You need a mechanism for validating the identity of someone you will work with over a network whether you have met them or not. After all, how can you tell that the company you just received an important security patch from is really Microsoft and not somebody who just wants to trick you into installing a Trojan horse? This mechanism would ideally allow you to encrypt and sign content also. A public key infrastructure (PKI) is the mechanism that provides the services and components to validate the identity of a user and store the keys needed to encrypt and sign data.

In this chapter, you will learn about the elements that make up a PKI. You will learn about the server types required for a PKI and the management requirements for PKI. You will also look at extending the PKI to trust other organizations.

Introduction to Certificates and Public Key Infrastructure

There are three problems with exchanging information over a network:

• How do I know you really are who you say you are?

• How can I keep the information that we exchange secret?

• How do I confirm that the information you sent hasn’t been modified in transit?

These questions can be addressed with technology known as public key encryption and X.509 certificates (digital certificates). In the following sections we will be discussing public key encryption and the digital certificate technology that makes it possible. We will also look at what a public key infrastructure is and how it is used to manage digital certificates.

Public Key Encryption and Digital Certificates

Public key encryption is an encryption scheme based on the Diffie-Hellman algorithm, which was first released in 1976. It allows users to share encryption keys without the need for a secure channel. You generally use a tool to generate a public and private key combination. The public key is used to encrypt a message and can safely be shared with others over a non-secure connection because it contains no information about how to decrypt the message. The private key is used to decrypt the message and should be kept secret by the owner. Any message you encrypt with the public key of the combination can only be decrypted with the corresponding private key. If you wanted two-way encryption, you would need to exchange public keys or, as in the case of Secure Sockets Layer (SSL) and Transport Layer Security (TLS), use a symmetric key that is generated by the client and sent to the server encrypted with the server’s public key (see Figure 6.1 to see how PKI works when applied to SSL). Digital signatures are also handled with a public and private key combination; in this case, the private key signs the data and the public key is used to verify the signature. A digital signature is a hash of the data (the most popular algorithms for hashing are MD5 and SHA-1) that is encrypted using the private key. The public key is used to decrypt the hash and verify that the document has not changed and that the signature really came from the corresponding key of the pair.

Figure 6.1: How PKI works when applied to SSL

X.509 certificates, also known as digital certificates or just certificates, are electronic documents that contain information about the owner of the certificate, the public key of the owner, and the signature of the validator of the information in the certificate (the validator is called a certificate authority). The X.509 certificate contains a number of fields, including these most common ones (see Figure 6.5):

• Version number

• Serial number

• Algorithm identifier

• Issuer name

• Validity

• Subject name

• Subject public key information

• Issuer unique identifier

• Subject unique identifier

• Key identifier

Figure 6.5: The Details tab of the Certificate dialog box

There are different types of certificates for different applications. These applications will use certificates for everything from encrypting e-mail and securing web communications to encrypting files. Windows Server 2003 provides templates for generating certificates for various applications; these are called certificate templates. They provide the fields necessary for the application that uses the certificate. Table 6.1 shows the various certificate templates available for issuing certificates from Windows Server 2003 and the applications that use the certificates.

Table 6.1: Available Certificate Templates

Certificate Template	Applications That Use This Type of Certificate
Directory Email Replication	directory service e-mail replication
Domain Controller Authentication	client authentication, server authentication, smart card logon
EFS Recovery Agent	file recovery
Basic EFS	encrypting file system
Domain Controller	client authentication, server authentication
Web Server	server authentication
Computer	client authentication, server authentication
User	encrypting file system, secure e-mail, client authentication
Subordinate Certificate Authority	certificate authority
Administrator	Microsoft trust system, encrypting file system, secure e-mail, client authentication
Authenticated Session	client authentication
CA Exchange	private key archival
CEP Encryption	certificate request agent
Code Signing	code signing
Cross Certification Authority	certificate authority
Enrollment Agent	certificate request agent
Enrollment Agent (Computer)	certificate request agent
Exchange Enrollment Agent (Offline Request)	certificate request agent
Exchange Signature Only	secure e-mail
Exchange User	secure e-mail
IPSec	IP security IKE intermediate
Key Recovery Agent	key recovery agent
RAS and IAS Server	client authentication, server authentication
Router (offline request)	client authentication
Smartcard Logon	client authentication, smart card authentication
Smartcard User	secure e-mail, client authentication, smart card logon
Trust List Signing Microsoft Trust List	Microsoft trust list signing
User Signature Only Secure Email, Client Authentication	only signing e-mail (no encryption), client authentication
Workstation Authentication Client Authentication	client authentication

The main function of a certificate is to link a public key to the information about a user or computer contained in the certificate. Of course, you cannot trust the information in the certificate because it could have been forged or manipulated in transit. For instance, anybody can create a certificate and say that they are from Microsoft or from any other company. The strength of certificates comes from a trusted third-party certifying that the certificate information is valid and the document has not been altered in transit. The creation, verification, and revocation of certificates requires an infrastructure to help manage it.

Public Key Infrastructure

A public key infrastructure (PKI) is the technology, software, and services that allow an organization or organizations to securely exchange information and validate the identity of users, computers, and services. This infrastructure is made up of a variety of services and components, as the following list illustrates:

• Digital certificates

• Certification authority (CA)

• Certificate revocation list (CRL)

• Technology to distribute certificates and certificate revocation list

• Tools to manage the PKI

• Software that uses PKI (web browsers, web servers, encrypting file system (EFS), Routing and Remote Access Server (RRAS), Virtual Private Network (VPN), Internet Authentication Server (IAS) for authentication, Active Directory, etc.)

• Certificate templates

These services are responsible for issuing, managing, revoking, and verifying digital certificates that are used on your network.

At the heart of the PKI is the certificate authority (CA), which verifies the information in the certificate and then digitally signs the certificate with its public key. A CA can be public (third-party like Verisign, Thawte, or RSA), or you can set up a private CA in your own organization by installing a root CA on Windows Server 2003 in your organization. By signing the certificate, the CA is essentially making a statement that the person sending the certificate is who they say they are based on the proof of identity that the CA required. PKI-enabled applications must be set up to trust the CA, which means that you trust the certificate.

A certificate is created through a separate tool or a tool contained in a PKI-enabled application. The certificate contains the public key of the requestor and the proper fields for the type of certificate requested. The certificate is then submitted to the CA (through a website, e-mail, or other means) which verifies the information, signs the certificate if the information checks out, and returns the certificate to you. Verification can come in many forms, from confirming that you own the DNS domain for your web application to requiring you to meet in person with a representative and provide two or three forms of identification like a driver’s license, Social Security card, or passport. The amount of verification depends on the type and use of the certificate. You then install the certificate into your application to provide identity validation and encryption.

Of course, a certificate can’t vouch for the character of the person or company, but at least you know they are who they say they are. If someone tries to alter the certificate, you will be alerted by the PKI-enabled application (like a web browser) that participates in the PKI process because the hash in the signature will not match the one in the certificate, so you can detect a forged certificate. You can view and configure certificates in PKI-enabled applications. The client-side certificates used by Internet Explorer or Outlook Express can be managed through Internet Explorer by following these steps:

1. Start Internet Explorer.

2. Choose Tools Internet Options to open the Internet Options dialog box.

3. Click the Content tab, shown in Figure 6.2.

   
   Figure 6.2: The Content tab of the Internet Options dialog box

4. Click the Certificates button to open the Certificates dialog box.

5. Click the Trusted Root Certification Authorities tab, shown in Figure 6.3. Here, you will see all the certificates that are trusted.

   
   Figure 6.3: The Trusted Root Certification Authorities tab of the Certificates dialog box

6. Double-click any one of the certificates listed in the list box to open the Certificate dialog box, shown in Figure 6.4.

   
   Figure 6.4: The General tab of the Certificate dialog box

7. Click the Details tab to view the fields that are contained in the certificate (see Figure 6.5).

8. Close the Certificate dialog box.

9. Close the Certificates dialog box.

10. Close the Internet Options dialog box.

Certificates can also be configured on the server side through the Internet Information Services MMC. The tool allows you to generate a web server certificate, submit the certificate to a CA, and install the certificate on the web server. You can then use the tool to identify the virtual directories on which you want to enable encryption through the virtual directory Properties dialog box.

When identifying systems that need the added protection of PKI, you need to analyze the cost of implementing PKI versus the value of the data that needs to be protected. PKI can be used to secure e-mail and communications with customers, employees, and other organizations over the Internet or to implement digital signatures for software components. You should implement some kind of PKI if you need to rely on the following technologies in your applications:

• Smart cards

• Extensible Authentication Protocol–Transport Layer Security (EAP-TLS)

• IP Security (IPSec)

• Secure Sockets Layer (SSL)

• Digital signatures

• 802.1x

• Encrypting File System (EFS)

• Software code signing

• Authentication

• Secure e-mail

To better illustrate the use of certificates, let’s look at a familiar technology that is based on PKI, Secure Sockets Layer (SSL). This technology solves two problems that occur when trying to secure a transaction over the Internet: verifying the vendor’s identity and securely transmitting data:

SSL begins with the merchant creating a certificate. The process of creating the certificate may vary from vendor to vendor, but they all need to provide a tool to produce a public and private key pair and collect some information about the creator.

Suppose you buy something online for your significant other’s birthday. You navigate to the website and select your product and then select checkout, which starts a secure session. You can now enter your personal information and credit card information without the risk of someone eavesdropping on the network connection and stealing the information (although you may still be vulnerable to being conned, or the vendor’s database could be infiltrated through lax security measures, problems that SSL does not fix).

The client requests the secure site by using the HTTPS protocol. This will establish a connection to the server on port 443 by default. The client will request the certificate from the server (see Figure 6.7). It will look at the CA information and verify that the certificate has not been altered since it was signed by the CA, that it has not been revoked by the CA, and that it is a trusted CA. If something does not check out, you will get a warning similar to the one in Figure 6.6 and you can decide how to proceed.

Figure 6.6: Warning in Internet Explorer

Figure 6.7: Client requesting certificate from the server

If you don’t get a warning, you can assume the server operator is associated with the DNS domain that contains the website. The server could also at this point request a certificate from the client to verify the client’s identity. This is an optional step in SSL and usually only used if you are working with a partner organization or a smart card technology.

The client will then extract the public key and use it to encrypt a session key that the client generates. This can be seen in Figure 6.8. The session key will be sent to the server encrypted with the public key (see Figure 6.9). This key is a symmetric encryption key that the server will then use to send encrypted information back to the client. The client will use the key to decrypt the information and send any response back to the server by encrypting the information first and then sending it to the server. You have now encrypted the data without revealing your keys, thereby making it safer.

Figure 6.8: Client verifies certificate signature and uses public key to encrypt response.

Figure 6.9: An encrypted response with the session key is sent to the server.

Generally, if you were setting up a secure public website, you would pay for a certificate from a trusted root CA like Verisign. Browsers ship with the CA’s certificate installed in them, so the user will not receive a warning when they try to connect to the site, which is why you should use a third-party CA on your public servers. But there are cases in which you want to use certificates with partners or even internally in your company. You can use a third-party CA, but because you may require a lot of certificates, that could cost your company a lot of money for internal use. You trust yourself, so you could become the CA by installing certificate services on Windows Server 2003. You would need to know how to design and secure a PKI infrastructure if you need to become your own CA.

---