Your network consists of a single Active Directory domain. All domain controllers run Windows
Server 2008 R2. You need to implement a Certificate Services solution that meets the following
requirements:
• Automates the distribution of certificates for internal users
• Ensures that the network’s certificate infrastructure is as secure as possible
• Gives external users access to resources that use certificate based authentication
What should you do?
A.
Deploy an online standalone root certification authority (CA). Deploy an offline standalone root
CA.
B.
Deploy an offline enterprise root certification authority (CA). Deploy an offline enterprise
subordinate CA.
C.
Deploy an offline standalone root certification authority (CA). Deploy an online enterprise
subordinate CA. Deploy an online standalone subordinate CA.
D.
Deploy an online standalone root certification authority (CA). Deploy an online enterprise
subordinate CA. Deploy an online standalone subordinate CA.
Explanation:
Certification authority hierarchies
The Microsoft public key infrastructure (PKI) supports a hierarchical certification authority (CA)
model. A certification hierarchy provides scalability, ease of administration, and consistency with a
growing number of commercial and other CA products.
In its simplest form, a certification hierarchy consists of a single CA. However, in general, a hierarchy
will contain multiple CAs with clearly defined parent-child relationships. In this model, the child
subordinate certification authorities are certified by their parent CA-issued certificates, which bind a
certification authority’s public key to its identity. The CA at the top of a hierarchy is referred to as the
root authority, or root CA. The child CAs of the root CAs are called subordinate certification
authorities (CAs).
A root certification authority (CA) is the top of a public key infrastructure (PKI) and generates a selfsigned certificate. This means that the root CA is validating itself (self-validating). This root CA could
then have subordinate CAs that effectively trust it. The subordinate CAs receive a certificate signed
by the root CA, so the subordinate CAs can issue certificates that are validated by the root CA. This
establishes a CA hierarchy and trust path.
http ://social.technet.microsoft.com/wiki/contents/articles/2900.offline-root-certification-authorityca.aspx
Certification authority hierarchies
The Microsoft public key infrastructure (PKI) supports a hierarchical certification authority (CA)
model. A certification hierarchy provides scalability, ease of administration, and consistency with a
growing number of commercial and other CA products.
In its simplest form, a certification hierarchy consists of a single CA. However, in general, a hierarchy
will contain multiple CAs with clearly defined parent-child relationships. In this model, the child
subordinate certification authorities are certified by their parent CA-issued certificates, which bind a
certification authority’s public key to its identity. The CA at the top of a hierarchy is referred to as theroot authority, or root CA. The child CAs of the root CAs are called subordinate certification
authorities (CAs).
Authentication and Authorization
Stand-alone CAs use local authentication for certificate requests, mainly through the Web
enrollment interface.
Stand-alone CAs provide an ideal service provider or commercial PKI provider platform for issuing
certificates to users outside of an Active Directory environment where the user identity is separately
verified and examined before the request is submitted to the CA.
Offline and Online CAs
Traditionally, the decision of whether to use either an online or offline CAs involves a compromise
between availability and usability versus security. The more sensitive that the key material is and the
higher the security requirements are, the less accessible the CA should be to users.
Specifying CA Roles
An ideal PKI hierarchy design divides the responsibility of the CAs. A topology that is designed with
requirements that have been carefully considered provides the most flexible and scalable enterprise
configuration. In general, CAs are organized in hierarchies. Single tier hierarchies might not provide
adequate security compartmentalization, extensibility and flexibility. Hierarchies with more than
three tiers might not provide additional value regarding security, extensibility and flexibility.
The most important consideration is protecting the highest instance of trust as much as possible.
Single-tier hierarchies are based on the need to compartmentalize risk and reduce the attack surface
that is available to users who have malicious intent. A larger hierarchy is much more difficult to
administer, with little security benefit.
Depending on the organization’s necessities, a PKI should consist of two or three logical levels that
link several CAs in a hierarchy. Administrators who understand the design requirements for a threelevel topology may also be able to build a two-level topology.
A three-tier CA hierarchy consists of the following components:
A root CA that is configured as a stand-alone CA without a network connection
One or more intermediate CAs that are configured as stand-alone CAs without a network connection
One or more issuing CAs that are configured as enterprise CAs that are connected to the network
Also worth a look though it refers to windows 2003
http ://technet.microsoft.com/en-us/library/cc779714%28WS.10%29.aspx
