Understanding Certificate Authorities

An Overview on Certificate Authorities

In the Public Key Infrastructure (PKI), digital certificates are based on public key cryptography. The PKI consists of a set of components, policies, protocols, and technologies that provide data authentication, integrity, and confidentiality through the use of certificates, and public and private keys. Data is protected by applying a hashing algorithm and signature algorithm to the original message. A hashing algorithm is an intricate mathematical algorithm which is applied to the message. The hashing algorithms which are commonly used are MD2, MD4, MD5, and SHA-1. The Microsoft strong cryptographic provider algorithm is the default signature algorithm used in Windows Server 2003. This algorithm is applied to what is called the message digest. With public key cryptography, the key that encrypts data is called a public key. The key that is used to decrypt data is called the private key. While the public key can be publicly distributed, the private key is kept secure.

The capability does exist for an organization to download software and tools that generates digital certificates and private and public key pairs, but how do you know that the source of this software and tools is safe. In the same manner, it is possible for a local PKI to create its own public and private keys, and send it to other parties. Once gain, how do these parties verify the source of the certificate when nothing authenticates it.

The utilization of Certificate Authorities (CAs) overcomes these security issues. A Certificate Authority can be defined as an entity that generates and validates digital certificates. The CA adds its own signature to the public key of the client. This essentially indicates that the public key can be considered valid, by those parties that trust the CA. Third party entities that provide and issue digital certificates are VeriSign, Entrust and GlobalSign. Because these entities issue digital certificates for a fee, it can become a costly expense in a large organization. By using the tools provided by Microsoft, you can create an internal CA structure within your organization. You can use Windows Server 2003 Certificate Services to create certificates for users and computers in an Active Directory domain.

Before discussing CAs any further, lets first look the role which CAs play in the Public Key Infrastructure (PKI).

1. A request for a certificate is sent to the CA.

2. The CA authenticates the user, and then issues a digital certificate to the requestor.

3. The CA publishes the certificate in a public certificate store, so that the receiver of messages can authenticate the CA.

4. When the key is used to sign messages, a hashing algorithm is applied to the message. The end result is the message digest.

5. Next, the signing algorithm (with the private key) is applied on the message digest.

6. The encrypted message is then sent.

7. The receiver of the message validates the certificate details using the public certificate repository.

8. The receiver then decrypts the message.

In Step 1 of the above process, the user or computer made itself known to the CA. This process is called registration, and can be performed manually or automatically. The user or computer that sent the request to the CA provides information to the CA, which the CA utilizes to authenticate the entity.

The initial step in implementing a PKI, is to install a CA. The first CA installed, becomes the root CA. The root CA forms the foundation of the PKI because it issues the private and public key pairs used to secure data as it is transmitted over the network.

The Differences between Internal CAs and External CAs

While a small organization could possibly need only one CA, a large organization would need multiple CAs, which could include a combination of internal and external CAs. When both internal and external CAs are used in an organization, Windows Server 2003 Certificate Services could be used to provide internal CA capabilities to the organization, while a third party such as VeriSign could be used as the external CA. The use of an external CA becomes important if the organization needs to exchange digital certificates with other organizations.

The security needs of the organization would dictate whether internal CAs, external CAs, or both of the two are used. Organizations typically use internal CAs to secure data that is communicated over the internal network, and external CAs to secure data communicated to external entities.

The advantages of using internal CAs are briefly listed below:

• Simplified and ease of management is probably the main advantage associated with using internal CAs. You do not need to depend on an external entity to perform administrative tasks.

• An internal CA structure can be integrated in Active Directory. This further simplifies the management of the CA structure.

• There is no cost per certificate fees associated with internal CAs.

• It is cheaper to configure, and expand the PKI.

• The auto-enrollment feature of Windows Server 2003 can be utilized for users.

The disadvantages of using internal CAs are briefly listed below:

• Implementing internal CAs is more complicated than using external CAs.

• When organizations use internal CAs, they have to take accountability for any PKI failures.

• External parties such as business partners, or customers of the organization; would typically not trust a digital certificate signed by an internal CA.

• The certificate management overhead of internal CAs is higher than that of external CAs.

The advantages of using external CAs are briefly listed below:

• The external CA is accountable for any PKI failures.

• External organizations would generally trust a digital certificate signed by a trusted external CA, such as VeriSign.

• The certificate management overhead of external CAs is lower than that of internal CAs.

The disadvantages of using external CAs are briefly listed below:

• The level of integration possible between an external CA and the infrastructure of the organization is limited.

• The cost per certificate fees associated with external CAs could become exorbitant in a large organization.

• Less flexibility exists when it comes to configuring, expanding and managing certificates.

If you have chosen to utilize internal CAs within your organization, you have to determine how many CAs are going to be needed, to meet the security requirements of your organization. After you have decided on the number of CAs that should be installed, you need to determine where the CAs are to be located. Having two or more CAs provides benefits such as fault tolerance. With multiple CAs, when one CA server fails, clients can continue to request certificates. If your organization has many branches, you can configure a CA for each branch. This decreases wide area network (WAN) traffic.

Factors such as the CPU performance of the server and disk performance affect the performance of a CA, and can affect the number of CAs which you need. Bear in mind too that the length of the encryption keys in certificates also affect the performance of a CA server. Longer keys typically need more processing time.

The Differences between a Root CA and Subordinate CA

The first CA that is installed becomes the root CA. The root CA forms the foundation of the PKI. The common practice is to first install the root CA, and then use the root CA to validate all the other CAs within the organization. A root CA is the most trusted CA in a CA hierarchy. When a root CA issues certificates to other CAs, these CAs become subordinate CAs of the root CA. When a root CA remains online, it is used to issue certificates to subordinate CAs. The root CA never usually directly issues certificates to users, computers, aplications or services.

A subordinate CA can also issue certificates to other subordinate CAs. These subordinate CAs are called intermediate CAs. While an intermediate CA is subordinate to the root CA, it is considered superior to those subordinate CAs to which it issued certificates. Subordinate CAs which only issue certificates to users, and not to other subordinate CAs, are called leaf CAs.

The Differences between Enterprise CAs and Stand-alone CAs

Both enterprise CAs and stand-alone CAs can be used to issue certificates for the following:

• Digital certificates

• Email, S/MIME

• Web servers, SSL

They are however differentiated from one another, based on their location:

• Enterprise CAs: An enterprise CA stores its certificate information in Active Directory. Enterprise CAs are essentially dependent on Active Directory to store and replicate certificate data. What this means is that the enterprise CAs have to be configured as domain controllers. This in turn means that enterprise CAs can only issue certificates to users and computers that belong to the forest.

• Stand-alone CAs: A stand-alone CA stores its certificate data in a shared folder which can be accessed through a Web URL. When users want to request certificates from stand-alone CAs, they have to use Web enrollment.

Certificate templates can only be used with enterprise CAs. Certificate templates are used to define the format and content of the certificate, based on intended use of the certificate. Through certificate templates, you can specify the users and groups which are permitted to request the particular certificate.

In summary, the types of CAs which you can install are listed below:

• Enterprise root CA: This is the topmost CA in the CA hierarchy, and is the first CA installed in the enterprise. Enterprise root CAs are reliant on Active Directory. Enterprise root CAs issue certificates to subordinate
  CAs

• Enterprise Subordinate CA: This CA also needs Active Directory, and is used to issue certificates to users and computers.

• Stand-alone Root CA: A stand-alone root CA is also the topmost CA in the certificate chain. A stand-alone root CA is not however dependent on Active Directory, and can be removed from the network. This makes a stand-alone root CAs the solution for implementing a secure offline root CA.

• Stand-alone Subordinate CA: This type of CA is also not dependent on Active Directory, and is used to issue certificates to users, computers, and other CAs.

CA Hierarchies

In a single CA model, there is only one CA in the PKI of the organization. All users or parties are handed the public key of this CA when they request certificates.

In a CA hierarchy, when the root CA is installed, you can use this CA to issue CA certificates to other certificate servers. These subordinates CAs can in turn issue certificates to other subordinate CAs. This process of installing CAs and issuing certificates between CA servers starts the formation of a CA hierarchy. Another terminology used to refer to the CA hierarchy is chain of trust. When multiple CAs exists in an organization, the relationship that they have with one another are based on the parent/child relationship between the CAs. It is important to note that a root CA has a self-signed certificate. What this means is that the certificate of the root CA is not signed by another higher authority, but by itself. The actual root CA issues and signs the certificate.

The CAs beneath the root CA in the certificate chain is called intermediate CAs. These types of subordinate CAs are used to issue certificates to other subordinate CAs. CAs located beneath the intermediate CAs are subordinate to the intermediate CAs. The name used to describe CAs which are located beneath intermediate CAs is leaf CAs. Leaf CAs issue certificates to users, computers, applications, and services.

h2>New Features provided by Windows Server 2003 CAs

The features which Windows Server 2003 CAs provides when you are running Windows Server 2003 Enterprise Edition or Windows Server 2003 Datacenter Edition are outlined below. These are enhancements to Windows 2000 CA capabilities, and are also only available when Version 2 certificate templates are used to issue certificates.

• Key archival and recovery: This feature allows you to archive the keys, and re-issue them when users happen to lose their keys.

• User auto-enrollment: You can configure users to auto-enroll for a User certificate.

• Delta CRLs: With delta CRLs, clients are only sent the updates that should be added to their base CRLs when changes are made.

• Qualified subordination: Through this feature, you can control the types of certificates which subordinate CAs can issue.

CAs and Certificate Revocation Lists (CRLs)

Another function associated with CAs in the PKI, is the issuing of Certificate Revocation Lists (CRLs). A CRL is a list that contains the serial numbers of all certificates which have been revoked. The CA is responsible for
maintaining the CRL. When the CA validates certificates, it checks the CRL to determine whether it is still valid or not. If the certificate is on the CRL, the CA announces the certificate as being revoked.

The CA places the CRL at locations, called CRL Distribution Points (CDPs), from which clients can download the CRL. When clients cannot locate a CRL at a CDP, it works on the assumption that all certificates issued by the CA have since been revoked. Enterprise CAs publishes its CRL in Active Directory. The actual object used is the CRLDistributionPoint object. Stand-alone CAs store their CRLs in the systemroot%system32certsrvCertEnroll folder. You can use the Certification Authority management console to view the list of certificates included in a CRL. Simply, right-click Revoked Certificates, select Properties from the shortcut menu, and then click View CRLs. You can also use the Certification Authority management console to manually publish a CRL. CRLs are normally manually published when an important certificate has been compromised.

When you specify a long validity period for a CA, the CRL can grow quite large. You can use delta CRLs if your servers are running Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition to minimize the update time needed to publish revoked certificates. When delta CRLs are used, clients are first sent the base CRL. After this, the client is only periodically sent updates.

The Certification Authority management console

The Certification Authority console is the MMC snap-in used to administer and manage CAs. You can perform the following key administrative tasks through the Certification Authority console:

• Start and stop CAs

• Back up and restore CAs

• Revoke certificates

• View, install and reinstall the CA certificate for the CA

• View the contents of the CRL

• Publish CRLs

• View and change the CRL distribution points

• View, approve, or deny pending certificates

How to install a CA

1. Click Start, Control Panel, and click Add Or Remove Programs.

2. Select Add/Remove Windows Components in the Add Or Remove Programs dialog box.

3. The Windows Components Wizard launches.

4. Select the Certificate Services checkbox.

5. Click Yes to the message warning that the name of the CA cannot be changed.

6. On the CA Types page, select Enterprise Root CA or Stand-alone Root CA. Click Next.

7. On the CA Identifying Information page, enter a name for the CA in the Common Name For This CA box. Click Next.

8. You can accept or change the default settings in the Certificate Database Settings page. Click Next.

9. The certificate service is installed and the CA database started. IIS is restarted after this.

10. Click OK if a message dialog box appears, warning that ASP must be enabled for Web enrollment.

11. Click Finish.

How to view the CRL

1. Click Start, Administrative Tools, and then click Certificate Authority.

2. Right-click Revoked Certificates and select Properties from the shortcut menu.

3. When the Revoked Certificates Properties dialog box opens, click View Current CRL.

4. In the Certificate Revocation List dialog box, click the Revocation List tab.