Respecting Authority

CAs play a vital role in managing identity between networks and aren’t difficult to install—as long as you plan wisely.

• By Michael Chacon
• July 01, 2001

As I discussed last month, centrally managing identity within and between network infrastructures is becoming an essential component of information systems. Recognizing this fact, Microsoft has made Certificate Authority an important aspect in the deployment of Windows 2000 technology. This is realized in the ability of Win2K CAs to interoperate with third-party external and internal CAs. The main security solutions supported via certificates in Win2K are secure e-mail through encryption and signing; Web site authentication; software code signing; smart card logon; and, of course, IPSec and EFS.

CAs don’t exist in a vacuum. They’re part of an overall public key infrastructure (PKI), and this is the case in Win2K as shown in Figure 1. The major components of the PKI in Win2K are the Win2K Certificate Services, the Microsoft CryptoAPI and cryptographic service providers (CSP), and the certificate stores for managing the certificates once they’ve been created.

Figure 1. CAs are an important component of an overall PKI.

The CSPs are the actual software or hardware components that provide the encryption services for the CA. The standard for Win2K is the Microsoft Base cryptographic service provider, which supports 40- or 56-bit keys in alignment with U.S. export rules. If you need stronger keys, you can use third-party CSPs. In addition, if you want to develop custom security applications that may demand specialized certificates you can write those applications using Microsoft CryptoAPI. (For more details on CryptoAPI visit http://msdn.microsoft.com/
library/ default.asp? URL=/library/psdk/sdkintro/contents_49d7.htm).

The Sum of its Parts
What we’re specifically interested in here are the various components that make up the Certificate Services. The CA is accessed via the Entry Module, which is a DLL that processes Public Key Cryptography Standard (PKCS) requests for certificates. This Entry Module supports both RPCs and HTTP and provides a standards-based method for certificate requests. The requests are queued until passed to the Policy Module for processing.

Another significant component is the Win2K CA default Policy Module. As with the Entry Module, the Policy Module is a DLL that can be customized for use by particular applications in a given environment. However, Microsoft recommends that you customize the Policy Module only with standalone CAs, as any modification with the enterprise CA might interfere with its integration with Active Directory.

The Policy Module determines whether the administrator approves a certificate request, denies it or leaves it pending for a manual decision. The default Policy Module covers both enterprise CAs and standalone CAs. A standalone CA is characterized by its lack of integration with AD. This lack of integration means there’s a larger administrative burden in the authorization and distribution of certificates. The standalone CA Policy Module sends certificate requests to a queue that’s managed manually by the administrator. With a standalone CA, there isn’t a directory to pass identity information to the CA, so there’s no way to automatically verify the authenticity of the requestor. Another option is to configure the standalone CA to honor all certificate requests without identity verification, which you may want to use for certain Web sites.

The other type of CA is the enterprise CA, characterized by its integration with AD. This is more useful because AD contains information such as user names, group memberships and templates that can be used to build certificates. AD integration is also useful because the directory’s aware of all other CAs in each domain, providing a centralized administration point.

Regardless of the CA type, the Policy Module evaluates information from the request against a directory, other database or even an external authority to determine the validity or appropriateness of a request. The Policy Module can also insert specific attributes into the certificate that can be used to secure access or set limits to functions within applications.

One advantage of the enterprise CA is the ability to use Certificate Templates that the Policy Module can use to create various types of certificates. Certificate Templates are stored in AD, and different types of certificates can be issued to users and computers based upon identity as instantiated in the directory. A standalone CA can’t use templates, and the requests must contain all the information necessary to build the certificates.

Another major component of the Win2K CA system is the Exit Module. Like the other modules, the Exit Module is a DLL that can be customized by developers for particular applications or environments. The Exit Module formats the certificate built and issued by the CA for transmission in the appropriate protocol to the requester. The various default formats the Exit Module supports are LDAP, HTTP, Win2K supported file systems, SMTP and ODBC. The default enterprise Exit Module publishes certificates to AD, and the default standalone Exit Module publishes certificates to the local file system for subsequent manual distribution.

All the transactions involved in requesting and creating certificates are stored in the Certificate Database. These transactions include the serial number and expiration dates of the certificate, which bookend a complete audit trail from request to expiration. The database also includes a record of the certificates revoked by the administrator. The default location of the transaction log files for the certificate database is \%SystemRoot%\System32\Certlog /. During installation of the CA, you can change this location and also specify that the logs and actual database be stored on separate physical drives for availability purposes.

Getting Started
The basic installation process for a standalone or an enterprise CA is basically the same. However, there are a few differences. The first is that you must be logged on as a member of the Domain Administrators group for the enterprise CA, and as a member of the Local Administrators group for the standalone CA. The Domain Administrators authentication gives you access to AD, which the enterprise CA requires.

As with most other Win2K services, the installation process begins at the Add/Remove Programs applet in Control Panel. Click on the Add/Remove Windows Components icon and select the Certificate Services check box (Figure 2).

You’re presented with a warning about how the computer can’t be renamed nor can it join or be removed from a domain after the CA is installed.

After acknowledging this warning by clicking Yes, you’re presented with the first screen of the installation wizard. Figure 3 shows that the account is logged into a Local Administrator account—the enterprise options are grayed out and there’s a message that displays the need for membership in the Domain Admins group to create an enterprise CA.

Figure 3. If you’re not a member of the Domain Admin group, the wizard’s enterprise options will be grayed out.

Click the Advanced Options checkbox if you don’t want to use some of the defaults for the CA. If you select this box and click Next, you’re presented with a screen (Figure 4) where you can change the Cryptographic Service Provider, the Hash algorithm, the key length or choose to use an existing public/private key pair. The last one’s useful if you need to move the CA to another machine or restore the CA.

Figure 4. If you click the Advanced Options box, the next screen gives you options to make a variety of changes, including the CSP, Hash algorithm and key length.

Once you’ve modified the options or accepted the defaults for the CA configuration, you’re presented with a screen to identify the CA (Figure 5). The information you enter can’t be changed after completing the installation.

Figure 5. When choosing a storage location, it’s a good idea to keep log files on a separate physical drive from the actual database.

Clicking the Next button brings you to the storage locations (Figure 5). As with all transactional databases, it’s a good idea to keep your log files on a separate physical drive from the database. It’s critical that these locations are absolutely secure, as they’re the foundation for your CA. If these locations are violated, then your CA loses any credibility for providing secure authenticated certificates.

With the standalone CA, all configuration information and issued certificates will be stored in the Shared Folder for subsequent distribution to the client requesting the certificate. With an enterprise CA, the location is usually AD. After completing all the configuration information, the software’s installed on the server. If IIS is running, it’ll be stopped until the installation is complete.

Wrapping it Up
After all files are copied, you’ll get the final screen of the installation wizard, the Finish button. After installing the CA, you manage it from the Certification Authority Console, which is added as any other MMC snap-in. Figure 6 is an example. It has the snap-in for the Certificate Authority and the one for the current user’s certificates.

Figure 6. Once the CA is installed, you can manage it from the Certificate Authority Console as an MMC snap-in.

You can see the certificates and failed requests as well as the ability to start and stop the service. It also allows you to add Exit and Entry Modules.

As you can see, installing a CA is very easy, but this shouldn’t be a reason to just slap one in. If you don’t plan for it properly, you’ll surely have to remove it and start over from scratch. You should build your first one in the lab and see how it functions with the clients and applications you intend to support. One thing’s certain—whether you manage a CA or buy a CA as a service from an external organization, you’ll have one integrated into your future. You’d be well served understanding how a CA works and how your organization can take advantage of certificates to expand the functionality of your information system.