How IT Works Certificate Services

Randy Muller

The term PKI (or public key infrastructure) strikes fear into the hearts of many network administrators. But, in reality, network administrators should draw comfort from the thought of PKI, knowing that it provides a secure means of communication on their network.

Essentially, PKI provides credentials (in the form of certificates) which can be used by applications to sign and/or encrypt data and communications. In public key cryptography, a pair of associated keys—one public and one private—are used for encrypting and signing data. Simply put, the data is encrypted with one of these keys and decrypted with the other. If, for example, I want to send a signed e-mail, my mail program creates a one-way hash of my message, which I encrypt using my private key. The recipient then uses my public key to verify the signature, ensuring that the e-mail was actually sent by me. I can send my public key to any individuals who need it, while I keep my private key well guarded.

Certificate Services is the essential component of a Windows®-based PKI. If you deploy an application that is PKI aware and you want to make use of the security capabilities offered by PKI, you will need Certificate Services. This is used to manage the lifecycle of certificates for the applications and accounts that require them. It covers the request, issuance, enrollment, publication, maintenance, revocation, and expiration of certificates. Certificate Services also provides information assurance, meaning that measures are taken to safeguard aspects of information and information systems. This is done by ensuring authentication, confidentiality, integrity, and nonrepudiation.

After you decide what types of PKI-enabled applications you are going to deploy, you have to decide which accounts will make use of these applications—thus, determining which accounts (or security principals) will be issued certificates. A security principal is the subject of the issued certificate. It can consist of computers, services, and users. A computer or user receives a certificate to establish its unique identity with PKI-aware applications. Services, meanwhile, use certificates to identify themselves on the network and authenticate themselves to other services, computers, or users. (For more information about when you might use PKI, see the sidebar "Common PKI Uses.")

Common PKI Uses

There are a variety of applications and technologies that are PKI compatible. Here are some common uses of PKI and certificates.

• 802.1X Controls access to wired and wireless networks, ensuring that only authorized users and computers are granted access.
• Encrypting File System (EFS) Allows users to encrypt data and share encrypted files, as well as provides for the establishment of Recovery Agents.
• Secure Internet Used for authentication between a client and server, while encrypting the communication between the client and server.
• IPSec Enables the creation of an authenticated communications channel between two systems, as well as the encryption of traffic once the session is established.
• Secure E-Mail Verifies the sender and ensures the message has not been tampered with in transit.
• Smart Card Logon Provides two-factor authentication to provide an additional layer of security in which the user must have the smart card and know the PIN associated with it.
• Software Code Signing Provides signing and authorization of code (both drivers and applications).
• Software Restriction Policy Provides a mechanism that can be used to prevent programs that are not authorized from being executed.

The Underlying Certificate

A digital certificate is an electronic credential that is based on a standard schema (such as X.509 or XRML). It consists of a variety of properties, such as who the certificate is granted to (Subject), the expiration date (Valid to), and what certificate authority it was granted by (Issuer).

Certificates can be used for several purposes. In some instances, you may want a single certificate to map to an individual user account—this is known as one-to-one mapping. In this case, the certificate might be issued to a user for Encrypting File System (EFS) or secure e-mail purposes. Alternatively, you might want a many-to-one mapping, in which multiple certificates are issued to a single user account for several purposes.

A certificate server issues a certificate based on who or what requested the certificate. The client computer generates the public and private keys. It keeps the private key on the local machine (or in the user’s profile) and sends the public key to the certificate authority (CA). The CA verifies the identity of the requestor and that the requested certificate is valid for the given requestor. If the requested certificate is permitted, the CA signs the public key and binds it to a certificate. Finally, the CA issues and manages the certificate until it is revoked or expires.

An actual certificate can be stored in one of several locations depending on how it is going to be used. If, for instance, a certificate is being used for a smart card, then it is stored right on the smart card. If, on the other hand, a certificate is issued for a user, then it is stored either on the user’s local hard drive or in another secure location accessible by the user.

The Infrastructure

The first step in planning an implementation is to determine its scope and purpose. Then you can decide on the types of certificates it will require and how your CA hierarchy should be structured. Generally, certificate hierarchies are three levels deep, consisting of an offline root CA, a policy (or intermediate) CA, and the issuing CAs (see Figure 1). The specifics, however, depend on the details of your overall deployment.

Figure 1 Certificate Authority Hierarchy

CAs can be one of either two types: enterprise or standalone. An enterprise CA is connected to the network and requires communication with Active Directory®. A standalone CA, on the other hand, does not require communication with Active Directory and can be removed from the network. An environment can contain a mixture of enterprise and standalone CAs. The root CA is often standalone while the issuing CAs are enterprise to facilitate user requests for certificates (the policy CAs are frequently either standalone or enterprise).

The root CA is the first server, or top level, in the CA hierarchy. A root CA can self-sign its own root certificate or use a certificate from a third party. Requests made to the root CA are automatically approved or denied based on the requestor and the permissions associated with the certificate template. Certificate requests to an enterprise root CA can be made by the Certificate Request Wizard or by the certification authority Web page.

A standalone CA does not require Active Directory and is typically removed from the network to become an offline root CA to maintain a higher level of security. If Active Directory is present, a standalone CA will use it to publish certificates and the certificate revocation list (CRL). All certificate requests made to a standalone CA must be approved or denied manually by the designated certificate manager. (With standalone CAs, certificate templates are not used and there are restrictions with smartcards.)

The next level is the policy CA. This is subordinate to a root CA and is certified (by the root CA) to issue and authorize certificates for other requesting CAs (the issuing CAs).

Below the intermediate CAs are the issuing CAs. This is the level with which users interact. Issuing CAs are authorized by a higher level CA (usually a policy CA) and are responsible for issuing certificates to the applications and subjects that request them. (In some scenarios, each issuing CA is responsible for just one type of certificate.)

Installing Certificate Services

After you’ve identified your certificate requirements and planned your CA hierarchy, you need to install the actual Certificate Services. To do this, open Add or Remove Programs and select Windows Components. Choose Certificate Services, and follow the wizard to select what type of server you wish to install, specify a common name for your CA (see Figure 2), and indicate the location where the database and log file will be installed. Once you’ve installed Certificate Services, you are ready to issue certificates.

Figure 2 Naming the CA

Another method for creating a CA is through the use of a CAPolicy.inf file. This is an optional file that you create manually and store in the %windir% folder. It is used to configure Certificate Services during installation and for the renewal of the CA’s own certificate. You do not have to use a CAPolicy.inf for creating a CA, but it is required for an offline root CA. The CAPolicy.inf contains configuration information for distribution points, CRLs, key usage, Certificate Practice Statements (CPS), key validity period, and so on.

Issuing and Revoking Certificates

When security principals and applications request certificates, the requests can take many forms depending on who is requesting the certificate and what type of certificate is being requested. There are five methods used for requesting certificates: Autoenrollment, Certificates Console, Certreq.exe, enrollment agents, and Web-based requests. Here’s a simple overview of how they differ:

• Autoenrollment allows Windows XP and Windows Server™ 2003 clients to automatically request and renew user and computer certificates. Group Policy and version 2 certificate templates are used to enable autoenrollment.
• A user or a computer can use the Certificates Console to request a certificate from an enterprise CA. You use the Microsoft Management Console (MMC) to access the Certificates Console, which allows you to access the Certificates Request wizard.
• A user can submit a request to a CA through the use of Certreq.exe. This provides for the management of requesting, retrieving, installing, and signing certificates from a command line.
• An enrollment agent can request a certificate on behalf of a user for a Smart Card Logon certificate or a Smart Card User certificate.
• The Web-based request form lets a user request a certificate from an enterprise CA. It can also be used to verify requests made to the CA.

To use the Web-based enrollment method, a user must open Microsoft® Internet Explorer® and type https://servername/certsrv in the address line (where servername is the name of the server on which Certificate Services is installed). The user can choose the type of certificate. For example, a user can request an advanced certificate by selecting Create and submit a request to this CA. In the Advanced Certificate Request window, the user must choose which certificate template he wants to use (see Figure 3). Here, the user can also specify the key size used for encryption, whether the keys are exportable, and so on. The user can then click the Submit button and await approval from the enterprise CA. Once approval is granted, the user can install the certificate on his system.

Figure 3 Making an Advanced Certificate Request

At some point a certificate will no longer be valid. This could occur because the certificate reached its expiration time or the certificate was revoked due to a compromise. Whatever the situation, a list of revoked certificates is maintained and published in a CRL. This list is automatically published at specified intervals and used by applications to ensure that the certificate presented is valid and in the certificate chain (the chain of certificates issued by higher level CAs until a self-signed root CA certificate is found and validated). A certificate manager can revoke a certificate through the CA console (see Figure 4). In doing so, the manager has the option of specifying a reason for revoking the certificate.

Figure 4 Revoking a Certificate

Wrap Up

PKI comprises a number of parts, such as CAs and digital certificates, which work together to enable secure communications. When a user requests a certificate—either directly (using a Web page) or indirectly (using, for instance, EFS)—the request is verified by an issuing CA. The issuing CA has been verified by a policy CA, which in turn has been verified by a root CA. Ultimately, this verification ensures that the requestor is authorized to be issued the certificate.

TechNet Online Resource

For more information about Certificate Services, see:
Best Practices for Implementing a Windows Server 2003 Public Key Infrastructure

Randy Muller, MCT, MCSE, MCSA, MCDST, teaches a variety of networking, security, and other computer classes. He is a former Army Signal Corp Officer and has been teaching since 2000. You can contact Randy at randy@randymuller.org.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.