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
|Figure 1. CAs are an important component of an
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
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
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
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).
|Figure 2. The installation process starts at
the Add/ Remove Programs applet in Control Panel.
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
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
|Figure 5. When choosing a storage location, it’s
a good idea to keep log files on a separate physical drive from the
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.