Understanding Certificate Authorities

When implementing certificates for security purposes, organizations can opt to use a commercial certificate provider or it can use a tool called Certificate Services , which is included with Windows 2000. In either case, before implementing any certificate infrastructure, it is important to understand certificates and certificate authorities.

Certificates

A certificate is a digital statement from a trusted authority used for verification purposes. The certificate is used to validate the entity bound to a public key . In other words, the certificate confirms that the holder of the key is who he claims to be. The entity issued a certificate can be a person, computer, organization, or a device, such as a router.

Certificates are similar to driver's licenses. A driver's license is issued to an individual from a trusted authority, such as a government agency, and can be used as proof of identity. Because it is a piece of identification issued from a trusted authority, we believe that the person holding the license is indeed who they claim to be. This is the purpose of certificates. Because they are issued from a trusted authority, we trust that the person or entity is who they claim to be.

PKI and Public/Private Keys

A Public Key Infrastructure (PKI) is a system that employs the use of digital certificates, public and private keys, and certificate authorities to secure communications. The digital certificates provide a way of verifying an individual's identity. The public and private keys are used to secure data that is exchanged. The certificate authorities are responsible for generating the key pair and issuing the digital certificates.

Public and private keys ensure data being sent between parties is secure. They also ensure that the entity sending the data is who they claim to be. Once a key pair is generated, the private key is given to the individual who made the request. The public key is made available to others as part of the digital certificate. When a message is encrypted using a public key, only the individual holding the corresponding public key can decrypt it. For example, if Sean wants to send Doug a secure message, he can locate Doug's public key and use it to encrypt the message (remember the public keys are made available to other parties, not the private keys). Once the message is encrypted, only Doug can decrypt it using his private key. Likewise, if Sean wanted to authenticate himself to Doug, he could encrypt a digital certificate using his own private key. Doug can then use Sean's public key to decrypt it.

For an entity to be part of a PKI , it must have a public and private key as well as a certificate. Before a certificate can be issued, a key pair must be generated. The key pair is usually generated by the Cryptographic Service Provider (CSP). The CSP provides the encryption and signature algorithms and determines the algorithms and key lengths used with a certificate. Once the key pair is generated, a request can be submitted to a Certificate Authority (CA). Depending on how CAs are implemented, this request may be sent to a third-party certificate service or to a CA on the internal network (CAs are discussed in the following section). The request for a certificate includes the public key of the requestor as well as any other required information, such as name and email address. If the certificate is issued it will include the following information:

• The entity's name

• Information about the entity, such as email address

• The entity's public key

• An expiration date for the certificate

• Details about the certificate authority that issued the certificate

• Digital signature

Some of the reasons for implementing certificates include:

• Implementing the Encrypting File System (EFS)

• Using IPSec to secure communications

• Signing and encrypting email messages

• Smart Card Logons

• SSL and TLS communications

Certificate Authorities

A Certificate Authority (CA) is an entity that has been assigned to issue certificates to users, computers, and organizations. There are two options when using CAs. You can use a third-party CA, such as VeriSign (www.verisign.com), or you can create your own CA using Certificate Services.

Certificate requests are submitted to a CA to verify the requestor. In other words, the CA verifies that the person requesting a digital certificate is indeed who they claim to be. This verification is an important step in the information security process. By having a trusted third party, such as VeriSign, identify and legitimize the requestor, entities wanting to transfer data to the requestor can rest assured that they are dealing with a trustworthy and secure party.

Not only is the CA responsible for issuing digital certificates, it is also responsible for revoking them. The CAs publish a list of all revoked certificates to identify which entities no longer have the trusted credentials given by the CA (revoking certificates is discussed later in this chapter).

Because a CA is responsible for sensitive information, it's important that security measures are in place to protect it. First of all, the CA should be physically protected, meaning it should be placed in a secure location accessible only by administrators. Because the CA's private key is the basis for trust in the certification process, this too must be secured.

The CA's private key is used to sign all issued certificates. For example, if Mike receives a digitally signed message from Dana, he can verify her identity by using the CA's public key to decrypt the signature (that was signed using a private key). If the CAs signature is valid, and the information contained within the certificate is valid, Mike can be assured that the message is in fact from Dana.

The cryptographic hardware module can provide tamper-resistant key storage and protect the CA's private key. Finally, you must also consider the possibility of losing a CA. This can obviously cause a number of problems. Certificate Services supports backing up the certificate instance so it can be restored in the event of failure.

Certificate Authority Hierarchies

CAs are organized into hierarchies, similar to the way in which Windows 2000 domains are organized. The top level of the hierarchy consists of a root CA, or root authority, which is responsible for issuing certificates to other CAs. All other CAs then branch off the root, thus creating a parent-child relationship. These CAs are also referred to as subordinate, or child, CAs. Child CAs are certified by their parent CA. A CA hierarchy essentially creates a model of trust. Each child CA trusts its parent CA with the trust path leading back to the root authority.

There are a number of benefits to creating a hierarchy of certificate authorities. Multiple CAs enable you to designate specific CAs to be responsible for issuing specific types of certificates. Depending on the structure of the organization, it can allow each department or geographical location the ability to maintain its own CA. It also offers another level of security because users and computers are not in contact with the root CA to get their certificates. Instead they are issued a certificate by one of the subordinate CAs. Additionally, it gives administrators the ability of taking the root CA offline.

Certificate Authority Classes

Windows 2000 supports two classes of Certificate Authorities: Enterprise CAs and Standalone CAs . The type of CA you implement depends on to whom you are issuing certificates. For example, a standalone CA would be implemented to issue certificates to entities such as partners or clients outside of your organization. An Enterprise CA would be implemented to issue certificates to entities within the organization. The differences between the two types are outlined in the following sections.

Enterprise Certificate Authorities

An Enterprise CA provides certificates to users and computers within an organization. An Enterprise CA is automatically registered in Active Directory and trusted by all computers in that AD domain.

Enterprise CAs have the following features:

• They require a domain controller with Active Directory.

• Information is stored within Active Directory.

• They are used to issue certificates to entities within an organization.

If you encounter an exam question in which domain user accounts are used to verify the identity of a requester, you will be implementing an Enterprise CA.

Standalone Certificate Authorities

In an environment without Active Directory, you can implement Certificate Services using a Standalone CA. Standalone CAs are also implemented if certificates are being issued to entities outside the organization, for example, to business partners or vendors . Standalone CAs have the following characteristics:

• Active Directory is not required.

• Information is stored within a local database.

• This type of CA is normally configured when certificates must be issued to extranet or Internet users.

• Requestors must provide all information needed to complete their certificate. This is unlike an Enterprise CA, which can retrieve the required information from Active Directory.

• All certificate requests are set to pending until the identity of the requestor is verified .

If Active Directory is installed, you have the option of using Enterprise or Standalone CAs. If Active Directory is not present, only Standalone CAs can be implemented.

Certificate Authority Types

Now that you are familiar with the two general classes of CAs, let's take a look at the different CAs that can exist within a certificate hierarchy. The four types of CAs supported by Windows 2000 are as follows :

• Enterprise Root CAs

• Subordinate CAs

• Standalone Root CAs

• Standalone Subordinate CAs

The following sections help you become more familiar with each of these CA types.

Enterprise Root CAs

At the top level of an enterprise certificate authority hierarchy is the Enterprise Root CA. Once the CA is configured, it is automatically registered within Active Directory and trusted by all computers within the domain.

In a CA hierarchy, the Enterprise Root CA is usually responsible for issuing certificates to subordinate CAs, which then issue the certificates to users and computers on the network. The Enterprise Root CA can also issue certificates directly to users and computers if required.

Enterprise CAs have the following requirements:

• Active Directory

• DNS

• The user configuring the Enterprise CA must be a member of the Enterprise Admins group

Remember that a single domain can have multiple Enterprise Root CAs. However, any given CA hierarchy can consist only of a single Enterprise Root CA.

Enterprise Subordinate CAs

In a certificate hierarchy, an Enterprise Subordinate CA exists under an Enterprise CA. Enterprise Subordinate CAs are usually created for a specific purpose, such as issuing certificates to a particular part of an organization. To configure an Enterprise Subordinate CA, an Enterprise Root CA must be present. This can be an Enterprise Root CA on the local network or a third-party root CA.

If you want to have your certificates trusted by people outside the local organization, you can configure the root CA to be from a third-party, such as VeriSign, instead of using a root CA on the internal network.

If a child domain is added to an existing domain tree that already has a CA in place, the default permissions in the new domain will not allow the CA to publish certificates. To solve this problem, the CA must be added to the Cert Publishers group in the new domain.

Standalone Root CAs

If Active Directory is not installed, a Standalone CA is the only type of CA that can be configured. It requires only administrative privileges on the local computer. If your organization needs to issue certificates to entities outside of the organization, a Standalone CA should be implemented All certificate requests are then held as pending until an administrator approves them.

Standalone Subordinate CAs

A Standalone Subordinate CA is very similar to an Enterprise Standalone CA, except it does not require Active Directory. To successfully install a Standalone Subordinate CA, there must already be a root CA in place. Again, this can be a root CA within the organization or from a third party. Also, keep in mind the administrative privileges requirement on the local server.