Over the last several years, using the public key infrastructure (PKI) to authenticate users and secure network communications has become more popular. Rather than being one technology, PKI is a combination of services, encryption technologies, and PKI-enabled applications. PKI's basic premise is the use of digital certificates to identify users and machines and to securely transmit traffic between them.
On the authentication level, these digital certificates are similar to a passport. Just as a government authority issues a passport to validate your identity to immigration officials, a Certificate Authority (CA) issues digital certificates to verify your identity to a network application. For PKI to work, both parties must trust the CA so that they can assume that the digital certificate accurately and truthfully identifies users and resources. For example, let's say I connect to a Web server to order a book. When I get ready to connect to the bookstore’s ordering site to enter my credit card number, not only do I need to ensure that the site has a digital certificate that confirms its identity, but I also need to trust the CA that issued the digital certificate. To see a list of the CAs that you can trust, go to the Internet Explorer (IE) Tools menu, select Internet Options, select the Content tab, click the Certificates button, and select the Trusted Root Certification Authorities tab. As you can see, trusted CAs are usually companies such as VeriSign and SecureNet.
Until now, we've been concerned only with verifying identities—in this example, the secure ordering site for an online bookstore. However, not only do we need to know that we're sending our credit card number to the right server, but also that we've securely transmitted that information. For this last part, we need to get the PKI key.
When the CA issues the digital certificate to the bookstore’s Web site, it also issues a pair of keys—one public and one private—to the site. Various applications use this key pair in different ways so that only the intended recipients can read the encrypted data. In our example, we need to use the Web site’s public key (or a key derived from the public key) to encrypt the credit card number before sending the order across the Internet. Anyone can see the packets in transit, but only the private key holder(the bookstores Web site) can unencrypt the packets.
In addition to securing Web sites and Web communications, network applications can use PKI to secure email, sign software digitally, support smart card logons, provide IPSecurity (IPSec) authentication, and encrypt data locally through the Encryption File System (EFS). Although each application or service functions uniquely, they all require using PKI to issue and use digital certificates. If we relied on a third-party CA in each of these situations, the number of certificates that users needed would quickly make the issuing process costly and difficult to manage. To overcome this limitation, Windows 2000 includes Certificate Services to let you set up your own CA. Using your own CA is appropriate when you need to provide security to internal users and resources—for example, for creating a secure intranet Web server or designating a recovery agent for EFS.
I've given you an overview of how PKI works and why it's beneficial. In future columns, I'll show you how to add Certificate Services to your Win2K network. As you explore Certificate Services, you might find that most of the documentation provides more theory than practical how-to information. I'll try to overcome the theory by providing the practical hands-on information you need to implement Certificate Services.
Register
