70-240 in 15 minutes a week: Windows 2000 Certificate Services

Sunday Dec 9th 2001 by ServerWatch Staff

Article 28 in Dan DiNicolo's 70-240 in 15 minutes a week series covers Certificate Services in Windows 2000, and includes a look at why certificates are used, the different ways in which Certificate Services can be set up, the installation of Certificate Services, and finally integration with Group Policy.

by Dan DiNicolo

Welcome to article number 28 in my 70-240 in 15 minutes a week series. This article covers Certificate Services in Windows 2000, and includes a look at why certificates are used, the different ways in which Certificate Services can be set up, the installation of Certificate Services, and finally integration with Group Policy. This is the last article in my 70-240 series, and again falls into the networking services portion of the exam.

The material to be covered in this article includes:

- Overview of Certificates and PKI
- Types of Certificate Authorities
- Installation of Certificate Services
- Integration with Group Policy

Overview of Certificates and PKI

Of all the many services that Windows 2000 offers, one of the least understood is probably Certificate Services. While it may seem that anything that has to do with cryptography is unnecessarily complex, understanding the main elements is certainly not difficult. Certificate Services exist for one primary purpose - to help in the creation of something referred to as a Public Key Infrastructure (PKI). The purpose of a PKI is simple - to allow data to be encrypted, to have users (or computers or services) authenticated and verified, and to have some system of trust that allows this all to work efficiently. You should also have an awareness of what certificates can be used for in Windows 2000 - in other words, why you should even care. Examples include authentication by Smart Cards, encrypting files and email messages, authenticating to web sites, authenticating computers for L2TP connections, and so forth - each of which relate to or rely on PKI in some respect. The key to understanding how a PKI works first involves understanding the two main elements that it is made up of - certificates and Certificate Authorities.

To make things easier, from now on I would suggest thinking of a certificate as being like a drivers license. For all intents and purposes, it is a piece of identification that tells something about you and can be used as proof of your identity. The most important detail about your driver's license is that fact that it was issued by a trusted third party, more than likely a department of local government. The license bares the department logo or signature, and as such they vouch for your identity. The only reason that a drivers license works as identification is because we have established trust in the system - I believe that your license is real because it was issued by government, and also because I too carry a license which is proof of my identity. I trust the government and so do you, so the system works (whether you really think the government is trustworthy is another story). In this case, the government is acting as the trusted third party - the Certificate Authority (CA). So first and foremost, think of the certificate as something that can prove your identity, with the CA acting as the one who has actually verified that you are who you say you are. 

The manner in which certificates are used and issues is a tad more complex. Before actually obtaining a certificate, a user must first generate a pair of keys - these are what are commonly referred to as the private and public key. People always seem to be confused about how these keys are used, so I'll spend a little time on that now. Basically, if you want to be part of a PKI, you will need a private and public key pair, and a valid certificate. The way in which this happens differs slightly between systems, but the gist of things is usually the same - I'll follow the Windows 2000 way. The first step is creating the key pair, which is done by something called the Cryptographic Service Provided (CSP), basically a program running on your system, which is accessed by a programming interface called the CryptoAPI. This will result in a key pair being created, made up of both a public and private key. The private key is not meant to be shared (as I'll soon explain) and is secured by the operating system. The public key is free to go to anyone, and will need to be accessed by those looking to securely communicate with you. After the key pair has been generated, the next step is requesting a certificate, from some predefined Certificate Authority. This might be a server in your internal organization, or it might be a public CA such as Verisign. Whatever the case, you must submit a request, and that request includes information such as your name, email address, contact information, and so forth (what you need to provide depends on the CA and type of certificate). The request also includes a copy of your public key. Based on rules that have been set up by the CA, a certificate may or may not be issued to you. If it is, the file that is created contains the information that you have submitted, as well as the digital signature of the CA - proof that they choose to verify your identity. Of course, this proof is only as good as your (and other people's) trust in the CA. This is another important fact that we'll look at shortly.

The manner is which these keys and certificate are used vary by the services you wish them to provide, but the easiest example is always email. Imagine that two users, Sally and Bob, wish to send each other email. A standard email message is not encrypted and can potentially be read by others as is moves across the network or Internet. Not only that, but another user could send email to Sally pretending to be Bob, and so things get even more complex. Certificates help with this, but we need to understand a little more about private and public keys. Lets begin by taking a look at sending an encrypted message. Imagine that Bob wants to send an encrypted email to Sally. In order to do so, Bob needs a copy of Sally's public key. How he can obtain this is via email from Sally, via a download from a directory service or website, and so forth. This shouldn't be a problem, because Sally's public key has a rather limited use - the messages that it encrypts can only be decrypted by Sally's private key. In other words, Sally's public key is used by others to send encrypted messages to Sally only. Unless Sally's private key is stolen somehow, people will be unable to read encrypted messages sent to her. Getting back to our example, lets say that Sally sends Bob her public key, the next question becomes how can Bob be sure that this message is really from Sally and not someone pretended to be Sally? This too can be handled via the user certificate. When Bob receives a message digitally signed by Sally, he can verify her identity according to the CA signature on her certificate. Bob can only read this signature by the CA if he has a copy of the CA's public key. Just to know, your web browser and email client software automatically include public keys for many certificate authorities. If the CA signature checks out, and the certificate contains all of Sally's information, then you can be reasonably sure that the request did, in fact, some from Sally.

Once Bob has a copy of Sally's public key, he can then send her encrypted messages, but the reverse is not true. Until Sally also has Bob's public key, she cannot send encrypted messages to him. The only way that the system works at all is if Bob and Sally both trust the CA to prove their identities. 

An important consideration when looking at public key cryptography is that the whole deal has a great deal of overhead (computationally) associated with it. For this reason, public key cryptography is often used not to encrypt all data, but instead to encrypt something referred to as a session key. In non-email applications (such as visiting a secure website), instead of encrypting all data back and forth using public and private keys, the client machine creates a session key that is used for the purpose of encrypting data by both the client and the server. This session key is passed from the client to the server using public key encryption, but from that point all data is encrypted with the session key - this is both faster and more efficient that encrypting everything using the associated public keys. Once the session is over, the session key is destroyed, and a new one will be used when another session is created. 

Now that you have an overview of what the keys do, it is important to understand that certificates also expire. When they are created by a CA, certificates are also given an expiry date, again similar to a license. If the license is expired, it may still be in your pocket, but is not considered valid. The same holds true for a certificate - including the fact that the issuer may revoke the certificate. In certificate-speak, revoked certificates are published to something called the Certificate Revocation List (CRL), a list available to client systems that choose to check it. Reasons for revoking a certificate include the associated private key having been compromised, misuse, and so forth. The situations under which certificates are revoked are at the discretion of the CA.

Types of Certificate Servers

Before covering the installation of Certificate Services in Windows 2000, it is important to understand the different types of Certificate Authorities that can be installed. A root CA is the top link in a chain of CAs, while a subordinate CA is a downlevel server that has one or more CAs above it (and eventually reaching a Root CA). Windows 2000 supports 4 types of CAs, as described below.

Enterprise Root CA - An Enterprise Root CA is used in corporate environments for issuing certificates to users and computers. An Enterprise CA requires that Active Directory exist, DNS be configured correctly, and that the user configuring the server have Enterprise Administrator privileges. In an Active Directory environment, an Enterprise Root CA is automatically registered in Active Directory and trusted by domain computers. In a large PKI setup, the Enterprise Root CA is usually used to issue certificates only Enterprise subordinate CAs, who then issue certificates to users and computers. Though this is often the case, it does not have to be, as an Enterprise Root CA can issue user and computer certificates as well.

Enterprise Subordinate CA - An Enterprise Subordinate CA is a certificate server that exists hierarchically under an Enterprise Root CA. Often Subordinates are used to for a specific purpose, such as granting certificates for users, or computers, or for a specific portion of an organization. A Subordinate CA requires all of the same services and privileges as an Enterprise Root CA, and cannot be created unless an Enterprise Root CA exists. Note that although the Enterprise Root CA might be another internal Windows 2000 certificate server, it might also be an external CA such as Verisign. In fact, if you want the outside world to trust the authenticity of your certificates, it is pretty much imperative that you trust an External Root CA such as Verisign. Otherwise, external users will need a copy of your Root CA's certificate, which they are certain not to have, unless as part of some partner relationship.

Standalone Root CA - For environments without Active Directory, a Standalone Root CA can meet certificate requirements. These servers require only Administrator privileges on the server. If Active Directory does not exist in the environment, this is the only type of Root CA that can be installed.

Standalone Subordinate CA - Much like the Enterprise Subordinate CA, this certificate server might be used to issue certificates to certain departments or users or computers, but does not require Active Directory. However, it does require a Root CA, which can again be internal or external. 

An important consideration when choosing the type of CA is the environment and the way in which you intend to use the certificates. If it is strictly for internal use, then your options are wide open according to your environment (for example is you have AD, then use you can use either Enterprise or Standalone CAs). If however you need certificates to secure a public website, then an external certificate authority will need to be involved, either providing the certificates for that site directly, or via a chain of trust. For example, if you access a secure website and click on the lock icon on the bottom left of the Internet Explorer window, you can view the Certification Path for that site, as shown below. 

Installation of Certificate Services

Installing Certificate Services on Windows 2000 is quite simple, though the choices available to you will again depend on your environment. For the purpose of this illustration I will walk through the process of creating a Standalone Root CA - mainly because my computer is not configured as a domain member at the moment. Since it is not installed by default, you will need to add Certificate Services using the Add/Remove Programs - Windows Components option in Control Panel, as shown below:

Note that when you attempt to choose Certificate Services, you will be presented with the dialog box shown below. Note the fact that you will not be able to rename the system or join or be removed from a domain without first uninstalling Certificate Services.

After choosing Next, you will be asked to decide what type of CA you wish to create. Note that my system has only the Standalone CA options available, since it is not a member of an Active Directory domain.

Note that the Advanced options checkbox on the screenshot above will allow you to choose advanced cryptographic options in the key generation process. I would suggest allowing the default values to be used unless you are certain of the need to make other choices.

Clicking Next again will bring you into the CA Identification screen, where you should enter the appropriate information. Note that while not all fields are mandatory, they should be completed in full.

The final screen in the process asks for where you wish to place configuration and logging data, as shown below.

Once Certificate Services is installed, the Server is ready to accept certificate requests from clients. For a Standalone CA these requests must be made a web browser by accessing the certificate server using the URL http://computername/certsrv. A wizard that walks you through the process step-by-step handles the actual request process.

The certificate request process also includes providing information about the user, the use of the certificate, and so forth. In the example below, I am requesting a certificate to secure email.

After the request is completed, the user is presented with the following message. Note that the request has been made, but the certificate will not be issued until approved by the Administrator.

The approval process for a requested certificate is pretty straightforward. Using the Certificate Authority tool in Administrative Tools, open the Pending Requests option, and choose to Issue the certificate or deny the request, as shown below.

Note that once completed, the user can again access the Certificate Services web site and download and install their new certificate. The certificate just issued will now be found in the Issued Certificates section from the screen above, and can be revoked from this interface as well. In an Active Directory environment, note that users can also request certificates using the Certificates MMC snap-in, or can be configured for auto-enrollment of certificates (on both a user and computer basis) via Group Policy. In large environments running an Enterprise CA, this is often the most practical idea.

Integration with Group Policy

It is obvious that setting up a PKI involves much planning and is a great deal of work. I couldn't possibly go into all of the details of PKI management in this article, not without possibly writing a dedicated book. However, the 70-240 exam doesn't assume you're a cryptography expect, so I'm not going to move far beyond the basics (for a longer and more detailed overview I would suggest reading http://www.microsoft.com/windows2000/docs/PKI.doc). One of the main benefits of setting up Certificate Services as an Enterprise CA is not only its integration with Active Directory, but also the ability to manage much of the necessary dirty work via Group Policy settings that handle automatic certificate requests, also known as auto-enrollment. In fact, Windows 2000 Group Policy will allow you to do the following:

- Have domain client computers automatically request and install a computer certificate. This certificate identifies the computer and can be used for the purpose of IPSec encryption / authentication, and is also a requirement for L2TP-based VPN connections (since both the user and computer must be authenticated in those connections). This is accomplished in the Computer Configuration - Windows Settings - Security Settings - Public Key Policies - Automatic Certificate Request Settings section of Group Policy. Any systems to which this policy applies will automatically request, download and install their certificate.

- Create and distribute certificate trust lists. This will allow client computers to be easily configured with a list of trusted Root CAs and their associated hierarchies. This is done via Computer Configuration - Windows Settings - Security Settings - Public Key Policies - Enterprise Trust in Group Policy. The actual configuration is handled via the Certificate Trust List wizard.

- Establish trust with other external root authorities, for example ones that are not part of your organization. This could be useful in secure partnering relationships between organizations. These are configured in Group Policy under Computer Configuration - Windows Settings - Security Settings - Public Key Policies - Trusted Root Certification Authorities.

- Adding encrypted data recovery agents for the purpose of using the Encrypted File System (EFS). Although the Administrator account is there by default, others can be added by accessing Computer Configuration - Windows Settings - Security Settings - Public Key Policies - Encrypted Data Recovery Agents.

And so ladies and gentlemen, we have finally reached the end of a very long road. All that is left now if for you to brush up on those areas where you feel the need, and then get to writing the big exam. Congratulations to all of those who have contacted me telling me of their success on the exam - I told you it wasn't that hard, as long as you know your stuff. My sincere best wishes to all of you have decided to stick with writing the 70-240 exam even though you now know that your old NT 4.0 certification is still valid - I sincerely believe that in studying and doing the exam you are doing yourself justice, rather than using the change as an excuse not to challenge yourself. Thanks so much to everyone who has supported the series, and those whose emails of support kept me plugging away at the articles as time permitted. Thanks also to those who have been understanding of the delays on my end due to my work in Africa, and thanks for the kind words with respect to that as well. Without rambling, just thank you. I feel confident that each and every one of you who have prepared for the exam can pass. Though time is running short, its still not too late to take advantage of the opportunity presented to you. If I can offer some parting words for the series - forget about the piece of paper, focus on learning, and you can't really lose.

Best of luck with your studies,

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved