Setting up certificate services

In part 1 of this series (”
Why set up a certificate server?
“), I discuss some of the issues involved in setting up a certificate server. In part 2, I’ll continue the series by explaining how to actually install and configure the certificate services. Although this article will walk you through the installation process, I recommend waiting until after you’ve read the entire series to begin installing your certificate server. The reason is that, as I explain in part 1, certificates tend to be very sensitive in nature. Part 3 will discuss some security methods that you can use to protect your certificate server. Later in the series, I will also discuss some special procedures that you’ll have to use for backing up and restoring individual certificates. With that said, let’s look at the installation procedure.

Installing an enterprise certificate server

As I mention in part 1, there are two types of certificate server: stand-alone and enterprise. For the purposes of this article, we’ll be installing an enterprise certificate server. As you may know, a stand-alone certificate authority can run on any Windows 2000 machine, but an enterprise certificate authority requires Active Directory. So before beginning the installation procedure make sure that your certificate server is configured to use Active Directory. If you have any doubts as to whether your server is configured to use Active Directory, you may run the DCPROMO command from the Run prompt to launch the Active Directory Installation Wizard. I also recommend making sure that you have a good backup of the server, including its system state data, just in case anything were to go wrong. As you’ll see later on, installing the certificate services can be a risky procedure, and once you get to a certain point there’s no turning back. Begin the installation by opening the Control Panel and double-clicking on the Add/Remove Programs icon to open the Add/Remove Programs dialog box. Click the Add/Remove Windows Components button to launch the Windows Components Wizard. Now, select the Certificate Services check box from the Components list. When you do, you’ll see a warning stating that once the Certificate Services are installed, you won’t be able to rename the machine. You also won’t be able to join a domain or remove the machine from its current domain. Once you’ve carefully considered the implications and effects of this warning, click Yes to continue. Doing so will return you to the main Windows Components Wizard screen. At this point, make sure that the Certificate Services are selected and click the Details button. Doing so will give you a chance to decide which Certificate Services components will be installed. For the purposes of this article, we’ll be installing both services; but in real life, you may only want to install the Certificate Services CA or the Certificate Services Web Enrollment Support option. Once you’ve made your selections, click OK to return to the main Add/Remove Windows Components Wizard screen. Click Next. The next screen gives you a choice of which type of certificate authority you want to install. In this article, we’ll use the Enterprise Root CA. This type of certificate authority is the most trusted certificate authority in the enterprise and should be installed before any other certificate authority.

Unicode limitations
In the screen that asks for the certificate authority’s identifying information, the organization’s name and other attributes are encoded in Unicode, as dictated by the X.509 standard. Unfortunately, this means that if your organization’s name contains any special characters (such as & or *), some applications may have trouble decoding the certificate. Therefore, Windows 2000 will warn you of this possibility before allowing you to use such characters.

Once you’ve selected the type of certificate authority you want to install and any advanced options that you want to configure, click Next until you come to the screen that asks for the certificate authority’s identifying information. This screen allows you to enter all sorts of identification information for the certificate authority. For example, you can enter the name of the organization and the organizational unit that will use the certificate authority. In the test environment I set up, the organization was Posey Enterprises and the organizational unit was research and development. These names have absolutely nothing to do with anything that’s currently listed in my Active Directory.

The identification screen also allows you to enter other information such as a city, state, description of the certificate authority’s purpose, and an expiration date. Normally, the certificate authority expires in two years, but you can set lifetime as low as a single day. In my test environment, I set the expiration date for July 29, 2200 just to see if it would take a date that was 200 years in the future. When you click Next, you’ll see a screen that asks where the database and log files should be stored. Keep in mind that the locations you specify aren’t where the normal certificates will be stored–instead, the location contains certificates used internally by the certificate authority. Needless to say, whatever location you choose, you should make sure that it gets backed up each night. You should know about two other options on this screen. First, if any clients on your network aren’t using Active Directory, but will need to use certificates, you can use the Shared Folder option to create an accessible share point. Second, suppose something goes wrong with your server and you have to reinstall the certificate services. If this is the case, this part of the Wizard will contain an option called Preserve Existing Certificate Database. By selecting this option, your existing certificates won’t be overwritten during the reinstallation. Once you complete this portion of the wizard, you may encounter several other housekeeping chores, depending on the options you’ve chosen. For example, if you’re installing a subordinate certificate authority, you’ll have to request a certificate from the root certificate authority before continuing. (I’ll cover the procedure for doing this in a future article.) For now, we’re still configuring the root certificate authority, so subordinate certificate authorities aren’t a concern. Another task that you may be asked to perform involves Internet Information Server (IIS). If your machine is running IIS, Windows 2000 will ask you to stop the IIS Web service so that it can complete the installation process. Once the wizard completes, Windows 2000 will ask you to restart the server. Once the server comes back online, the certificate authority services should start running automatically.

Other certificate authority options

Let’s take a minute to discuss some of the other options offered by the Add/Remove Windows Components Wizard. The Enterprise Subordinate CA option is used when you need to create an enterprise certificate authority in an environment that already has one. This type of certificate authority obtains its certificates from the existing certificate authority and is primarily used to ease the workload from the existing server or from a particular network segment. The stand-alone root CA is the most trusted certificate authority within the stand-alone certificate authority hierarchy. It doesn’t require Active Directory. As you might have guessed, the stand-alone subordinate certificate authority is basically a device to relieve some of the workload from the stand-alone root certificate authority. You may have also noticed the Advanced Options check box at the bottom of the screen. You don’t have to use this check box unless you need to change some of the cryptography settings. By default, the certificate authority uses the Microsoft Base Cryptographic Provider with the SHA-1 hash. However, using the Advanced Options check box, you can change these options along with the key length. You can also import keys from other sources by telling Windows 2000 to use keys that have already been installed by applications such as Microsoft’s Internet Information Server.// Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.

Get the Free Newsletter!
Subscribe to Daily Tech Insider for top news, trends & analysis
This email address is invalid.
Get the Free Newsletter!
Subscribe to Daily Tech Insider for top news, trends & analysis
This email address is invalid.

Latest Articles

Follow Us On Social Media

Explore More