In part one of this article series,”Setting up a Certificate Server,” I explained how to install a certificate authority on a Windows 2000 Server and create a custom console that can be used to manage the new certificate authority. In this Daily Drill Down, I’ll continue the discussion by explaining how to interact with the newly created certificate authority.
To configure the certificate authority, open the console that you created in part one and navigate through the console tree to Console Root | Certificate Authority (Local) | your certificate authority. Now, right-click on your certificate authority and select the Properties command from the resulting context menu. You’ll see the certificate authority’s properties sheet. This properties sheet contains five tabs that you can use to configure the certificate authority.
The General tab
As you can see in Figure A, there really isn’t much that you can do with the General tab. However, this doesn’t mean the General tab isn’t important; it identifies the description of the server, the cryptographic service provider, and the hash algorithm that the server uses. Unfortunately, you can’t change these values. Once you’ve initially defined them, you’re stuck using them unless you completely remove the Certificate Services and reload them from scratch. Keep in mind, though, that if you’ve already issued any certificates, reloading the Certificate Services would be an extremely bad idea.
Figure A |
![]() |
The General tab identifies the hash algorithm used by the Certificate Server. |
Another function of the General tab is that it allows you to see the Certificate Server’s certificate. This is kind of pointless if you’re looking at a root level server, but if you’re working with a subordinate Certificate Server, it’s sometimes very informative to see the actual certificate that was issued by an upline Certificate Server. You can see an example of such a certificate in Figure B. The window displays whom the certificate was issued to, who the certificate was issued by, the certificate’s expiration date, and, of course, the certificate’s purpose. Notice that the section describing the certificate’s purpose goes way beyond the boundaries of the window. Many client-level certificates may have only a couple of items on this list, but it’s common for Certificate Servers, especially root level Certificate Servers, to have a long list of things that the certificate is intended to do.
Figure B |
![]() |
The Certificate window will show you information about the certificate used by the server. |
Also notice in the figure that the Certificate properties sheet contains three tabs. The Details tab contains much more detailed information about the certificate, such as its serial number, version number, certificate template, etc. Finally, the Certification Path tab shows the hierarchy of Certificate Servers that led to the creation of this certificate. This tab also shows that the certificate has a status of OK if everything is working correctly.
The Policy Module tab
The main purpose of the Policy Module tab is to allow you to view or change which policy module the Certificate Server uses. The policy module is nothing more than a set of rules. Whichever policy module is loaded is the set of rules that the Certificate Server will follow. As you can see in Figure C, a Certificate Server will almost always use the Enterprise And Stand-alone Policy Module. I don’t recommend changing policy modules. However, if you do have a compelling reason to change the policy module, you can do so by clicking the Select button.
Figure C |
![]() |
The Policy Module tab allows you to view or change which policy module the Certificate Server uses. |
To customize the Policy Module, click the Configure button. You’ll see the policy’s properties sheet. This properties sheet contains two tabs. The Default Action tab controls the basic behavior of the policy. It controls whether valid certificate requests are automatically issued a certificate or whether they are marked as pending, which would require an administrator to manually grant the final authority to issue the certificate. However, with the type of Certificate Server we created in part one, you aren’t given this choice. Instead, Windows is configured to always issue the certificate automatically.
The other tab you’ll see on the policy’s properties sheet is X.509 Extensions. This tab allows you to customize the locations in which users may obtain a certificate revocation list and the locations where users may obtain certificates from the certificate authority. (The items on this list are encoded in X.509 format, thus the tab’s name.) You can enable or disable the various possible publication locations by selecting or deselecting the check boxes next to each location.
The Exit Module tab
The next tab you’ll encounter on the certificate authority’s properties sheet is the Exit Module tab. The easiest way to describe an exit module is to compare it to a policy module. A policy module is basically a set of rules that is applied to the Certificate Server to control its behavior. An exit module is also a set of rules that is applied to a Certificate Server. There are a few major differences, though. First, a policy module controls whether certificates are automatically issued or whether they require manual intervention. A policy module also controls the locations that certificates and certificate revocation lists are published to. The exit module, on the other hand, controls how certificates are published when they are issued.
Another major difference between the behavior of policy modules and exit modules is that while you can use only one policy module per server, you can have multiple exit modules. When using multiple exit modules, each module is applied in sequence. However, Windows 2000 only comes with a single exit module, so you’ll never need to worry about layering exit modules unless you decide to use some third-party exit modules or develop your own in-house.
When you look at the Exit Module tab shown in Figure D, you can see that it’s strikingly similar to the Policy Module tab. The Add and Remove buttons allow you to add or remove exit modules to and from the list of active modules. (Of course, the Policy Module tab didn’t have these two buttons because you can only run one policy module. Instead of having Add and Remove buttons, the Policy Module tab simply uses a Select button.)
Now, look at the default module names. On the policy module, the default name is Enterprise And Stand-alone Policy Module. Likewise, the default exit module name is Enterprise And Stand-alone Exit Module. You’ll also notice that both the Exit Module and the Policy Module tabs contain a Configure button. When you click the Configure button on the Exit Module tab, you’ll see the properties sheet shown in Figure E.
Figure D |
![]() |
The Exit Module tab is very similar to the Policy Module tab. |
Figure E |
![]() |
The exit module’s configuration properties sheet allows you to determine where certificates should be published to. |
You can publish certificates to Active Directory, the file system, or both. Obviously, using the Allow Certificates To Be Published In The Active Directory check box allows the Certificate Server to load certificates into Active Directory. The Allow Certificates To Be Published To The File System check box tells Windows to post the certificates into the share point that you established when you initially installed the Certificate Server.
In case you’re wondering, by default the Certificate Server automatically posts certificate revocation lists to the file system in the %SYSTEMROOT%\SYSTEM32\CERTSERV\CERTENROLL folder. You can figure out which file is which by looking at the file name. The filename begins with a C and then uses the date in YY/MM/DD format to complete the file name. For example, you might have a filename like C010423.CRL for a revocation list from April 23, 2001. If more than one file was created on a given day, Windows adds a sequence number to the file. For example, if three files were created on April 23, 2001, the filenames would be C010423.CRL, C0104232.CRL, and C0104233.CRL.
The Storage tab
The next tab you’ll encounter is the Storage tab. As you can see in Figure F, you can’t actually do anything with the Storage tab. Instead, the Storage tab provides a reference of the name and location of the certificate database and the request log. This tab can be especially useful if you find yourself having to troubleshoot a problem with a Certificate Server on an unfamiliar system.
Figure F |
![]() |
The Storage tab tells you the name and location of the certificate database and of the request log. |
The Security tab
The final tab on the CA properties sheet is the Security tab (see Figure G). The Security tab works like pretty much every other security screen you’ve seen in a Windows 2000 environment.
Figure G |
![]() |
The Security tab allows you to determine who can do what with your Certificate Server. |
By default, Windows adds four groups to the access control list and applies permissions to them. You can check out each group’s permissions by selecting the group and then looking at the check boxes that are selected in the Permissions section. Remember that as with every other form of Windows 2000 security, an explicit deny overrides any assigned permission.
Unfortunately, the Security tab limits you to applying security to a total of ten groups. Therefore, if you’re planning some really elaborate security scheme, be careful about exhausting the access control list. You can add and remove groups to and from the access control list by using the Add and Remove buttons.
Requesting a certificate
Now that you know how to interact with the console to manage the Certificate Server, let’s take a brief look at the process of requesting a certificate. There are many ways of requesting certificates. One of the more common methods is for a user to request a certificate that positively identifies him or her at login.
To do so, a user must be running Windows 2000 Professional. The user may open the Control Panel and double-click on the Users And Passwords icon. This will bring up the Users And Passwords Properties sheet. Next, the user will select the Advanced tab and click the New Certificate button. When doing so, Windows will launch a wizard that searches the domain for a certificate authority and installs a new certificate based on the certificate template that the user selects.
Conclusion
In this Daily Drill Down, I’ve explained how to custom tailor your Certificate Server to meet your company’s needs. I also discussed how to configure the certificate authority through the console that you created last week. Finally, I explained how to request and install a certificate from a client computer.