Exam 70-124: Objective 3.1.4: Certificate Authorities

Digital certificates provide a way to validate public keys. By definition, the issuer of a Public Key Certificate is known as a certificate authority (CA). CA's are responsible for validating the identity of a person or organization and for joining that entity with a key pair. The CA stores the public keys and maintains the list of certificates that have been issued.

CA's vary greatly in size. At one end of the spectrum are commercial CAs such as Verisign and GTE Cybertrust, which issue millions of certificates, while at the opposite end are departmental CAs that issue a small number of certificates. Many smaller CAs are known to issue certificates signed by a higher-level CA, which can be inside or outside the organization.

CAs can decide what attributes will be included in the certificates it creates and what method of verification it will implement at the time of creation. Each CA also has the responsibility of validating the identity of a person or organization and associating that entity with the key pair it issued. Users place trust in the CA's ability to distinguish between authorized and unauthorized certificate requests, thus the CA stores and maintains a list of the certificates it has issued. Additionally, every CA has the responsibility of issuing a certificate revocation list (CRL) containing any certificate that has to be revoked. The CRL is published to locations that clients have access to so that they can check the list before any authentication request is approved.

CA Types

CAs provide validation of the entity belonging to the public key, so the administrator must understand the four types of CAs included with the Microsoft Certificate Service:

• Enterprise Root CA

• Enterprise Subordinate CA

• Standalone Root CA

• Standalone Subordinate CA

The Enterprise Root CA is at the top of the PKI. Active Directory is used to verify a certificate requester's identity. Because it is at the top of the PKI, the Enterprise Root CA signs its own CA certificate and then publishes that certificate to every other CA on the network. By signing its own CA certificate, the Enterprise Root CA establishes itself at the top of the CA trust chain. The down side to this arrangement is that since the chain of trust has to start somewhere- in this case, at the Enterprise Root CA-there now exists a weak link in the chain. This is why a third party Trusted Root is sometimes considered for use. Compromise of the Enterprise Root CA will most certainly result in catastrophic effects on the rest of the network if no higher level CA exists.

An Enterprise Root CA uses predefined certificate templates for issuing and requesting certificates. When using certificate templates, the Enterprise Root CA can verify user credentials during certificate enrollment. Each template has an access control list (ACL) that is evaluated at the time the user makes a certificate request to determine if the requester is authorized to receive the template. An example of a template is one created for a smart card logon.

The Enterprise Root CA can be used to issue certificates directly to users, but is generally used to authenticate Enterprise Subordinate CAs, thus authenticating them in the chain of trust. The Enterprise Root CA is integrated with Active Directory, which helps simplify issuing and revoking certificates.

Enterprise Subordinate CAs are available in two different types: intermediate or issuing. All CAs can issue certificates, but the implementation practice in larger organizations is to use issuing certificate subordinate CAs to issue certificates. The issuing CAs issue certificates directly to users that support client services such as smart card logons, the Encrypting File System (EFS), and Internet Protocol (IP) security. The intermediate CA's job is not to issue user certificates but to generate a certificate for issuing CA validation and to provide a link in the chain back to the Root CA. Using a multi-layered CA arrangement can provide redundancy and scalability of a CA implementation. Of course, a smaller organization may not have this type of arrangement and may even only have one CA-the Enterprise Root CA. This results in reduced redundancy, however, as with any time a critical service is placed entirely on one server.

The practical reasons for supporting a model containing multiple CAs include the following:

• Use  A certificate may be issued for defined purposes such as smart card logons; separation will provide a basis for administering different policies.

• Geographic  A large organization may have entities at multiple remote sites. The network connections between the multiple sites may require separate issuing CAs.

• Flexible Configuration  The most important CA is the root, so a company may decide to physically secure the computer by removing it from the network. (See the following Test Day Tip for an example of this.)

• Shutdown  Multiple CAs enable the administrator to turn off or remove one without having an impact on the CA hierarchy.

• Organizational Divisions  A large organization may have entities at multiple remote sites. The network connectivity between the multiple sites may require separate issuing CAs.

Test Day Tip 

There are some instances where you may have an Active Directory environment and still opt to use a Standalone CA on your network. One example would be a CA that issues code-signing certificates. These certificates must only come from one source (this sole Standalone CA) and users must not be able to request new certificates, which are issued manually by an administrator. This CA must be protected at all costs as it maintains the chain of trust for your code-signing certificates. Make it a Standalone Root CA and place it in a fireproof, waterproof vault when not in use.

Not all Windows 2000 environments use Active Directory, which generates the need for the other two types of CAs. When an environment does not have Active Directory services or is not a member in a Windows 2000 domain, the CAs are referred to as standalone CAs. The Standalone Root is at the very top of the certificate structure, but a Standalone Subordinate CA can be an intermediate or issuing CA, much as in the Enterprise environment.

Certificate Hierarchies

As discussed previously, the CA at the very top of a certificate hierarchy is referred to as a Root CA. No one within the boundaries of an organization is above the Root CA, so no one within an organization can vouch for its authenticity, and the Root CA typically signs its own certificate. Because the signing of its own identity is not really secure, a third party may sometimes be used to verify a Root CA's certificate; thus, verification of the entire certificate chain is possible outside of the organization's boundaries and up to a publicly available and trusted Root CA.

Any environment can and should have more than one Trusted Root CA. Figure 4.4 shows an environment that contains 106 Trusted Root CA certificates. The Windows 2000 Certificate snap-in not only displays these CA certificates but also includes the expiration date and the intended purpose for each listed CA. From this interface, a user can add or remove a Trusted Root CA. It stands to reason that not all users of digital certificates will use the same Trusted Root CA, thus any number of Trusted Root CA certificates ca be imported into a certificates store (a process which will be examined later in this chapter). By placing these certificates in a certificate store ahead of time (many of which come pre-installed with Windows itself), administrators can quickly verify an issued certificate that is presented to them.

Figure 4.4: Examining the Trusted Root CAs

Trust and Validation

When a receiver receives a signed message, the signature is validated through the use of the sender's public key and a mathematical process. The receiver must be sure that the public key truly belongs to the sender; if Bob is the sender, Alice needs proof that it is Bob's public key.

This is where the CA enters the validation process, providing proof that the correct public key was used. Examining the certificate that corresponds to the sender's public key in a CA they trust, allows the recipient to determine the following facts:

• Was the certificate issued by a trusted CA?

• Does the certificate assure a binding between the sender and the sender's public key?

• Does the certificate have a valid signature from its issuer?

The receiver uses the public key of the issuing CA to verify the certificate. The receiver needs to be sure that the public key of the CA used to verify the sender's public key is not an impersonator. This chain reaction of verifying the verifier continues up the CA hierarchical structure. In the final step, a certificate is issued to a CA that the receiver implicitly trusts. This certificate, which does not require authentication, is known as a Trusted Root certificate, because it is at the very top of the key hierarchy and identifies bindings accepted as truthful. When the CA hierarchy is created, the parent-child relationship is established. A user who trusts a particular root certificate implicitly trusts all the certificates issued by that root and its subordinate CAs.