Information Technology Reference
In-Depth Information
In the two-level hierarchy, the root CA issues certificates to subordinate CAs and then is usu-
ally taken offline for security. The subordinate CAs are referred to as issuing CAs because they
interact with clients to field certificate requests and maintain the CRL. Because the root CA
issues certificates to issuing CAs and the clients trust the root CA, they also trust the issuing CAs.
Issuing CAs are generally enterprise CAs or can be a combination of enterprise and standalone
if the network includes non-Windows clients.
The three-level hierarchy is a common configuration and offers the most security because the
issuing CAs, where user certificate requests are made, is farther removed from the root CA. In
this arrangement, the root CA issues certificates to intermediate CAs (sometimes called policy
CAs), authorizing them to issue certificates to other CAs. Intermediate CAs issue certificates to
issuing CAs, which respond to user and device certificate requests. The root CA and intermedi-
ate CAs can be standalone and operate in offline mode. Issuing CAs can be a mix of enterprise
and standalone CAs and operate in online mode.
Multilevel CA hierarchies are often used to distribute the certificate-issuing load in organi-
zations that have multiple locations. Each intermediate CA is responsible for one or more issu-
ing CA in each location. In Figure 11-2, for example, one intermediate CA and its subordinate
issuing CAs might handle certificate management for the U.S. location, and the other intermedi-
ate and issuing CAs handle certificates for the Europe location.
Certificate Practice Statement
A certificate practice statement (CPS) is a document describing how a CA issues certificates. A CPS
is not a required component of a PKI, but it should be developed as part of the planning process
when an organization is designing its PKI. The document is usually published on the Internet, and
every certificate the CA issues has a URL pointing to the CPS so that people examining the certifi-
cate can read the statement. Because the CPS describes the process used to issue certificates, it can
be used as a guide when deploying your CA design. A CPS usually contains the following elements:
• Identification of the CA
• Security practices used to maintain CA integrity
• Types of certificates issued
• Policies and procedures used when issuing, revoking, recovering, and renewing certificates
• Cryptographic algorithms used
• Certificate lifetimes
• CRL-related policies, including where CRL distribution points are located
• Renewal policy of the CA's certificate
The CPS is installed by creating a CAPolicy.inf file and placing the file in the CA server's
%systemroot% directory before the AD CS role is installed. For more about creating a
CAPolicy.inf file, see http://technet.microsoft.com/en-us/library/cc728279.aspx .
Installing the AD CS Role
Best practices dictate that the AD CS role shouldn't be installed on a domain controller. In fact,
for optimum security, AD CS should probably be the only role installed on the server. If you're
installing a standalone CA, the server can be a member server if you want to take advantage of
the limited Active Directory integration possible with standalone CAs. An enterprise CA must
be installed on a member server running Windows Server 2008 Enterprise or Datacenter Edition.
Activity 11-1: Demoting Server1XX to a Member Server
Time Required: 20 minutes
Objective: Demote Server1XX to a member server.
Description: You're ready to begin implementing AD CS. You have an excess of domain con-
trollers on your network, and you don't want to install AD CS on a domain controller. You
demote one of your DCs to a member server in preparation for installing AD CS.
 
Search WWH ::




Custom Search