Share via

What Are CA Certificates?

  • Article

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

Certification authority (CA) certificates are certificates that are issued by a CA to itself or to a second CA for the purpose of creating a defined relationship between the two CAs.

A certificate that is issued by a CA to itself is referred to as a trusted root certificate, because it is intended to establish a point of ultimate trust for a CA hierarchy.

Once the trusted root has been established, it can be used to authorize subordinate CAs to issue certificates on its behalf.

Although the relationship between CAs is most commonly hierarchical, CA certificates can also be used to establish trust relationships between CAs in two different public key infrastructure (PKI) hierarchies.

In all of these cases, the CA certificate is critical to defining the certificate path and usage restrictions for all end entity certificates issued for use in the PKI.

Problems Solved by CA Certificates

When an end entity uses a certificate, a trust relationship must be verified between the end entity certificate and the root CA. This trust relationship between a root CA and an end entity certificate is verified by validating the contents of all of the certificates in the certificate chain up to the root CA.

The guidelines and procedures that have been established for the PKI define the trust. This includes the ability of end entity certificates to be used for certain purposes and prevented from being used for other purposes. These guidelines and procedures are implemented in a number of ways. For example, the trust and the security of the PKI can be established in two ways:

  • The steps taken to ensure the physical security of the server that hosts the CA.

  • The manner in which administrative roles for the CA are delegated.

However, the appropriate configuration of CA certificates for the organization’s needs is one of the most powerful tools that an organization has to implement appropriate PKI security.. CA certificates contain special configuration data that regulate the CAs to which they are issued. These configuration options can:

  • Define the organizational namespace in which certificates issued by the subordinate CA can be issued and trusted.

  • Specify the acceptable uses of certificates issued by the subordinate CA.

  • Define the issuance guidelines that must be followed in order for a certificate issued by the subordinate CA to be considered valid.

  • Create a managed trust between separate certification hierarchies.

Core CA Certificate Use Scenarios

Trust and acceptable use are integrally connected: How much you trust a certificate should help you decide whether it is acceptable for a predetermined use at a specific time in a specific location.

This is the most basic security and business principle in PKI deployment: you must create defined trust relationships within an enterprise.. Once this is done, you can use defined trusts to enable certificate types of connections while limiting others. For example, they can:

  • Prevent certificates from being used with unintended applications.

  • Apply consistent certificate issuance policies.

  • Apply consistent name formatting in issued certificates.

  • Prevent the implementation of unauthorized subordinate CAs.

The following are some of the trust scenarios that can be enabled by properly configured CA certificates:

  • Simple trust within an enterprise PKI

  • Cross trust between two enterprise CAs (restricted)

  • Bridge trust for multiple enterprise PKIs (unrestricted)

  • Certificate trust continuity when the certificate policy changes

Simple Trust Within an Enterprise

Simple trusts between CAs in a single PKI are the most common type of certificate trust relationships. They impose clear hierarchical roles and relationships between the root CA, intermediate policy CAs, the CAs that issue end entity certificates (if any), and the end-entity certificates themselves.

The following diagram illustrates a simple PKI trust hierarchy in a single organization.

Simple PKI trust hierarchy in a single organizatio

Cross Trust Between Two CAs

Cross trust between two CAs allows an organization to extend a simple PKI trust hierarchy to secondary PKI trust hierarchies within the same organization or within other organizations. You can implement cross trust by using special CA certificates called cross certificates and a strategy called qualified subordination. Qualified subordination allows you to place certificate issuance constraints on subordinate CAs and to place usage constraints on the certificates they issue. With qualified subordination, you can focus subordinate CAs according to specific certification needs and administer your public key infrastructure (PKI) more efficiently. With qualified subordination, each CA in a cross trust relationship can define and implement rules that do the following:

  • Define the namespaces for which your PKI hierarchy will issue and accept trusted certificates

  • Specify the acceptable uses of certificates issued by a cross-certified subordinate CA

  • Define what issuance practices must be followed for a certificate issued by the qualified subordinate CA to be considered valid.

For example, suppose that, due to a merger, Organization 1 wants to share certain certificate-protected resources with users in the engineering department of Organization 2. They can accomplish this by creating a cross trust with a specific CA in Organization 2, but limit the locations and applications in organization 1 for which Organization 2’s certificates can be used.

These cross CA trusts are one-directional. If Organization 2 wants to grant Organization 1 certificate users privileges within Organization 2, they must establish a separate cross trust in order to enable this certificate use.

The following figure illustrates one typical cross CA trust relationship. There are two-way trust relationships between the CAs in both Organization 1 and Organization 2, but trust between the two organizations is managed using two separate one-way trusts, so that each organization can determine the degree and type of trust it wants to share with the other organization.

Two separate one-way trusts

Cross certificates restrict the certificates that are acceptable to your organization. They can be issued by either the qualified subordinate CA or by CAs that chain through the qualified subordinate CA,. The configuration options that you apply in the cross certificates between the two organizations allow you to:

  • Limit trust to all CAs in your organization

  • Limit trust to specific CAs in your organization.

  • Restrict the name space available to certificate holders from the other organization

  • Add new CAs to an existing CA hierarchy

  • Apply application policy that defines the purposes for which certificates issued by a subordinate CA can be used

  • Apply policy constraints

  • Map CA policy in one organization to CA policy in another organization

  • Create trust between two organizations

  • Create trust between multiple organizations

CA Certificate Dependencies and Interactions

A number of factors can impact interoperability between a Windows Server 2003 CA and the CAs of other organizations. The interoperability of Windows Server 2003 PKIs with non-Microsoft PKIs is dependent on how the following features and standards are implemented in both PKIs:

  • Standards support

  • Algorithm and key length support

  • CRL distribution points

  • Authority information access (AIA)

  • Authority key identifier (AKI)

  • Certificate extensions

  • Extended key usage (EKU)

  • Directory integration

You must determine whether the other PKIs with which you need to establish trust support these features and standards, and how you can accommodate differences.

Standards Support

A number of technical standards provide a basis for interoperability between Windows Server 2003 and other PKI applications. To promote non-Microsoft interoperability with the Windows Server 2003 application programming interface (API), Microsoft supports the following standards:

  • Public Key Infrastructure for X.509 Certificates (PKIX). Defines interoperable PKI standards for the Internet.

  • X.509. Describes the standard format of a certificate.

  • Public-Key Cryptography System (PKCS). Provides a standard for public key message exchanges.

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

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

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

  • Personal Computer/Smart Card (PC/SC). Serves as a standard for integrating smart cards and smart card readers.

Most PKI vendors have adopted many or all of these PKI standards. Different vendors, however, can implement the standards in different ways. While it might be possible to link external PKI implementations to yours, this might involve making some changes to your existing design. For this reason, it is strongly recommended that you evaluate the external PKI to determine whether it meets all your critical requirements.

Hardware Support

Windows Server 2003 uses CryptoAPI to abstract hardware-based key management from applications, and it uses the PC/SC standard instead of PKCS #11 to communicate with smart cards and readers. Many non-Microsoft CAs have their own cryptographic APIs and use PKCS #11 to interface to hardware tokens such as smart cards. Because the Windows 2000 and Windows Server 2003 operating systems require hardware devices to support Plug and Play and power management features, and PC/SC includes support for these ease-of-use features, Windows Server 2003 does not support PKCS #11.

Note

  • The Windows Server 2003 PKI can use non-Microsoft cryptographic service providers (CSPs), and can enroll users for certificates that have keys that were generated by non-Microsoft CSPs.

Algorithm and Key Length Support

Windows 2000 and Windows Server 2003 support several well-known cryptographic algorithms that are also supported by other PKI products. Key length, in turn, is determined in part by the cryptographic algorithm that you select. When you install a Windows Server 2003 CA, you can select CA key lengths from 384 bits to 16,384 bits, depending on the CSP that you select. In a typical deployment, user certificates have 1,024-bit keys and root CAs have 4,096-bit keys.

In general, the lengths of public and private keys do not impact interoperability, as long as both environments support a common range of key lengths. If one PKI supports large public keys and another does not, however, the two cannot exchange symmetric keys or sign and verify data.

Note

  • While key exchange and digital signature operations performed between PKIs do not require the same public and private key lengths, symmetric key algorithms do. In addition, if different key lengths are used, both key lengths must be supported in both environments.

When PKIs do not support the same key lengths, some applications cannot decrypt data that other applications have encrypted. In addition, the PKIs might not be able to establish secure communications channels between applications if the applications cannot agree on symmetric key lengths, as required by protocols such as Secure Sockets Layer (SSL) and TLS.

If a PKI uses public key cryptography based on an algorithm such as RSA, all PKI operations can be accomplished with only one key pair. However, single key pairs might not meet the security requirements of your organization or its choice of algorithm. For this reason, Windows Server 2003 supports both single key pairs and dual key pairs. A good PKI is flexible enough to allow as many or as few key pairs as are required by applications.

If one PKI operates according to the number of keys that applications use, it can impact interoperability with other PKIs. For example, an e-mail application could sign a message with a signature-only key and include the associated certificate in a message sent to a recipient without also sending an encryption certificate as part of the message. The recipient might then be unable to discover the encryption certificate of the sender to reply with an encrypted message back to the sender.

CRL Distribution Points

With certificate revocation lists (CRLs), the optional CRL distribution point (CDP) extension in a certificate identifies how revocation information for the certificate can be obtained. If a CRL distribution point is not always available, certificate chain building can be delayed, causing inconvenience for the user. If a CRL is not available at the distribution point that has been specified in the certificate, CRL retrieval might even fail and the certificate will be considered invalid.

You need to compare any non-Microsoft CRL support with the Windows Server 2003 CRL support. For example, the non-Microsoft PKIs might not support the Windows Server 2003 CRL process, which includes the use of delta CRLs. Conversely, the Windows Server 2003 PKI might not support the methods of the non-Microsoft PKI for processing CRL information. Also, a few non-Microsoft PKIs support partitioned CRLs, which most PKIs, including Windows Server 2003 PKIs, do not support.

Authority Information Access

The Authority Information Access (AIA) extension is a pointer to the most currently published CA parent certificate of a CA. The Windows Server 2003 PKI uses this extension to assist in building trust chains to validate client certificates.

Some non-Microsoft PKIs do not provide the AIA extension. In this case, parent certificates must be distributed to domain clients so that the certificates are available before the chain building process begins. Cross certificates must also be available locally on domain clients, because there is no information in a certificate that specifies where it can be found.

Authority Key Identifier

The Authority Key Identifier (AKI) extension provides a means to identify the public key of the CA that validates the signature on a CRL. This identification is based on either the subject key identifier (SKI) or the issuer name and serial number from the certificate that is issued by the CRL issuer. The AKI extension is useful in cases when a CRL issuer has more than one signing key.

An organization that expects its PKI certificates to be used by other Windows Server 2003 PKIs must populate the Authority Key Identifier extension with a unique key identifier and an issuer name and serial number. The Windows Server 2003 PKI attempts to construct certificate chains by using the issuer name and serial number in the AKI first, and then the subject key identifier.

Certificate Extensions

Not all certificate extensions are universally recognized. If a CA does not recognize a certificate extension in a request and it has been marked critical, it rejects the certificate. Unless you intend to limit the use of the certificate to a specific application that understands the critical extension, avoid putting critical extensions in certificates because it limits interoperability.

Extended Key Usage

The Extended Key Usage (EKU) extension indicates the purposes for which the public key that is contained in the certificate can be used. The Windows Server 2003 PKI uses the EKU extension to indicate certificates that support special functions, such as Internet protocol security (IPSec) and encrypting file system (EFS) file encryption backup. The EKU extensions of other organizations may be used for different purposes.

Directory Integration

Windows Server 2003 PKI certificates can be published to any directory or repository, although the default CA exit module only supports Active Directory. However, by default, a Windows Server 2003 PKI relies on Active Directory and LDAP for authentication, including smart card logons and certificate autoenrollment, as well as for certificate management.

With Microsoft Certificate Services, certificates issued by a non-Microsoft CA can be associated with a Windows Server 2003 user account stored in Active Directory. This is possible because applications such as Internet Explorer and Internet Information Services (IIS) can be used to authenticate a user to an account stored in Active Directory, based on the user principal name (UPN) information in a certificate.

The account to which the certificate maps provides information about user access rights on the server. This is an extremely powerful feature for Web-based applications and non-Microsoft CAs because it combines strong authentication by means of public key technology with the native authorization model of Windows Server 2003. For example, to enable extranet and remote access scenarios without requiring the application and certificate to manage access rights, administrators can use certificates from partner companies and map them to accounts in Active Directory by means of one-to-one or many-to-one mappings.

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