Designing a Certificate Authority Implementation

---

A certificate authority (CA) needs to perform the following roles:

• Maintain a root certificate to distribute its public key.

• Identify the certificate requestor and validate their identity. This can vary from simply verifying that the domain is correct to doing a background check and having someone physically verify the identity of the requestor.

• Issue certificates to requestors.

• Maintain a database of registered users (certificates issued).

• Generate and maintain a certificate revocation list (CRL).

When designing a CA implementation, you need to consider what types of applications you will use to require certificates. You will then need to determine what clients will need certificates. You will also need to define the certificate security requirements. Finally, you will need to decide on the appropriate certificate server roles and hierarchy.

Determining Certificate Requirements

Applications that use PKI will require a number of types of certificates to be installed. You will need to decide which applications will require certificates and what types of certificates those applications will require. Table 6.2 list technologies that rely on certificates and the ways applications might use certificates.

Table 6.2: Common Technologies That Rely on Certificates

Technology	Applications
Client authentication	Validating computers or clients on the network
Digital signatures	Signing a document to verify that it came from the appropriate user
Encrypting File System (EFS)	Securing files on the file system of a computer
IP Security (IPSec)	Securing remote access to network over a public network through encryption and authentication of machines
Secure email (S/MIME)	Encrypting and signing e-mail messages
Secure Sockets Layer (SSL)	Encrypting traffic to and from a website; verifying the identity of the web site
Server authentication	Verifying the identity of the server
Smart card logon	Providing for two-factor authentication with smart card technology
Software code signing	Verifying that the source of the code and the code has not been altered since it was released
802.1x	Authenticating clients and encrypting traffic
Extensible Authentication Protocol– Transport Layer Security (EAP-TLS)	Providing encryption and identity verification

After you have determined what applications you need to secure, you will need to decide to implement a private CA or utilize a commercial CA. There are different reasons you might choose one or the other. You would set up a private CA if you have the need to control and administer your own certificates. You would also do so if you needed to deploy many certificates because doing so with a commercial CA would be costly. Implementing your own root CA and additional hierarchy means you can cross-certify with a partner organization, which allows you to create a limited trust of certificates from a partner organization that they manage separately.

Note

Cross-certification will be discussed later in this chapter, in the section “Trusting Certificates from Other Organizations.”

The disadvantage to implementing a private CA is that it will likely require additional staff and servers to install and manage. You would have to also consider the methods for deploying the certificates. You could then use Group Policy and Active Directory to deploy the certificates to clients on your network, but deploying them outside of your network is more difficult.

A commercial authority is widely trusted, so clients will not have to complicate things by having to install a certificate. You would use a commercial CA if you need to have a certificate trusted outside your organization. For example, suppose your company has built an application that will be used over the Web. Part of the application will require that private or sensitive information be sent over the Internet. You would obtain a certificate from a commercial CA to implement SSL on your website because the commercial CA’s certificate will be contained in the client’s browser. The drawback is that you cannot administer your own certificates. You also cannot cross-certify with a partner organization because you do not have control over the root server.

In the “Choosing Where to Host Certificates” Design Scenario, you will determine where to host certificates for a company.

Design Scenario: Choosing Where to Host Certificates

Trinity Importers, Ltd. is a retailer that specializes in importing Asian goods into the United States and selling them through retailers throughout the East Coast. The company has decided to expand to the Internet to expand its market. It has hired a web development company to develop and host the e-commerce site.

Network Administrator We are overworked supporting the servers and the POS systems already in place in the organization. We are not increasing the staff for supporting the e-commerce site because the company has outsourced the hosting of the site. We do not want any additional administrative duties for the application.

CIO We are testing out the popularity of an Internet presence for our company. We want the customers to have an easy time using the site. We do not want to support any kind of complex installs.

CSO The clients of the website will be sending private information to the website, like credit card information and additional information that we collect. We want customers to feel confident that their information will not be compromised.

1. Question: Trinity needs to implement SSL to secure data transmit ted over the Internet. Of the following, what kind of PKI should you recommend to Trinity Importers? Answer: You should choose a commercial CA for issuing the certificate because of the requirement of not wanting a solution that is a burden for the network administrators and because the CIO doesn’t want to have to worry about distributing the private root CA certificate.

2. Question: Why would you need a certificate for Trinity Importers? Answer: You need a certificate to implement Secure Sockets Layer in the application. The certificate will prove to the client that the server comes from Trinity’s domain if the client trusts the issuing root CA. It also contains the public key of the web server so the client can send an encrypted message to the server to initialize the SSL session key.

Designing the Roles of Certificate Authorities

When you establish a PKI in your own organization, you will need to choose the roles of the CA servers that you install. You have a choice of three different server roles:

Root CA role The first CA you install in your organization is the root CA. The root CA server is the ultimate CA in the organization. It is responsible for signing all other subordinate CA certificates. The root CA is the only server role that trusts itself by signing its own certificate and issuing this root certificate to itself. The role of the root CA is to authorize other CAs in the organization. Therefore, if your clients trust the root CA, then they trust the certificates issued by the root’s subordinate CAs. When an application receives a certificate, it will verify that the certificate is issued by a trusted root CA; otherwise, it will warn the user that there is a problem with the certificate. You can issue root certificates to the Windows client trusted root certificate store by using Active Directory or Domain Group Policy or through a website or file share where users can download the trusted root certificate. The root CA is very important and it would be detrimental to network security if it was infiltrated, so it is recommended that it be kept offline.

Intermediate CA role Generally, it is recommended that the root CA be kept offline, so it is not available to approve and issue certificates. The root CA can certify the subordinate CAs to accept, approve, and issue certificates on its behalf. The intermediate CA can be used to certify requests for certificates. This will reduce the number of times that the root CA’s private key is exposed. The intermediate CA (also known as a policy CA) is the CA that approves client requests for certificates known as enrollment requests.

Issuing CA role After the intermediate CA, you would install an issuing CA to enroll, deploy, and renew the certificates. The issuing CA is the CA that will communicate with the client applications and computers. The issuing CA is the server that needs to be available all of the time for proper CA functionality.

You will want to design for multiple CAs in your organization to provide availability and secure publishing points in your organization. You should not go more than three levels deep with your CA design and two levels will be adequate for most organizations.

You also have the choice of installing an enterprise CA or a stand-alone CA on a Windows Server 2003 server. An enterprise CA will take advantage of Active Directory to control the enrollment process. This means that you can use Group Policy to manage and distribute client certificates. You can also use the certificate templates to create a certificate. A stand-alone CA does not take advantage of Active Directory. You will not be able to use Group Policy to manage certificates and will be limited to a web-based or command-line utility enrollment.

You build a chain of trust or a certificate path when issuing certificates. The certificate that a user or a computer receives can be trusted because the issuing CA received its certificate from another CA or directly from the root CA. Because the root CA issues the certificates used by subordinate CAs, and eventually the client’s certificates, as long as you trust the root CA and it is kept secure, you can verify the identity of the certificate. If the root CA is compromised, then all certificates issued by the root CA or any subordinate can be considered invalid because they can be forged by someone. You should keep the root CA secure.

You can install the different CA roles into one of three basic hierarchies. A single server would have the root CA approving and issuing certificates. This is the least secure of the three hierarchies because it exposes the root CA to attackers, which can be dangerous if the private key used to sign certificates is compromised. You can help mitigate this risk by installing a two-tier hierarchy.

A two-tier hierarchy allows you to keep the root CA offline except when you install new CAs. The root would have one or more subordinates, but it would have no more than two levels, as shown in Figure 6.10.

Figure 6.10: A two-tier hierarchy

The subordinate would be the intermediate and issuing CA, which can be kept online to handle the day-to-day certificate maintenance requirements without exposing the root CA’s private key. This is usually the best cost-versus-security combination.

A three-tier hierarchy can further secure your CA by separating the intermediate CA from the issuing CA, as shown in Figure 6.11.

Figure 6.11: A three-tier hierarchy

The three-tier hierarchy allows you to add an additional layer of CAs between the client and the root CA. This will allow you to create separate issuing CAs for different groups of clients. For example, internal clients can obtain their certificates from a different CA than the one external clients obtain theirs from.

Most organizations will not require a three-tier hierarchy for security of their applications. You will need to weigh the cost of server licenses and managing the extra servers against the importance of security requirements for your CAs. The root and intermediate CAs are centralized, so when we talk about designing a CA hierarchy, we are generally referring to issuing CAs.

Determining Appropriate CA Hierarchies

You will need to determine where and how you will want to group your issuing CAs. You have four design choices when determining how to lay them out:

Organizational CA hierarchy You can design a CA hierarchy based on the classifications of employees in your organization. You would use an organizational CA hierarchy if you need to use different policies for issuing certificates to employees, contractors, administrators, partners, and various other classifications of users. Users would obtain certificates from the proper issuing CA for their classification. For example, you could decide that a contractor must provide two forms of government ID, while an employee might only need to log on to the network with their user ID and password.

Department CA hierarchy If your organization’s administration is decentralized, then you can let each department control their own issuing CAs. Using the department CA hierarchy, you could let the marketing department or the accounting department decide what certificates they want to deploy. They can control the issuing of certificates for their PKI-based applications or they can meet the unique legal requirements of their departments. You could have both a policy CA and an issuing CA in the department if the department requires different policies for issuing certificates.

Function CA hierarchy You can design a CA hierarchy based on the type of certificates that you wish to issue. With the function CA hierarchy, you would have a separate issuing CA for each certificate type or application that requires PKI. You would use this design if you need to separate the management of different certificate types. For example, the group that manages the Exchange servers for e-mail may require control over the certificates that are issues for S/MIME digital signatures and encryption. You would then create an issuing CA for S/MIME certificates and allow the Exchange group to manage the certificates that it issues. You may have legal requirements for different certificate types. This may involve the length of issuance or the issuing policies for particular certificate types or applications.

Geographic CA hierarchy You can decide that it is necessary to base the distribution, enrollment, and management of certificates on geographic locations of your organization. With the geographic CA hierarchy, you would install issuing CAs at each geographic location in your company. Factors that would influence this decision would be legal requirements, such as a requirement that all PKI activity must be maintained within country boundaries, or availability requirements, such as needing a local CA server if the WAN links are potentially down.

When designing for the different CA hierarchies, you will find that legal requirements will determine the type of hierarchy you choose. Certain industries will have requirements about how long documents must be kept, therefore encryption keys cannot be changed or recycled during that period. Countries will have different legal requirements for encryption and you would need to make sure issued certificates do not violate these laws. You would need to create three documents to help determine the appropriate hierarchy for your organization: the security policy, the certificate policy, and the certification practice statement.

The security policy for the organization The security policy is a document that defines the security practices that are used in the organization, as we discussed in Chapter 1, “Analyzing Security Policies, Procedures, and Requirements.” The security policy would define the security concerns of the organization, what they need to protect, and what resources the organization wants to dedicate to security. The security policy should include information about the PKI in use in the organization. You would use this information to document procedures and practices with regard to CAs, their certificates, the level of trust that each certificate should have, and the legal liabilities if the different certificates are compromised.

The certificate policy The certificate policy defines how a certificate subject (user or computer) is verified before it is assigned a certificate, where the private keys will be stored (separate hardware device or a computer hard drive), the process for responding to lost keys, the enrollment and renewal process, the maximum monetary or intrinsic value that can be protected by this certificate, the types of actions that can be performed with the certificate, and any additional requirements surrounding a certificate that is issued in your organization.

The certification practice statement (CPS) The CPS is a document that specifically defines how to implement the certificate policy on the organization’s CA hierarchy. You would define the users, computers, and applications that will require certificates. You also can include authentication and identification methods for enrollment and renewal, the obligations and liabilities of the organization with regard to the CA hierarchy, the audit policy for ensuring that the CPS is followed, operational requirements for the CAs in the organization, the types and versions of certificates that will be issued, and the procedures for securing CAs in the organization. The CPS essentially defines the management of the CAs that are in the organization, while the certificate policy defines the procedures for managing certificates. The CPS can then be published to the policy CAs through the use of a CAPolicy.inf file. The CPS will then be published to all subordinate CAs.

In the “Choosing a CA Hierarchy” Design Scenario, you will decide what would be the appropriate CA hierarchy for an organization.

Design Scenario: Choosing a CA Hierarchy

Trinity Imports, Ltd. has offices in Asia, Europe, and New York. The company uses a multiple-domain model with one domain for each of the locations. Each location has its own administrative staff. These locations also have different legal requirements when it comes to strength of encryption that may be used. Trinity needs to implement a CA hierarchy. The folks at Trinity have decided that their design will have the root CA and policy CA for the organization in New York. They now want to design the rest of the hierarchy.

1. Question: What hierarchy would you recommend for Trinity and why? Answer: Trinity should build a hierarchy based on the geographic location of each of its sites because the organization requires different legal requirements for regions or countries.

---