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
Estimated lesson time: 35 minutes
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.
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.
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:
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.
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.
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
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.
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).
In this practice, you will install a standalone subordinate CA and then request a certificate to use from the local authority that you setup.
In this exercise, you install and configure the standalone subordinate CA.
For CA name, type ComputernameCA and then click Next.
Now that the CA is installed, you can request a certificate.
Notice that the service is started (indicated by a check mark), as illustrated in Figure 15.4.
Figure 15.4 Certificate Authority Manager
In the left pane select the Issued Certificates folder, and notice that your request has been issued.
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 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.
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:
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.
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:
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.