Why set up a certificate server?

In the article ”
Working with certificates in Windows 2000
, I discuss some ways that you can manage certificates on your local machine. Managing local certificates can be a crucial task in some situations. However, it’s much more common to work with certificates at the server level. In this series of articles, I’ll discuss the issues involved in setting up a certificate server. In Part 1, I’ll explain the reasons for establishing a certificate server, along with some of the basic terminology and general requirements. In future articles in the series, I’ll provide you with step-by-step procedures for setting up a certificate server. I’ll also talk about issues that you’ll encounter such as backing up and restoring certificate servers, and how a certificate server works with third party certificates.

Why use a certificate server?

Before you can understand the importance of a certificate server, you need to understand the role that certificates play in Windows 2000. In Windows 2000, practically every security mechanism relies on certificates to some degree. For example, Kerberos (the Windows 2000 authentication protocol) and the IPSec protocol (which is designed to protect network packets) both rely on certificates to ensure secure communications. Other Windows 2000 services such as Secure Multipurpose Internet Mail Extensions (S/MIME) and the encryptable file system (EFS) also rely on certificates to protect Internet messages and local files. Even Windows 2000 services that don’t directly use certificates gain extra security by relying on underlying services that do use certificates. Certificates make up a big part of the overall Windows 2000 security structure.

There’s no doubt that certificates are an important part of Windows 2000 security, but why use a certificate server? There are several reasons why you should use a certificate server, but most can be summed up in a single word–manageability. Keep in mind that thousands of certificates can be floating around your network at any given time. Windows 2000 needs a way to keep track of all those certificates. A certificate server provides a central point from which to issue or revoke certificates, or to test a certificate’s validity.

There’s also the issue of recovery. In some cases, a certificate server can be used to issue a recovery certificate that you can use to retrieve data that would otherwise be lost. For example, suppose that a user in your company uses EFS to encrypt critical files. Now, suppose that the user leaves the company without decrypting the files, or that a hard disk problem destroys the certificate associated with the decryption process. The administrator could use a certificate server to issue a special certificate for recovering the files.

Some terms to know

Before you can properly install and configure a certificate server, you need to know several terms. In this section, I’ll cover some terms that are unique to the certificate services. I’ll also be using some other, more common, security-related terms in this series; most are defined in other articles about security. Obviously, I’ll also be using some other security-related terms in this series, but most of those terms are more common, and have already been defined in other security related articles.

• Policy module–Like most services in Windows 2000, the certificate services are broken into several different modules. The first of these is the policy module. As the name implies, the policy module is nothing more than a set of rules that the certificate server uses to determine how to act on inbound certificate requests. Depending on how you set up the policy module, it can use the built-in rules to automatically approve or reject any incoming certificate request. In some situations, it’s even possible to forward a questionable request to a human operator for approval. Windows 2000 ships with a standard policy module. Other applications, such as Exchange 2000, may modify or extend the basic module, but the basic concept behind the module remains the same. You can also modify the default policy module yourself, should your situation call for it.
• Exit module–An exit module is a little trickier to understand. Basically, it’s a segment of code that tells the certificate authority what to do after it generates a certificate. For example, the exit module might tell the certificate authority to publish the certificate to the Active Directory, or to send the certificate to a certain user. As you might have guessed, because the certificate authority is dependent on an exit module, Windows 2000 comes complete with a default exit module. The default module allows the certificate requestor to specify a directory path, an Active Directory location, or both. After this information has been provided, the exit module will publish the certificate in the locations specified and provide the certificate authority with a link to the newly published certificates.
• Certificate publisher–When the exit module gets ready to publish a certificate, it calls upon another module called the certificate publisher. A certificate publisher [[is just a module]]is nothing more than a module of code that makes the certificate available to the client who requested it.
• Certificate templates–So far, I’ve explained how modules work when a client requests a certificate. There’s one more important piece to the puzzle. As I mentioned earlier, Windows 2000 uses certificates for lots of different types of security-related tasks. Therefore, there are several different types of certificates. Each certificate is composed of many individual attributes that define the behavior of the certificate. Naturally, you only want users to be able to request certain types of certificates. This is where certificate templates come in.

As I mentioned earlier, each certificate is made up of a collection of individual attributes. These attributes do the actual work of making data secure. When a user requests a certificate, they probably don’t know the exact combination of attributes they need to make the process work. Even if they did know which attributes to choose, it would be a huge breach of security to let users pick and choose individual certificate attributes from a list.

To simplify and secure the process, Windows 2000 uses a collection of 19 certificate templates. Each of these templates is a collection of the individual attributes necessary to accomplish a specific security-related task. Rather than selecting individual attributes, the user merely selects the template that best fits the task at hand, and Windows 2000 will automatically populate the embedded attributes. To protect your environment’s security, the administrator can restrict which certificate templates that groups of users have access to. You can even block users from using certificates altogether.

Types of certificate authorities

Now that you’ve got the vocabulary and have a basic understanding of the certificate server’s modules, you’re almost ready to start designing your certificate server. Before you do, though, you need to be aware of one more very important concept. When you set up your certificate server, you’ll have a chance to make it function as an enterprise certificate authority or as a standalone certificate authority. From an architectural standpoint, the only difference is in which policy module is loaded. However, that policy module dictates some significant operational differences.

The biggest difference is that an enterprise certificate authority functions as a part of your network. It requires access to the Active Directory and is always trusted by all users and computers within the domain. Furthermore, an enterprise certificate authority always makes a granted/denied decision when a user requests a certificate. It will never flag a request as pending and wait for an administrator to step in.

A standalone certificate authority, on the other hand, doesn’t service domain user requests. Rather, it’s designed to grant certificates to Internet or extranet users. Because of this, the server isn’t a part of the Active Directory. Making this kind of server a part of the Active Directory would be a huge security hole, because an Internet user may be able to use the information stored in the Active Directory to gain access to the rest of the network.

By default, a standalone certificate authority marks all requests as pending, because it can’t use the certificate templates or the Active Directory to verify the requests. As a result, certificates generated by the server aren’t published anywhere–they must be distributed manually.

If you really need to add this functionality to a standalone certificate authority, you can do so by making the server a part of the Active Directory. Once you’ve done so, you must make the server a member of the Certificate Publishers group before it will be able to publish certificates. //

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.