Categories World Wide Web

Continued from Introduction

Digital certificates are often likened to driver's licenses: Both contain important information and are created by trusted authorities. And though driver's licenses are not easy to duplicate, fraud is made even more difficult by law enforcement personnel's ability to query a DMV database to check their validity. In a similar fashion, a CA issues digital certificates, and ultimately, the CA vouches for the information contained in the certificate. This information need not be complex--often it's little more than an e-mail address--but at some point the CA is staking its reputation that steps were taken to verify that the information in the certificate is accurate. In more advanced cases, CAs will even run a Dun & Bradstreet check on an organization before giving it a certificate of a certain level (or class). Who are these certifying organizations? Generally, they're well-established, trusted companies like AT&T, GTE, Thawte, and VeriSign. These trusted authorities certify other organizations who might, in turn, certify further organizations. For instance, the various components of Microsoft Internet Explorer (IE) 4.0 are signed by Microsoft; RealPlayer is signed by Real Networks. And both companies get their authority from VeriSign.

Organizations that certify at the highest level of such a hierarchy are known as root CAs. Although Microsoft Certificate Server 1.0 does not officially support CA hierarchies, a subsequent white paper from Microsoft titled "Creating Certificate Hierarchies with Microsoft Certificate Server Version 1.0" describes how to use CertSrv 1.0 and certification authority hierarchies with Microsoft Exchange Server Version 5.5 Service Pack 1. Microsoft Knowledgebase Article Q186012, "Creating Certificate Hierarchies," describes how to download this white paper (Hier3.exe) from the Microsoft Software Library.

A list of common CAs and root CAs is installed on your machine when you install a Microsoft or Netscape browser. In IE4, for example, choose "Internet Options" from the View menu, select the Content tab, and click the Authorities button to see which authorities are trusted for each of several types of operations. If you prefer, you can delete any of the CAs; if you receive a certificate that is ultimately signed by one of these CAs, however, you won't be able to verify the signer's identity. If you decide later that you'd rather have those CAs, you can reset the list by reinstalling the browser.

In theory, any organization can be a root CA. All that's required is for the CA to "self-sign" its certificate, and for recipients to accept the self-signed certificate. The problem is getting other people to take you seriously. Users inside your organization might be willing to trust the company, but external users (Web site visitors, for example) may well be more skeptical. Also, it's relatively straightforward for an organization to become a root CA for its internal users, either by modifying the installed list of CAs (using IE Administration Kit) or by instructing users to download the certificate from a secure internal site. Obviously, neither of these options is ideal if the certificates signed by the root CA are for use outside the organization.

Why would an organization want to be a root CA? Often, it's a matter of cost. VeriSign's OnSite license, for example, is priced from $4,000 for up to 500 users to $38,000 for up to 10,000 users (higher-volume licenses are also available). But an organization installing Certificate Server 1.0--which comes free with Windows NT Option Pack--pays nothing to issue client certificates. CertSrv 1.0 runs as a service under Windows NT, has no direct user interface, and works with both Microsoft and non-Microsoft browsers and Web servers. It uses Cryptographic Service Providers (CSPs) and the CryptoAPI under the hood and is accessed through several programmable objects and command-line utilities. Certificates can also be requested through included ASP pages, which in turn call those objects. Configuring CertSrv 1.0 can be confusing, but the MSDN article at http://premium.microsoft.com/msdn/library/partbook /mts/html/secureencryptedcommunication.htm has detailed steps for installing the product, creating a root certificate, and generating server and client certificates. Microsoft Windows 2000 will ship with an integrated public key infrastructure and CertSrv 2.0, which will have a more complete user interface, built-in support for CA hierarchies, and additional capabilities such as a time-stamping server.

Next: Digital Certificates

Published as PC Tech Feature in the 4/20/99 issue of PC Magazine.

Related Links
• Making E-Mail Secure -- PC Tech
• Internet Security Standards -- PC Tech