The primary part of your PKI deployment is the design of your Certification Authorities (CAs). The deployment of your PKI must include the following steps:
After this lesson, you will be able to
Estimated lesson time: 60 minutes
A PKI is comprised of several services and components working together. A PKI's primary components include
NOTE
In addition to graphical tools, the Microsoft Windows 2000 Server Resource Kit includes text-based certificate tools, including Certutil and Dsstore. Certutil provides the same functionality as the Certification Authority console. Dsstore is used to manage CA certificates in Active Directory.
One of the first decisions you need to make when you deploy a public key–enabled application is where to obtain the necessary certificates. In general, you must decide between a public CA (also known as a third-party CA) and a private CA.
Public CAs are managed by third-party companies such as Entrust or Verisign. You should obtain certificates from public CAs when the application requiring the certificates runs on a public network and when the use of a third-party certificate increases customer trust in the application. For example, most e-commerce sites obtain the certificate for their secured Web site from a public CA. Consumers may not trust a small or unknown organization when that same organization issues the certificate for the Web site.
Public CAs include an issuer statement that describes rules of conduct for the certificate. The issuer statement (or CPS) defines acceptable usage, conduct that results in the certificate's revocation, and the issuing company's liability. Public CA service isn't free. Any certificates acquired from a public CA have a price determined by the certificate's use.
Public CAs are also used for interorganization projects. Each organization can trust certificates from the other if they're acquired from a common root authority such as Verisign or Entrust. If you use a public CA, the CA hierarchy is simplified because certificates are acquired from a common CA structure.
For many internal applications a private CA may be beneficial. Windows 2000 provides all the tools needed to create and maintain a private CA within Certificate Services.
You should obtain certificates from private CAs when you need greater ability to manage and control certificates issued to clients. Rather than waiting for a third-party organization to revoke certificates, you're immediately able to implement the revocation process when you need to.
Consider whether participants will trust certificates issued by your CA and how you will make key certificate services publicly available. These resources include the CA's certificate and the Certificate Revocation List associated with the CA.
Should I Mix and Match Public and Private CAs?
Sometimes it's best to mix private and public CAs. For example, if you're hosting a Web-based application on your extranet that will be protected using Secure Hypertext Transfer Protocol (HTTP-S) and you also wish to implement certificate-based authentication, the best solution is a mix of public and private CAs.
For the Web server, you want to acquire a Web server certificate from a trusted public CA. This certificate allows encryption of all data transferred between the client and the Web server hosting the application. The public CA certificate inspires consumer confidence in your Web server because your Web-based application must follow the issuance policy of the public CA that issued the certificate.
For certificate-based authentication of users, it may be desirable to create a private CA to manage user certificates. The primary advantage of using a private CA is that your organization has much more control over the management of issued certificates. It can revoke a compromised certificate quickly if necessary.
Use the decision matrix shown in Table 10.1 to determine whether to implement a public or a private CA for your application.
Table 10.1 Choosing Between Public CAs and Private CAs
Use a | When |
---|---|
Public CA | Your application requires verification from a trusted third party, such as selling products on the Internet. You don't have, and don't want to allocate, the resources to deploy an internal PKI. Time is limited. Public CAs already have the necessary infrastructure in place. A project requires certificate interoperability between organizations. Use of a public CA provides all issued certificates with a common root CA. Your application requires liability protection in case security is breached for your certificate-based application. |
Private CA | Your organization wants to maintain management control of all client-associated certificates. The certificates will be used only for internal projects, applications, and services. You want to minimize the costs associated with issuing certificates. Your organization has PKI expertise that can manage and maintain Certificate Services. |
Blue Yonder Airlines requires a mix of public and private CAs for its PKI deployment. The Web server that hosts the online booking Web site must have a public CA–issued certificate to ensure customer confidence in the security of sensitive data such as credit card information. As an added security feature, you also should configure the Web server to require 128-bit encryption to provide the strongest form of encryption available.
A private CA makes it possible to issue smart cards to customers while maintaining the ability to revoke certificates quickly (within four hours, for example, as described in the scenario). Likewise, a private CA provides internal employees with smart card logon and EAP authentication for remote access. Consequently, Blue Yonder Airlines requires a mix of private and public CAs.
Most PKI deployments require multiple CAs in the organization. The CAs are organized into either a rooted hierarchy or a cross-certification hierarchy, depending on business needs.
Rooted hierarchies are the most common CA structures. A rooted hierarchy has an initial CA, known as a root CA. The root CA is unique in that it issues itself a certificate. This certificate is also known as a self-signed certificate.
Below the root CA are one or more subordinate CAs. The root CA issues certificates to the subordinate CAs with the subject matching the name of the subordinate CA, as illustrated in Figure 10.3.
Figure 10.3 A rooted CA hierarchy
Additional levels of CAs might exist below a subordinate CA. These CAs are often referred to as issuing CAs. Rooted CA hierarchies enable the highest form of security because you can remove the root CA from the network, thus protecting it from attack.
WARNING
There are far-reaching implications if a CA is compromised and the CA's certificate must be revoked. Not only is the CA's certificate revoked, but all certificates issued by the CA—including those issued by subordinate CAs that received their certificates from the compromised CA—are considered compromised and are invalidated. By removing the root CA from your network, you can ensure that all certificates are protected from key compromise of the root CA.
In a cross-certification hierarchy, a CA acts as both a root CA and a subordinate CA. This structure is used when two organizations want to establish certificate trust between them.
Cross-certification is commonly deployed in business-to-business scenarios when the participating organizations have existing CA hierarchies. Cross-certification allows existing hierarchies to be maintained while allowing additional CAs to exist in the hierarchy.
Figure 10.4 shows an example of a cross-certification hierarchy.
Figure 10.4 A cross-certification CA hierarchy
In this hierarchy the Corp CA is the root CA for the corporation. In addition to the self-signed certificate signifying that the Corp CA is a root CA, the Corp CA also has a subordinate CA certificate issued by the Partner CA. This certificate indicates that the Root CA is a subordinate CA of the Partner CA. Following the same logic, the Partner CA is a subordinate CA of the Corp CA.
Figure 10.5 shows the logical structures that exist in the case of cross-certification.
Figure 10.5 The logical view of a cross-certification CA hierarchy
The CA hierarchy on the left shows the CA structure from the Corp organization's perspective. The Corp CA is the root CA, and the Partner CA is the subordinate CA. The CA hierarchy on the right shows the CA structure from the Partner organization's perspective. For the partner organization, the Partner CA is the root CA and the Corp CA is a subordinate CA of the Partner CA.
The risk of cross-certification is that the existence of another organization's root CA means that all other CAs in the structure and the certificates issued by those CAs are also trusted. This circumstance often might be considered excess trust between organizations. You may want to trust only certificates issued by a specific CA located within a partner's CA hierarchy.
You can minimize this risk by implementing certificate trust lists (CTLs). A CTL is a group of CA certificates deemed trustworthy by a CA administrator. Only certificates issued by CAs in the CTL can be used. In a cross-certification scenario, only the CAs at the partner's site that you trust would be included in the CTL.
Use the decision matrix in Table 10.2 to decide whether to implement a rooted CA hierarchy or a cross-certification hierarchy.
Table 10.2 Designing Certificate Hierarchies
To | Do the Following |
---|---|
Provide maximum security for the root CA | Deploy a rooted CA hierarchy. Only a rooted CA hierarchy allows the root CA to be removed from the network. |
Limit trusted CAs to your organization's CAs | Deploy a rooted CA and remove all other CAs from the trusted root store. |
Provide interoperability between organizations | Deploy a cross-certification hierarchy where the root CA from each organization is configured as a subordinate CA of the other organization. |
Limit which CAs will be trusted from a partner organization | Deploy a cross-certification hierarchy and configure a CTL that contains only the trusted CAs from the partner organization. |
Blue Yonder Airlines requires a CA hierarchy only for the internal network and for customers of its Web site. The company doesn't need to create cross-certification with another organization.
The rooted CA hierarchy allows Blue Yonder Airlines to increase security by removing the root CA from the network. Even though Blue Yonder Airlines will acquire a certificate for their Web server from a public CA such as Entrust, there's no business reason to create cross-certification between the Blue Yonder Airlines CA hierarchy and the Entrust CA hierarchy. The Entrust certificate will be trusted because the root certificate from Entrust CA will be included in the Trusted Root Certification Authorities container by default for all users of the network, as shown in Figure 10.6.
Figure 10.6 The entrust root CA certificate included in the Trusted Root Certification Authorities store
Within Microsoft Services you can install two scopes of CAs: Enterprise and Standalone. The scope of the CA defines where the CA stores its database of issued certificates and how the CA issues certificates, as shown in Figure 10.7.
Figure 10.7 Configuring Certificate Services as either an Enterprise or Standalone CA
An Enterprise CA must be a member of a Windows 2000 domain. Only members of the Enterprise Admins universal group can install an Enterprise CA. If you aren't a member, the Enterprise CA options will be unavailable.
Some of the reasons to consider deploying an Enterprise CA include
NOTE
Only Enterprise CAs support the use of certificate templates. Standalone CAs don't implement certificate templates to define certificate usage restrictions.
Figure 10.8 Configuring Enroll permissions for each certificate template
Figure 10.9 Certificates issued automatically by Enterprise CAs
Standalone CAs can be members of a domain or stand-alone servers in a workgroup. The Standalone CA differs from the Enterprise CA because all data is stored in a local database and the Standalone CA doesn't use certificate templates.
Because the Standalone CA doesn't use certificate templates, a security principal must complete a form when requesting a certificate. By default, the certificate request is then reviewed by a certificate administrator who accepts or rejects the certificate request in the Certification Authority console. All requests requiring a decision by a certificate administrator will be placed in the Pending Requests store until a certificate administrator either issues or denies the certificate request, as illustrated in Figure 10.10.
Figure 10.10 A Standalone CA issuing a certificate request
NOTE
The default behavior for a Standalone CA is to require the certificate administrator to issue or deny certificate requests. You can configure the issuance policy to automatically issue certificates for valid certificate requests to match the default behavior of an Enterprise CA.
Consider deploying a Standalone CA when
NOTE
X.509 is a standard for digital certificates defined by the International Telecommunication Union-Telecommunications Standardization Sector (ITU-T) and the ISO/International Electrotechnical Commission (ISO/ IEC). First published in 1988 and then extended in 1993, the current version (3.0) was released in 1996.
Mixing and Matching CAs
A common question is whether you can mix Standalone and Enterprise CAs in the same CA hierarchy. The answer is Yes! When you design a secure CA hierarchy, one of your goals is to configure the root CA as an offline CA. You must use Standalone CAs for offline root CAs, due to Enterprise CAs' dependence on Active Directory.
Figure 10.11 shows a CA hierarchy that mixes both Standalone and Enterprise CA policies.
Figure 10.11 Enterprise and Standalone CAs existing in the same CA hierarchy
NOTE
Don't consider Enterprise to mean domain and Standalone to mean workgroup. The terms refer only to where the certificate services database information is stored.
Use the decision matrix in Table 10.3 to determine when to implement an Enterprise CA or a Standalone CA in your certification authority hierarchy design.
Table 10.3 Deciding Between Enterprise and Standalone CAs
Use This CA Scope | When You Want To |
---|---|
Enterprise CA | Deploy Certificate Services for an internal deployment where the users will be providing their network credentials for authentication. Deploy Windows 2000 services that require certificate templates provided only by Enterprise CAs. These include
Leverage the standard Windows 2000 security model to determine who can acquire specific certificate templates. |
Standalone CA | Deploy offline CAs that must operate without communicating with the rest of the network. Configure the Exchange 5.5 KMS to use x.509 v3 certificates, rather than the default x.509 v1 certificates. Place the CA in a location where it can't connect to Active Directory. |
The requirement to issue smart cards for both customers and internal user accounts requires you to deploy an Enterprise CA. Only an Enterprise CA supports certificates for smart cards. Each CA hierarchy should have an offline root CA to increase the security of the CA hierarchy. An offline root CA requires you to configure a Standalone scope for the CA.
For the internal network, Blue Yonder Airlines requires a mix of Standalone and Enterprise CAs.
An important step in protecting your CA hierarchy is to remove the root CA, and, potentially, a second level of CAs from the network. This action ensures that the CAs aren't compromised. Remember that if a CA is compromised, all certificates issued by the CA also are compromised.
The decision to remove a CA from the network isn't as simple as removing the network interface card or shutting down the server. The design of an offline CA also must include the following considerations:
You perform the primary configuration of an offline root CA in a text configuration file known as Capolicy.inf. The Capolicy.inf file must be placed in the Systemroot folder before you install Windows 2000 Certificate Services. The Capolicy.inf file is read from the Systemroot folder during the installation of Certificate Services. The following code example shows the structure of the Capolicy.inf file:
[Version] Signature="$Windows NT$" [CAPolicy] Policies=LegalPolicy [LegalPolicy] OID=1.2.840.113556.1.4.7000.233.28688.28684.8.189041.1105561.1861398.1661801.1 Notice="http://www.abc.tld/certificate/cps.doc" [CRLDistributionPoint] URL="http://www.abc.tld/Public/crlname.crl" URL="ldap:///CN=EnterpriseCA,CN=CA-ROOT,CN=CDP, CN=Public%%%%20Key%%%%20Services,CN=Services,CN=Configuration, DC=abc,DC=tld?certificateRevocationList?base? objectclass=cRLDistributionPoint" [AuthorityInformationAccess] URL="http://www.abc.tld/Public/certname.crt" URL="ldap:///CN=EnterpriseCA,CN=AIA, CN=Public%%%%20Key%%%%20Services,CN=Services,CN=Configuration,DC=abc, DC=tld?cACertificate?base?objectclass=certificationAuthority" [Certsrv_Server] RenewalKeyLength=4096 RenewalValidityPeriod=5 RenewalValidityPeriodUnits=Years
NOTE
The four "%"s in a row aren't a typo. You must represent a space character with the string "%%%%20" when defining Lightweight Directory Access Protocol (LDAP) paths in the Capolicy.inf configuration file. The "%" symbols ensure that the space character is included in the LDAP URL.
The following sections are included in the Capolicy.inf configuration file:
Do You Use Capolicy.inf Only for Root CAs?
In most cases, the answer is yes. The only time you use a Capolicy.inf configuration file for a nonroot CA is to define a CPS for an issuing CA. The Capolicy.inf text file is the only way you can enter information into a CPS for Windows 2000 Certificate Services.
A nonroot CA processes only the [CAPolicy] and [Policyname] sections of the Capolicy.inf configuration file. All other sections are ignored because they're defined by the issuing CA from which the subordinate CA received its subordinate CA certificate.
In addition to configuring the Capolicy.inf file with CRL and AIA publication points, you must also configure the certificate distribution points (CDPs) for the CRL and AIA associated with the CA. Configure the CDPs in the properties of the Certification Authority by defining the X.509 extensions for the CA's policy module, as shown in Figure 10.12.
Figure 10.12 Defining certificate distribution points for the CRL and AIA
The URLs you define for the CRL and AIA distribution points will be included in the properties of any newly issued certificate by the CA.
Include the design points featured in Table 10.4 in your security plan to ensure the security and functionality of an offline root CA.
Table 10.4. Securing Offline Root CAs
To | Do the Following |
---|---|
Allow the CA to be removed from the network for long periods of time | Configure the CA to be a Standalone CA. Make sure that the CA is installed on a Windows 2000 Server that isn't a member of a Windows 2000 domain. |
Provide the strongest form of encryption at the offline root CA | Implement a hardware CSP for the offline root CA. Ensure that the associated CSP is installed before installing the offline root CA. |
Make the CRL and AIA available to network users | Configure the Capolicy.inf file to provide alternative locations for the CRL and AIA publication points. Configure the publishing schedule for the CRL to be a longer period of time than for issuing CAs. Configure the certificate distribution points for the CRL and AIA to be located at areas of the network that are available when the root CA is offline. Establish a manual process for placing the updated CRL or AIA into the public locations outlined in the certificate properties for offline CAs. Edit the registry to allow longer certificate lifetimes for the certificates issued by the root CA. The default of one year is too short for subordinate CAs. |
Define a CPS | Ensure that the Capolicy.inf file is edited and placed in the Systemroot folder before installing Certificate Services. To provide for updates, ensure that the Notice= line references a URL rather than just a text statement. Using a URL allows you to modify the CPS without having to renew the CA's certificate. |
Provide the most security for your CA hierarchy | Ensure that at a minimum, the root CA is removed from the network. For higher-security networks, also consider removing the second layer of CAs in the rooted hierarchy from the network. |
Blue Yonder Airlines must use a Standalone CA for the offline root CA. Depending on the level of business expected for the Web site, Blue Yonder also can remove a second layer of subordinate CAs from the network.
Blue Yonder Airlines must configure a Capolicy.inf configuration file to issue a CPS that defines usage policy for all customers who receive Blue Yonder Airlines smart cards. The Capolicy.inf configuration file must also provide CRL and AIA publication points that will be available when the root CA is removed from the network.
For example, Blue Yonder Airlines could use the following Capolicy.inf file when installing Certificate Services on their offline root CA:
[Version] Signature="$Windows NT$" [CAPolicy] Policies=BlueYonder [BlueYonder] OID=1.2.840.113567.1.4.6000.234.28697.28632.8.1325041.1005461.1934398.1223661.4 Notice="http://www.blueyonder.tld/Public/etiquette.html " [CRLDistributionPoint] URL="http://www.blueyonder.tld/Public/crlname.crl" URL="ldap:///CN=RootCA,CN=OfflineROOT,CN=CDP, CN=Public%%%%20Key%%%%20Services,CN=Services,CN=Configuration, DC=AD,DC=Blueyonder,DC=Tld?certificateRevocationList?base? objectclass=cRLDistributionPoint [AuthorityInformationAccess] URL="http://www.blueyonder.tld/Public/certname.crt URL="ldap:///CN=RootCA,CN=AIA, CN=Public%%%%20Key%%%%20Services,CN=Services, CN=Configuration,DC=AD,DC=Blueyonder, DC=Tld?cACertificate?base?objectclass=certificationAuthority" [Certsrv_Server] RenewalKeyLength=4096 RenewalValidityPeriod=5 RenewalValidityPeriodUnits=Years
In addition to configuring the Capolicy.inf configuration file, Blue Yonder must set the following attributes for the CA before removing the CA from the network:
Once you've determined your CA structure's security by implementing an offline root CA, you must design a CA hierarchy below the root CA. The CA hierarchy helps you deploy certificates to security principals in your organization. In general, your CA hierarchy falls into one of the following general structures:
Figure 10.13 A CA hierarchy based on usage
You configure this structure by setting each CA to issue only the certificates that are required by the associated project. For example, in a smart card deployment, you might want to configure the CA to issue only Smartcard User, Smartcard Logon, Enrollment Agent, and Enrollment Agent (Computer) certificates. This action restricts the CA to issuing only certificates for the smart card deployment.
NOTE
For more information on configuring a CA to support smart card authentication, see Lesson 3, "Using Certificates for Authentication," in this chapter.
Figure 10.14 A CA hierarchy based on an administrative model
At the third level in the figure, different CAs exist for full-time and part-time personnel so that different certificate validity periods can be issued.
Figure 10.15 A CA hierarchy based on geographic location
Regardless of the structure, for maximum security you must configure the root CA as an offline CA. In higher-security networks, consider configuring the second-level CAs as offline CAs as well. For example, in the structure-by-location example in Figure 10.15, you could configure the Europe and North America CAs as offline CAs.
How Many Levels Do I Require?
The general goal is to create a CA hierarchy that's three to four levels deep. CA hierarchies with fewer than three levels are more vulnerable. If there are only two levels and the root level is compromised, all certificates also are compromised. Likewise, having a CA structure that's more than four levels deep introduces unnecessary complexity and might result in extra time being needed to verify the revocation status for each CA in the certificate chain.
Use the decision matrix shown in Table 10.5 when deciding which CA hierarchy structure to deploy for your organization.
Table 10.5 Choosing CA Hierarchy Structures
Choose This CA Structure | When the Following Conditions Exist |
---|---|
Usage structure | There are several active projects within an organization and each project is managed by a separate team. A pilot project requires that the CA related to the project be rebuilt when the project is launched for the entire organization. You want CAs dedicated to issuing certificates related to specific projects. |
Administrative structure | The organization requires different issuance policies based on the relationship of the security principal to the organization. You must issue the same certificate template, but with differing validity periods. |
Location structure | The organization is geographically distributed and management of certificates is delegated to each region. |
The final CA hierarchy design might end up as a combination of these designs. You might need to implement a highly customized hierarchy to meet your business needs.
Blue Yonder Airlines could implement a CA hierarchy based on either usage or administration. Blue Yonder doesn't need to develop a CA hierarchy based on location because the smart card authentication for clients will be centralized at the Salt Lake City office.
Figure 10.16 shows one possible Blue Yonder Airlines CA hierarchy that meets both its customer and internal network needs.
Figure 10.16 A CA hierarchy based on administration and usage
Blue Yonder Airlines can establish two separate CAs for outside customers ordering airline tickets. The Enrollment CA will issue only Enrollment Agent (Machine) certificates and Enrollment Agent certificates. This arrangement allows greater security for the Enrollment Agent server. The Smartcards CA issues the smart card user certificate template.
You can establish three CAs for the internal network. Use the Internal Smartcards CA to issue all certificates related to smart card logon. Use the IPSec CA to issue IPSec-specific certificates for all computers that perform IPSec, including L2TP/IPSec Virtual Private Network (VPN) clients. Finally, use a dedicated CA to issue other certificates (such as User and Computer certificates) for users and computers requiring certificates for other purposes on the network.
The final step in deploying CAs is planning for the recovery of the CAs in the event of disaster. Disaster can result from disk failure or accidental removal of Certificate Services.
You can prevent CA failure by implementing hardware solutions for fault tolerance. Certificate Services performs best when you place the Certificate Services database on a redundant array of independent disks (RAID) volume that combines multiple disks into what is known as a stripe set with parity or RAID-5 disk volume. A RAID-5 volume protects data by writing the data in a stripe across multiple physical disks. For each stripe, one disk contains parity information that allows recovery of the data stored in that stripe if a single disk fails in the RAID-5 disk set. In addition, you should store the Certificate Services log files on a RAID-1 mirror set. This ensures that the log files are also protected in the event of disk failure. A mirror set offers better performance than RAID-5 disk volumes for log files.
Ensure that the Certificate Services data stores are backed up regularly. You can accomplish this in one of two ways:
WARNING
You must include Internet Information Services (IIS) in the backup set because the Web Enrollment Support pages included with Certificate Services update the IIS metabase.
In the case of an offline CA, you may want to consider backing up the server with disk imaging software. Some organizations store an exact duplicate of the offline CA at a remote location to protect against natural disasters. When the CA is updated (such as renewing the CAs certificate), a new image is created for remote storage.
Consider the points in Table 10.6 in your disaster recovery plan for CAs.
Table 10.6 Planning Disaster Recovery of a CA
To | Do the Following |
---|---|
Prevent loss of data in the Certificate Services database | Store the Certificate Services database on a RAID-5 disk volume. Hardware RAID-5 is preferable to software RAID-5 solutions for both performance and recoverability reasons. Store the Certificate Services log files on a RAID-1 disk volume. As with the Certificate Services database, hardware RAID-1 solutions are preferable to software RAID-1 solutions for both performance and recoverability reasons. |
Ensure that a rebuilt CA is still valid for all issued certificates | Ensure that all server keys are backed up. This allows the CA to reuse existing keys in the event of a failure. |
Allow a CA to be recovered | Ensure that the Certificate Service database is regularly backed up through the Certification Authority console or by including System State in the backup set. |
Ensure recoverability | Run a test recovery to a different server to ensure that your recovery procedures are adequate. |
Blue Yonder Airlines must include a backup and restore strategy for all CAs in their organization. The company should purchase a common computer system that implements RAID-5 and RAID-1 disk sets for the Certificate Services database and log files.
In addition, you should schedule regular backups that include the system state backups. The backup sets must include the IIS directory structure so that the IIS metabase captures all changes made by Certificate Services.
To ensure recoverability in the event that you have to rebuild and restore a CA from backup, you should export the existing private and public keys associated with the CAs certificate to files and include those files in the regular backup set.
Finally, you should create an image of the root CA for the hierarchy on a CD. This CD allows you to restore the root CA quickly in the event of failure. You must update this image whenever additional certificates are issued or renewed at the root CA.
Developing your CA structure is a primary component of your PKI design. The CA structure must meet your business needs, ensure security, and, most of all, provide the necessary functionality to ensure success for your PKI-based applications.
Make sure that your design includes a decision on whether to use public or private CAs for specific scenarios. Once you decide on using a public or private CA, you must design the CA hierarchy structure. This process involves determining whether to use a rooted hierarchy or a cross-certification hierarchy. With rooted hierarchies, you must decide whether a CA will be taken offline to protect the Certificate Services database from vulnerabilities.
Finally, you must design a CA structure that mirrors your administrative model. Protect the CA structure in the event of failure so that you can restore the CA hierarchy without reissuing certificates.