Step-by-Step Guide to Setting up a Certificate Authority
This step-by-step guide will help you set up a public key Certificate Authority (CA) in a network running the Microsoft® Windows® 2000 Server operating system.
A Certificate Authority is a service that issues the certificates needed to run a public key infrastructure. The CA could be an external commercial CA, or it could be a CA run by your company. The certificates enable a user to log on using a smart card, send encrypted e-mail, code-sign documents, and more. Since a CA is an important trust point in an organization, most organizations will have their own CA.
Microsoft Windows 2000 provides two types of CAs, determined by which policy modules are selected during installation—an enterprise CA or a stand-alone CA. Within these classes, there can be two types of CAs—a root or a subordinate. The policy modules define the actions that a CA can take when it receives a certificate request. Note that by changing the policy modules, it is possible to change the functionality of the system. A customer can write a policy module and customize the CA’s behavior using the Microsoft Platform Software Development Kit (SDK).
Typically, you should install an enterprise CA if you will be issuing certificates to users or computers inside an organization that is part of a Windows 2000 domain. You should install a stand-alone CA if you will be issuing certificates to users or computers outside of a Windows 2000 domain. An enterprise CA requires that all users requesting certificates have an entry in the Windows 2000 Server Active DirectoryTM services, whereas a stand-alone CA does not. Also, an enterprise CA can issue certificates that are used to log on to a Windows 2000-based domain, and a stand-alone CA cannot.
CAs are organized into hierarchies with the fundamental trust point—or root CA—at the top. All other CAs in the hierarchy are subordinate CAs, and are trusted only because the root is trusted. The enterprise root CA is the trust point in the enterprise. There can be more than one enterprise root CA in a Windows 2000-based domain, and thus more than one hierarchy. It is also possible to mix and match stand-alone and enterprise CAs in a hierarchy to best suit your needs.
Enterprise CAs have a special policy module that enforces how certificates are processed and issued. The policy information used by these modules is stored centrally in a CA object in Active Directory. This means that to set up an enterprise CA, you must have a working Active Directory and DNS server.
In a stand-alone hierarchy, the stand-alone root CA is at the top. Each new stand-alone root CA starts a new hierarchy. Again, it is possible to mix and match stand-alone and enterprise CAs in a hierarchy to best suit your needs.
A stand-alone CA has a very simple policy module and does not assume that Active Directory service is available. However, if Active Directory is available, then the stand-alone CA will take advantage of it.
Certificate Authority Requirements and Prerequisites
This section describes the setup requirements for each type of CA. You must meet all these requirements before installing the CA.
Enterprise Root CA
An enterprise CA is the root of a Windows 2000-based corporate CA hierarchy. You should set up an enterprise CA if the CA will be issuing certificates to users and computers within your corporation. For security reasons, the enterprise CA is typically configured to issue certificates only to subordinate CAs.
The enterprise CA requires the following:
Enterprise Subordinate CA
An enterprise subordinate is a CA that issues certificates within a corporation, but is not the most trusted CA in that corporation. (It is subordinate to another CA in the hierarchy.)
The enterprise subordinate CA requires the following:
Stand-alone Root CA
A stand-alone CA is the root of a CA trust hierarchy. You should install a stand-alone root CA if you will be issuing certificates outside of a corporation’s enterprise network. A root CA typically issues certificates to subordinate CAs only. For example, you want to issue certificates to your customers so they can access your Web site, and it is not feasible to give each one an account in your directory. Another example is if you intend to lock your root CA in a vault with no network access for security reasons, and want to allow only a few trusted people to access this server.
The stand-alone root CA requires administrator privileges on the local server.
Stand-alone Subordinate CA
A stand-alone subordinate CA is one that operates as a solitary certificate server, or exists in a CA trust hierarchy. You should set up a stand-alone subordinate CA when you will be issuing certificates to entities outside a corporation.
The stand-alone subordinate CA requires the following:
The common infrastructure documents specify a particular hardware and software configuration. If you are not using the common infrastructure, you need to take that into account when using this document. All names used throughout this guide are based on that set of instructions.
The most current information about hardware requirements and compatibility for servers, clients, and peripherals is available at the Windows 2000 Product Compatibility site.
Certificate Authority Setup
For the purposes of this step-by-step guide, you must be logged on as an enterprise administrator.
You now need to log on as an enterprise administrator; using our example, log on as Mike Nash.
Note: You will also need to log on as an enterprise administrator when setting up the enterprise intermediary and enterprise-issuing certificate computers.
To set up the CA
In this dialog box, you can change the cryptographic settings, such as the Cryptographic Service Provider (CSP), hash algorithm, and other advanced options. In general, you will not need to modify the default settings. Users who need to modify these settings must be very familiar with cryptography, Certificate Server, and the CAPI 2.0 architecture.
The list of CSPs will vary depending on the software and hardware that has been installed on the server. The Key length specifies the length of the public and private key pair. A value of Default in this box generates a key pair whose default length is determined by the selected provider. Microsoft recommends that you use a long key length, such as 1024 or 2048, for a root CA or an enterprise CA. (Note that a long key length is computationally more expensive, and may not be accepted by all hardware devices. For example, some smart cards may not accept certificates issued by a CA that has a 4096 bit key, due to space limitations on the card.)
The Use existing keys option allows you to use keys that were generated previously or to reuse keys from a previously installed CA. When installing a CA, you should almost never reuse keys. The exception to this is when you are restoring a CA after a catastrophic failure. You will then import a set of existing keys and install a new CA that uses those keys. In addition, if you are restoring a CA after a failure, you must select the Use the associated certificate check box. This ensures that the new CA has a certificate that is identical to the old CA. If you do not check this box, a new certificate will be generated that makes the new CA different from the old CA.
Note: The private key is always stored locally on the server, except in the case where a cryptographic hardware device is used. In such a case, the private key is stored in the device. The public key is placed in the certificate, and in the case of an enterprise CA, the certificate is published in Active Directory.
When the installation is complete, take the Certificate Request file you created to your CA for processing. If you are using a Microsoft Certificate Service to process this file, you can refer to the Step-by-Step Guide to Certificate Service Web Pages for details about processing the request.
When you have your new certificate, you can use the Certificate Authority MMC snap-in to install the certificate and enable your CA.
Verify Certificate Server Installation
Whether you created an enterprise CA or a stand-alone CA, you can quickly check to see if your installation was successful.
The simplest way is to open a command window, and type net start to see if the Certificate Service is running.
Removing Certificate Services
Installing a Subordinate CA Certificate from a File
This section is to be used only by people who created a certificate request file during installation of a subordinate CA.
Before you begin this section, take the certificate request file to your CA for processing. Your CA will provide you with a certificate for this file. If you are submitting this file to a Microsoft Certificate Service, refer to the Step-by-Step Guide to Certificate Service Web Pages for detailed instructions on how to submit the request file.
This section uses the Certificate Services snap-in. Refer to the Step-by-Step Guide to Advanced Certificate Management for more details.
Your CA is now installed and ready for verification.
Stand-Alone Policy Behavior
Certificate Server stand-alone policy behavior has changed. In the past, the default policy module immediately processed requests and issued the certificate. The new stand-alone policy makes the request pending until an administrator manually approves the request. This new behavior affects the stand-alone CAs only. Enterprise policy still processes the request immediately.
Installing Web Pages on a Remote Server
If the CA is an enterprise CA, the Certificate Services Web pages must be installed on the same computer as the CA. The CA needs to authenticate the client to ensure that it can request only the certificates that the client has permission to request. If the Web pages are on a different computer from the Web server, then the CA cannot authenticate the user.
Installing the CA and Web Server
The CA must be installed after the Web server to ensure that the Web pages are installed. If the CA is installed first, it still functions, but you may not be able to access the Web pages. You can enable the Web pages by running the command:
Upgrading Certificate Server 1.0
When you upgrade from Windows NT Server 4.0 to Windows 2000, the Certificate Services executable and dynamic-link library (DLL) files must be updated. Note that it is important to run the Dbcnvt.exe utility to convert the old version 1.0 database to the new format before the CA processes any new requests. Upgrades are not supported for any configuration that uses a version 1.0 database that has been modified.
This feature information was obtained from the Microsoft Windows 2000 website at http://www.microsoft.com/windows2000 and are linked from ActiveWin.com for your convenience and is subject to Microsoft's copyright. For the most accurate information please visit the official site.