Lesson 2: Installing and Configuring Certificate Authority

In this lesson, you explore certificates in more detail by learning how to install and protect your CA. Next, you are introduced to various ways to enroll certificates.

After this lesson, you will be able to

  • Explain how to use Certificate Authority Manager
  • Explain how to install a CA
  • Explain how to protect a CA
  • Describe the certificate enrollment process

Estimated lesson time: 35 minutes

Deploying a CA

CAs will be installed during the upcoming practice, "Installing a Standalone Subordinate CA." The Certificate Services Installation wizard walks the administrator through the installation process. This section discusses key elements that should be considered before beginning the installation process.

  • Establishing a Windows 2000 domain. If an enterprise CA is to be deployed, establish a domain before installing Certificate Services.
  • Active Directory integration. Information concerning enterprise CAs is written into a CA object in Active Directory during installation. This provides information to domain clients about available CAs and the types of certificates they will issue.
  • Selecting the host server. The root CA can run on any Windows 2000 Server platform, including a domain controller. Factors such as physical security requirements, expected loading, and connectivity requirements should be considered in making this decision.
  • Naming. CA names are bound into their certificates and hence cannot change. Renaming a computer running Certificate Services is not supported. Consider factors such as organizational naming conventions and future requirements to distinguish among issuing CAs. The CA name (or common name) is critical because it is used to identify the CA object created in Active Directory for an enterprise CA.
  • Key generation. The CA's public-private key pair will be generated during the installation process and is unique to this CA.
  • CA certificate. For a root CA, the installation process will automatically generate a self-signed CA certificate using the CA's public-private key pair. For a child CA, the administrator has the option to generate a certificate request that may be submitted to an intermediate or root CA.
  • Issuing policy. The enterprise CA setup automatically installs and configures the default enterprise policy module for the CA. The standalone CA setup automatically installs and configures the default standalone policy module. Custom policy modules can be substituted if necessary.

After a root CA has been established, it is possible to install intermediate or issuing CAs subordinate to this root CA. The only significant difference in the installation policy is that a certificate request is generated for submission to a root or intermediate CA. This request may be routed automatically to online CAs located by means of Active Directory, or it may be routed manually in an offline scenario. In either case, the resultant certificate must be installed at the CA before it can begin operation.

The enterprise CA trust model may or may not correspond to the Windows 2000 domain trust model. A direct mapping between CA trust relationships and domain trust relationships is not required. There is nothing that prevents a single CA from servicing entities in multiple domains or even entities outside the domain boundary. Similarly, a given domain may have multiple enterprise CAs.

Protecting a CA

CAs are highly valued resources, and it is often desirable to provide them with a high degree of protection. Specific actions that should be considered include:

  • Physical protection. Because CAs represent highly trusted entities within an enterprise, they should be protected from tampering. This requirement is dependent on the inherent value of the certification made by the CA. For example, if the certificates provided by a server are used to provide security to users accessing their online bank accounts, physical protection of the server would be a good idea. Physical isolation of the CA server in a facility accessible only to security administrators can dramatically reduce the possibility of such physical attacks.
  • Key management. The CA's private key provides the basis for trust in the certification process and should be secured from tampering. Cryptographic hardware modules (accessible to Certificate Services through a CryptoAPI Cryptographic Service Provider [CSP]) can provide tamper-resistant key storage and isolate the cryptographic operations from other software running on the server. This significantly reduces the likelihood of a CA key being compromised.
  • Restoration. Loss of a CA—due to hardware failure, for example—can create a number of administrative and operational problems and prevent revocation of existing certificates. Certificate Services supports backup of a CA instance so it can be restored at a later time. This is an important part of the overall CA management process.

Certificate Enrollment

The process of obtaining a digital certificate is called certificate enrollment. The Windows 2000 PKI supports certificate enrollment to the Microsoft enterprise CA, standalone CA, or third-party CAs. Enrollment support is implemented in a transport-independent manner and is based on use of industry-standard public-key cryptography standards (PKCS) #10 certificate request messages and PKCS #7 responses containing the resulting certificate or certificate chain. At the time of this writing, certificates supporting RSA keys and signatures, digital signature algorithm (DSA) keys and signatures, and Diffie-Hellman keys are supported.

Multiple Enrollment Methods

The PKI supports multiple enrollment methods, including Web-based enrollment, an enrollment wizard, and policy-driven auto-enrollment that occurs as part of a user's logon processing. Microsoft plans to develop the certificate enrollment process in a manner consistent with the Certificate Request Syntax (CRS) draft currently in the Internet Engineering Task Force (IETF) Public-Key Infrastructure X.509 (PKIX) working group.

Web-Based Enrollment

The Web-based enrollment process begins with a client submitting a certificate request and ends with the installation of the certificate in the client application. Certificate Services includes a Hypertext Transfer Protocol (HTTP) enrollment control with forms, illustrated in Figure 15.3, for custom certificate enrollment and renewal applications for Microsoft Certificate Services. The enrollment control and its forms are accessed through the Certificate Services Enrollment page, which is available from the Certificate Services Administrative Tools Web page, located at http://<server_name>/certsrv/default.asp. You can customize the Microsoft Certificate Services Web pages to modify user options or provide links to online help, support, or user instructions.

Figure 15.3 Certificate Server Web enrollment

Client Certificate Enrollment

Certificate Services supports client certificate enrollment using Internet Explorer version 3.0 or later. To obtain a client certificate with these browsers, the user opens the client authentication page and submits identification information. After Certificate Services creates the client certificate, it is returned to the browser, which installs the certificate on the client.

Automated Enrollment

The automated enrollment process is controlled by two key elements: certificate types and auto-enrollment objects. These are integrated with the Group Policy object and may be defined on a site, domain, organizational unit (OU), computer, or user basis.

Certificate types provide a template for a certificate and associate it with a common name for ease of administration. The template defines elements such as naming requirements, validity period, allowable CSPs for private key generation, algorithms, and extensions that should be incorporated into the certificate. The certificate types are logically separated into machine and user types and applied to the policy objects accordingly. Once defined, these certificate types are available for use with the auto-enrollment objects and Certificate Enrollment wizard.

This mechanism is not a replacement for the enterprise CA issuing policy, but is integrated with it. The CA service receives a set of certificate types as part of its policy object. These are used by the Enterprise Policy Module to define the types of certificates the CA is allowed to issue. The CA rejects requests for certificates that fail to match these criteria.

The auto-enrollment object defines policy for certificates that an entity in the domain should have. This can be applied on a machine and user basis. The types of certificates are incorporated by reference to the certificate type objects and may be any defined type. The auto-enrollment object provides sufficient information to determine whether an entity has the required certificates and enrolls those certificates with an enterprise CA if they are missing. Auto-enrollment objects also define policy on certificate renewal. This policy can be set by an administrator to occur in advance of certificate expiration, which supports long-term operation without direct user action. The auto-enrollment objects are processed, and any required actions taken, whenever policy is refreshed (logon time, Group Policy object refresh, and so on).

Practice: Installing a Standalone Subordinate CA

In this practice, you will install a standalone subordinate CA and then request a certificate to use from the local authority that you setup.

Exercise 1: Installing a Standalone Subordinate CA

In this exercise, you install and configure the standalone subordinate CA.

  1. From Control Panel, select Add/Remove Programs.
  2. Click Add/Remove Windows Components.
  3. Check the box next to Certificate Services, and then click Next.
  4. Select Standalone Root CA, and then click Next.
  5. Fill in the CA identifying information.

    For CA name, type ComputernameCA and then click Next.

  6. Use the default data storage locations, and then click Next.
  7. During the CA installation process, you may need to click OK to stop the World Wide Web Publishing Service, and you need to give the location of the Windows 2000 installation files (specifically Certsrv.*).
  8. Click Finish.
  9. Close the Add/Remove Programs window.

Exercise 2: Requesting a Certificate from the Local CA

Now that the CA is installed, you can request a certificate.

  1. Run Certificate Authority Manager.

    Notice that the service is started (indicated by a check mark), as illustrated in Figure 15.4.

Figure 15.4 Certificate Authority Manager

  1. Run Internet Explorer and connect to http://<your_server>/certsrv/default.asp.
  2. Request a Web browser certificate. The request will be pending.
  3. Close Internet Explorer.
  4. Open Certificate Authority and select the Pending Requests folder. Right-click your request and choose Issue from the All Tasks menu.

    In the left pane select the Issued Certificates folder, and notice that your request has been issued.

  5. Run Internet Explorer, connect to http://<your_server>/certsrv/default.asp , check on the Pending Certificate Request, and then install the certificate.
  6. From the Tools menu, click Internet Options, Content, and then Certificates.
  7. Under Certificates, highlight your certificate, and then click View. Notice that the certificate was issued by your computer, and close all windows.

Cryptographic Key Storage

Within the Microsoft PKI, cryptographic keys and associated certificates are stored and managed by the CryptoAPI subsystem. Keys are managed by CSPs and certificates are managed by the CryptoAPI certificate stores. The certificate stores are repositories for certificates, along with associated properties. By convention, the PKI defines five standard certificate stores, described in Table 15.1.

Table 15.1 Standard PKI Certificate Stores

Store Description
MY This store is used to hold a user's or computer's certificates, for which the associated private key is available.
CA This store is used to hold issuing or intermediate CA certificates to use in building certificate verification chains.
TRUST This store is used to hold certificate trust lists. These are an alternate mechanism for allowing an administrator to specify a collection of trusted CAs. An advantage of this type of store is that it is digitally signed and may be transmitted over nonsecure links.
ROOT This store holds only self-signed CA certificates for trusted root CAs.
UserDS This store provides a logical view of a certificate repository stored in Active Directory (for example, in the userCertificate property of the User object). Its purpose is to simplify access to these external repositories.

These are logical stores that can present a consistent, systemwide view of the available certificates that may reside on multiple physical stores (hard disk, smart cards, and so on). By using these services, applications can share certificates and are assured of consistent operation under administrative policy. The certificate management functions support decoding of X.509 v3 certificates and provide enumeration functions to assist in locating a specific certificate.

To simplify application development, the MY store maintains certificate properties that indicate the CSP and key-set name for the associated private key. Once an application has selected a certificate to use, it can use this information to obtain a CSP context for the correct private key.

Certificate Renewal

Certificate renewal is conceptually similar to enrollment, but takes advantage of the trust relationship inherent in an existing certificate. Renewal assumes the requesting entity wants a new certificate with the same attributes as an existing, valid certificate, but with extended validity dates. A renewal may use the existing public key or a new public key.

Renewal is of advantage primarily to the CA. A renewal request can presumably be processed more efficiently because the existing certificate attributes do not need to be verified again. Renewal is currently supported in the Windows 2000 PKI for automatically enrolled certificates. For other mechanisms, a renewal is treated as a new enrollment request.

Industry-standard message protocols for certificate renewal are not yet defined, but are included in the IETF PKIX CRS draft. Once these standards are ratified, Microsoft plans to implement the associated message formats.

Certificate and Key Recovery

Public-key pairs and certificates tend to have high value. If they are lost due to system failure, their replacement may be time-consuming and result in monetary loss. To address this issue, the Windows 2000 PKI supports enable you to back up and restore both certificates and associated key pairs through the certificate management administrative tools.

When exporting a certificate using the Certificate Manager, the user must specify whether to also export the associated key pair. If this option is selected, the information is exported as an encrypted (based on a user-supplied password) PKCS #12 message. This may later be imported to the system, or to another system, to restore the certificate and keys.

This operation assumes that the key pair is exportable by the CSP. This is true for the Microsoft Base Cryptographic Provider if the exportable flag was set at key generation time. Third-party CSPs may or may not support private key export. For example, smart card CSPs do not generally support this operation. For software CSPs with nonexportable keys, the alternative is to maintain a complete system-image backup, including all registry information.


Roaming in the context of this discussion means the ability to use the same public key-based applications on different computers within the enterprise's Windows 2000 environment. The principal requirement is to make users' cryptographic keys and certificates available wherever they log on. The Windows 2000 PKI supports this in two ways.

First, if the Microsoft Base Cryptographic Providers are used, roaming keys and certificates are supported by the roaming profile mechanism. This is transparent to the user once roaming profiles are enabled. It is unlikely that this functionality will be supported by third-party CSPs, as they will generally use a different method of preserving key data, often on hardware devices.

Hardware token devices, such as smart cards, support roaming, provided they incorporate a physical certificate store. The smart card CSPs that ship with the Windows 2000 platform support this functionality. Roaming support is accomplished by moving the hardware token with the user.


Certificates tend to be long-lived credentials. There are a number of reasons these credentials may become untrustworthy prior to their expiration. Those reasons include the following:

  • Compromise, or suspected compromise, of an entity's private key
  • Fraud in obtaining the certificate
  • Change in status

PK-based functionality assumes distributed verification in which there is no need for direct communication with a central trusted entity that vouches for these credentials. This creates a need for revocation information that can be distributed to individuals attempting to verify certificates.

The application determines if and when revocation information is required. To support a variety of operational scenarios, the Windows 2000 PKI incorporates support of industry-standard certificate revocation lists (CRLs). Enterprise CAs support certificate revocation and CRL publication to Active Directory under administrative control. Domain clients can fetch this information, caching it locally, to use when verifying certificates. This same mechanism supports CRLs published by commercial CAs or third-party certificate server products, provided the published CRLs are accessible to clients over the network.


Certificate verification is of primary concern to clients using PK-based applications. If a given end-entity certificate can be shown to "chain" to a known trusted root CA, and if the intended certificate usage is consistent with the application context, it is considered valid. If either of these conditions is not true, it is considered invalid.

Within the PKI, users may make trust decisions that affect only themselves. They do this by installing or deleting trusted root CAs and by configuring associated usage restrictions by using the certificate management administrative tools. Within the enterprise, this is expected to be the exception rather than the rule. It is expected that these trust relationships will be established as part of the enterprise policy. Trust relationships established by policy are automatically propagated to Windows 2000 client computers.

Trusted CA Roots

Trust in root CAs may be set by policy to establish trust relationships used by domain clients in verifying PK certificates. The set of trusted CAs is configured using the Group Policy editor. It can be configured on a per-computer basis and will apply to all users of that computer.

In addition to establishing a root CA as trusted, the administrator can set usage properties associated with the CA. If specified, these restrict the purposes for which the CA-issued certificates are valid. Restrictions are specified based on object identifiers as defined for ExtendedKeyUsage extensions in the IETF PKIX Part 1 draft. Currently, these restrictions can be applied to the usage of any combination of the following:

  • Server authentication
  • Client authentication
  • Code signing
  • E-mail
  • IP Security Protocol (IPSec) end system
  • IPSec tunnel
  • IPSec user
  • Time stamping
  • Microsoft Encrypted File System

Lesson Summary

In this lesson, you learned how to install and protect your CA. CAs are highly valued resources and it is important to protect them. You also learned various ways to provide enrollment of certificates. To obtain a client certificate, the user opens the client authentication page and submits identification information. Then, Certificate Services creates the client certificate that is returned to the browser and installed on the client.

MCSE Training Kit(c) Microsoft Windows 2000 Accelerated 2000
MCSE Training Kit(c) Microsoft Windows 2000 Accelerated 2000
Year: 2004
Pages: 244

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net