Share via

What Is Certificate Services?

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

In this section

  • Common Certificate Services Scenarios

  • Technologies Related To Certificate Services

  • Certificate Services Dependencies

  • Related Information

Windows Server 2003 Certificate Services provides customizable services for creating and managing public key certificates used in software security systems employing public key technologies.

Organizations use certificates to enhance security by binding the identity of a person, device, or service to a corresponding private key. However, in order to realize the enhanced security made possible by certificates, organizations need a cost effective, efficient, secure way to manage the distribution and use of certificates.

A server configured as a certification authority (CA) provides the management features needed to regulate certificate distribution and use. A CA:

  • Configures the format and content of certificates and issues certificates to users, computers, and services.

  • Establishes and verifies the identities of certificate holders.

  • Sets policies that control how certificates are to be used.

  • Revokes certificates if they should no longer be considered valid and publishes certificate revocation lists (CRLs) to be used by certificate verifiers.

  • Logs all request, issuance, renewal, and revocation transactions.

Certificate Services is the Windows Server 2003 service that provides the core functionality for Windows Server 2003 CAs. Certificate Services provides customizable services for managing certificates for a particular CA and for the enterprise.

Common Certificate Services Scenarios

Managing certificates and CAs involves the following processes:

  • Issuing certificates to users and computers. The issuance process includes obtaining and validating information about the intended recipient of the certificate, placing policy restrictions designated by the organization in certificates that are issued, and publishing the certificates to a directory.

  • Managing certificate lifetimes. Because all certificates have a limited life, certificates need to be renewed or allowed to expire. The renewal process is similar to the issuance process, but typically involves fewer security checks. Thus, when an organization develops its renewal strategy, it should balance security concerns against potential disruptions to users.

  • Revoking certificates and verifying revocation status. Some certificates need to be invalidated before their expiration date. Effective certificate revocation and revocation verification processes are critical to the security of an organization’s public key infrastructure (PKI).

For a more detailed technical description of these processes, see “How Certificate Services Works.”

Issuing Certificates to Users and Computers

A certificate can be used to authenticate the identity of the computer or user that owns the certificate, as well as to encrypt or sign data. Because of this, the certificate issuer must ensure that certificate holders are known entities and meet certain criteria.

In Windows Server 2003, identity verification can be based on:

  • Manual verification of a client’s credentials by a Certificate Manager.

  • Automatic approval based on credentials in Active Directory directory service.

When identity verification is complete, a certificate is constructed based on the certificate policy set by the CA administrator.

Certificate policies are sets of rules that are used when processing certificate requests, issuing certificates, revoking certificates, and publishing certificate revocation lists (CRLs). Certificate policies constitute a combination of administrative policies and configuration settings on the CA:

  • Administrative policies. For example, an administrative policy might grant commercial certificates only if applicants present identification in person. Another administrative policy might grant credentials based on e-mail requests.

  • Configuration settings on the CA. When you install Certificate Services, the CA is configured with a default set of rules and settings. These define CA-specific settings such as the CA’s certificate, the CA’s default issuance behavior, and the CA’s key recovery agents. Along with the CA, you can also install a number of preconfigured certificate templates, which define what information a certificate request must have and how to process incoming requests for a certificate based on a particular template.

The combination of applying CA settings and certificate template settings, plus the defined administrative guidelines, are documented in the certificate policy and practice statements that govern the operation of a CA.

When a certificate request has been processed and the certificate has been created, it needs to be published and made available for use. At this point, Certificate Services returns the certificate to the client to be placed in the client’s certificate store on the local computer, and data about the certificate is recorded in the certificates database on the CA. In addition, the certificate can be published to Active Directory to make it more accessible to others.

Managing Certificate Lifetimes

All certificates have a limited lifetime that needs to be defined by an administrator in a certificate template before the first certificate is issued. The certificate lifetimes that an administrator defines can have an impact on the security of a PKI for the following reasons:

  • Over time, encryption keys become more vulnerable to attack. In general, the longer amount of time that key pairs are in use, the greater the risk that keys can be compromised.

  • When a CA certificate expires, all certificates that are issued by that CA for validation also expire. This is known as time nesting.

End-entity certificates expire when the issuing CA certificate reaches the end of its lifetime, unless:

  • The end-entity certificate is renewed and linked to a CA certificate with a longer lifetime.

  • The end-entity certificate was revoked before the CA certificate expiration date is reached.

Revoking Certificates and Verifying Revocation Status

Unlike a certificate that reaches the end of its lifetime and is not renewed, a certificate might need to be designated unusable before its lifetime is complete. This is done by a process called revocation.

A certificate manager should revoke a certificate if the recipient of the certificate breaks the rules that are defined in the certificate practice statement or if the private key that is associated with the certificate is compromised. For example, a rule might specify that certificates can only be issued to a current employee of the organization or to an employee who performs a specific task. If that employee leaves the organization or is reassigned, the certificate should be revoked. Similarly, a certificate should be revoked if the private key associated with the certificate has been compromised. In either case, the goal is to prevent unapproved use of the certificate and its associated key.

Note

  • Even when a certificate has been revoked, it is up to the party relying on the certificate to decide whether to accept or reject the certificate for an intended purpose. For example, some parties would accept an expired passport as proof of a bearer’s identity, although they would not allow an expired passport to be used to cross a national border.

Verifying revocation status is an important corollary to certificate revocation. When a certificate is issued and used, certificate policies determine whether a certificate requester or certificate user meets the criteria set for the certificate. However, when revocation verification takes place and a certificate is determined to have been revoked, all other certificate policy verifications are overridden. Because a certificate that was valid yesterday might not be acceptable today, the revocation verification process is critical to the integrity of the PKI.

Certificate Services is an enabling technology that can be used in a wide variety of applications. For example, it can be used to enhance the security of technologies such as:

  • Authentication. Certificates and Certificate Services extend and enhance, rather than replace, the security provided by password-based authentication.

  • Access control. Certificates and Certificate Services make it possible to limit user access to highly sensitive data.

  • Digital signing. Certificates and Certificate Services make it possible to positively identify a user who modifies data by applying digital signatures to files and documents.

  • Wireless networking. Certificates and Certificate Services can be used to enhance the authentication process for wireless clients and deter unauthorized users from accessing a wireless network or from viewing data as it crosses between wireless access points and client computers.

  • Virtual private networks (VPNs). Certificates and Certificate Services can be used to authenticate clients that are allowed to initiate VPN connections to an organization’s network. In addition, certificates and Certificate Services can be used to deter unauthorized users from viewing or intercepting data as it crosses the public Internet through a VPN connection.

Because Certificate Services is an enabling technology, technology strategists should consider the business problems faced by their organizations to determine how Certificate Services can help solve those problems.

Certificate Services Dependencies

Using Certificate Services in Windows involves three types of dependencies:

  • What Windows version you are using.

  • Whether the computer is joined to a domain, and the version of Active Directory that the organization is using.

  • Whether the organization’s PKI will be linked to any other organization’s PKI.

Windows Version Dependencies

In Windows Server 2003, Certificate Services includes a number of new and enhanced features. Windows Server 2003 Enterprise Edition includes some enhanced features that are not available with Windows Server 2003 Standard Edition. In addition, using Windows XP Professional clients enhances an organization’s ability to take advantage of many of these new features.

Many features and capabilities require that you run Windows Server 2003 on the server and run Windows XP Professional on the client. The following table illustrates key differences in capabilities that are available in environments using different client and server operating systems.

Feature Dependencies in Certificate Services

  Version 2 Templates Key Archival and Recovery Autoenrollment Delta CRL Qualified Subordination

Description

New features and options including customizable enrollment, validity, issuance, application, and key usage policies

Archival and recovery of private keys associated with a certificate request

Enables the issuance of certificates to computers and users

Lists of certificates whose status has changed since the last full (base) CRL was compiled can be published more frequently with less impact on network capacity.

Administrator can add restrictions to a CA certificate. These restrictions are translated into certificate extensions within issued certificates.

Windows Server 2003 Enterprise Edition

Enterprise CA only

Yes

User and computer

Yes

Yes

Windows Server 2003 Standard Edition

 

 

Computer only

Yes

Yes

Windows 2000 Server

 

 

Computer only

 

 

Windows XP Professional client with Windows 2000 Server CA

 

 

Computer only

 

 

Windows XP Professional client with Windows Server 2003 CA

Yes

Yes

User and computer

Yes

Yes

Windows 2000 Professional client with a Windows 2000 Server CA

 

 

Computer only

 

 

Windows 2000 Professional client with a Windows Server 2003 CA

By Web enrollment support only

By Web enrollment support or programmatic script

Computer only

 

 

Active Directory Dependencies

If you are using Active Directory to manage user and computer accounts on the network, your enterprise CAs can use information contained in Active Directory — such as user account names, security group memberships, and certificate templates — to simplify certificate enrollment, renewal, revocation, and validation.

The Active Directory schema in Windows Server 2003 has been enhanced to enable a number of new Certificate Services capabilities — version 2 templates, key recovery and archival, and delta CRLs, for example — that were described in the previous section.

In addition, Active Directory stores public key Group Policy for distribution to all computers that are within the scope of the policy. Public key Group Policy enables you to control which CAs are to be trusted in the enterprise, to specify alternative Encrypting File System (EFS) recovery agents, and to configure automatic enrollment and renewal of certificates for computers running Windows 2000, Windows XP, and Windows 2003 — all from a central administration point.

Active Directory also supports mapping certificates to network user accounts for authenticating clients and controlling access to network resources. Using smart cards for the user logon process is a special case of certificate mapping that extends the Kerberos V5 authentication protocol to include authentication of users on the basis of certificates and private keys that are stored on smart cards. Using smart cards for the user logon process provides enhanced security for user authentication and a single set of user credentials for logging on locally or remotely over a network.

The Active Directory schema in Windows Server 2003 has been enhanced to enable a number of new Certificate Services capabilities — for example, version 2 templates, key recovery and archival, and delta CRLs — that were described in the previous section.

Non-Microsoft Dependencies

Windows Server 2003 Certificate Services is based on common industry standards defined by the Internet Engineering Task Force (IETF) Public Key Infrastructure (PKIX) working group and others. Windows Server 2003 Certificate Services supports the following industry standards:

  • RFC 2313 (PKCS #1). A method for encrypting data using Rivest-Shamir-Adleman (RSA) public key cryptography.

  • RFC 2527. A framework for creating certificate policies and certification practice statements for CAs and PKIs.

  • RFC 2528. Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Certificates.

  • RFC 2559. Addresses operational protocols that make it possible to retrieve data regarding X.509 certificates and CRLs from an LDAP directory.

  • RFC 2560. Guidelines for support of Online Certificate Status Protocol (OCSP).

    Note

    • This requires the use of non-Microsoft OCSP software.

  • RFC 2585. Specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and CRLs from PKI repositories.

  • RFC 2587. Defines auxiliary object classes that need to be supported in an LDAP schema to support PKIX requirements.

  • RFC 2255. Guidelines for formatting LDAP URLs. Clarifies how LDAP URLs are resolved.

  • RFC 2797. Defines a certificate management protocol using Certificate Management Messages over CMS.

  • RFC 3280. Formatting of X.509 v3 certificates and X.509 v2 CRLs for use on the Internet.

In addition, Windows Server 2003 Certificate Services also supports industry standards that enable the following:

  • Transport Layer Security (TLS). Provides a secure and authenticated channel between hosts on the Internet above the transport layer.

  • Secure Multi-purpose Internet Mail Extensions (S/MIME). Serves as a standard for secure e-mail across the Internet.

  • Kerberos V5 authentication protocol. Provides a symmetric key framework for authentication in networks.

A PKI based on Certificate Services can generally be linked to an external organization’s PKI, even if the external PKI is not based on Certificate Services, so long as the external PKI supports the above standards. A detailed comparison of how each PKI implements these standards is generally required in order to determine compatibility.

The following resources contain additional information that is relevant to this section.