Defining CA Types and Roles

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

To plan your CA infrastructure, you need to understand the different types of CAs available with Windows Server 2003 and the roles that they can play. Windows Server 2003 Certificate Services supports the following two types of CAs:

• Enterprise
  
• Stand-alone
  

Enterprise and stand-alone CAs can be configured as either Root CAs or Subordinate CAs. Subordinate CAs can further be configured as either Intermediate CAs (also referred to as a policy CA) or Issuing CAs.
Before you create your CA infrastructure, you need to determine the type or types of CAs that you plan to use, and define the specialized roles that you plan to have each CA assume.

Enterprise vs. Stand-Alone CAs

Enterprise CAs are integrated with Active Directory. They publish certificates and CRLs to Active Directory. Enterprise CAs use information stored in Active Directory, including user accounts and security groups, to approve or deny certificate requests. Enterprise CAs use certificate templates. When a certificate is issued, the enterprise CA uses information in the certificate template to generate a certificate with the appropriate attributes for that certificate type.
If you want to enable automated certificate approval and automatic user certificate enrollment, use enterprise CAs to issue certificates. These features are only available when the CA infrastructure is integrated with Active Directory. Additionally, only enterprise CAs can issue certificates that enable smart card logon, because this process requires that smart card certificates be mapped automatically to the user accounts in Active Directory.
Stand-alone CAs do not require Active Directory and do not use certificate templates. If you use stand-alone CAs, all information about the requested certificate type must be included in the certificate request. By default, all certificate requests submitted to stand-alone CAs are held in a pending queue until a CA administrator approves them. You can configure stand-alone CAs to issue certificates automatically upon request, but this is less secure and is usually not recommended, because the requests are not authenticated.
From a performance perspective, using stand-alone CAs with automatic issuance enables you to issue certificates at a faster rate than you can by using enterprise CAs. However, unless you are using autoissuance, using stand-alone CAs to issue large volumes of certificates usually comes at a high administrative cost because an administrator must manually review and then approve or deny each certificate request. For this reason, stand-alone CAs are best used with public key security applications on extranets and the Internet, when users do not have Windows 2000 or Windows Server 2003 accounts, and when the volume of certificates to be issued and managed is relatively low.
You must use stand-alone CAs to issue certificates when you are using a third-party directory service or when Active Directory is not available.
Note

• You can use both enterprise and stand-alone certification authorities in your organization.
  

Table 16.3 lists the options that each type of CA supports.
Table 16.3   Options for Enterprise vs. Stand-Alone CAs

 

Option	Enterprise CA	Stand-alone CA
Publish certificates in Active Directory and use Active Directory to validate certificate requests.
Take the CA offline.
Configure the CA to issue certificates automatically.
Allow administrators to approve certificate requests manually.
Use certificate templates.
Authenticate requests to Active Directory.

Root CAs

A root CA is the CA that is at the top of a certification hierarchy and must be trusted unconditionally by clients in your organization. All certificate chains terminate at a root CA. Whether you use enterprise or stand-alone CAs, you need to designate a root CA.
Because there is no higher certifying authority in the certification hierarchy, the subject of the certificate issued by a root CA is also the issuer of the certificate. Likewise, because the certificate chain terminates when it reaches a self-signed CA, all self-signed CAs are root CAs. Windows Server 2003 only allows you to designate a self-signed CA as a root CA. The decision to designate a CA as a trusted root CA can be made at either the enterprise level or locally, by the individual IT administrator.
A root CA serves as the foundation upon which you base your certification authority trust model. It guarantees that the subject public key belongs to the subject identity information that is contained in the certificates it issues. Different CAs might also verify this relationship by using different standards; therefore it is important to understand the policies and procedures of the root certification authority before choosing to trust that authority to verify public keys.
The root CA is the most important CA in your hierarchy. If your root CA is compromised, every other CA and certificate in your hierarchy might have been compromised. You can maximize the security of the root CA by keeping it disconnected from the network and using subordinate CAs to issue certificates to other subordinate CAs or to end users.
For more information about using a third-party CA as the root CA, see "Extending Your CA Infrastructure" later in this chapter. For more information about disconnecting CAs from the network, see "Using Offline CAs" later in this chapter.

Subordinate CAs

CAs that are not root CAs are considered subordinate. The first subordinate CA in a hierarchy obtains its CA certificate from the root CA. This first subordinate CA can, in turn, use this key to issue certificates that verify the integrity of another subordinate CA. These higher subordinate CAs are referred to as intermediate CAs. An intermediate CA is subordinate to a root CA, but also serves as a higher certifying authority to one or more subordinate CAs.
An intermediate CA is often referred to as a policy CA because it is typically used to separate classes of certificates that can be distinguished by policy. For example, policy separation includes the level of assurance that a CA provides or the geographical location of the CA to distinguish different end-entity populations. A policy CA can be online or offline.
Note

• Most organizations use one root CA and two policy CAs — one to support internal users, the second to support external users.
  

The next level in the CA hierarchy usually contains the issuing CA. The issuing CA issues certificates to users and computers and is almost always online. In many CA hierarchies, the lowest level of subordinate CAs is replaced by RAs, which can act as an intermediary for a CA by authenticating the identity of a user who is applying for a certificate, initiating revocation requests, and assisting in key recovery. Unlike a CA, however, an RA does not issue certificates or CRLs; it merely processes transactions on behalf of the CA.