Designing a Private CA Hierarchy

With PCA, you can create a hierarchy of certificate authorities with up to seven levels. The root CA can have any number of branches and have as many as six levels of subordinate CAs (or child CAs or intermediate CAs) on each branch. A well-designed CA hierarchy can:

Keep the entire public key infrastructure (PKI) system more reasonable and secure.
Make fine-grained control over certificates a reality.
Make the PKI system more suitable for your own business structure, facilitating workloads migrations and expansion.

Table 1 describes each structure that you can create in the PCA service. You can design the CA hierarchy to meet your business needs.

**Table 1** CA hierarchies
CA Hierarchy	Description	Remarks
Single-level CA hierarchy	The root CA directly issues private certificates.	This structure does not comply with security specifications and is often used in non-production environments, such as environments for development and testing when a full chain of trust is not required. The root CA is frequently used, and the risk of key leakage is high. Once the key of the root CA is leaked, all certificates issued by the root CA must be discarded, and all terminals must quickly remove the leaked root CA from the trusted root certificate list, which is time- and labor-consuming. The worst of this is that services are severely interrupted. Figure 1 shows a single-level CA hierarchy.
Two-level CA hierarchy	The root CA issues level-2 subordinate CAs, and the subordinate CAs (with the path length set to 0) issue private certificates.	This structure is a common CA hierarchy. The CA hierarchy has only two levels. The certificate chain uses less resources during transmission and certificate validation compared with other complex hierarchies. The root CA is isolated from the private certificates, and subordinate CAs are used to issue certificates. If a subordinate CA is compromised, you only need to revoke and replace all certificates below the subordinate CA. There is no impact on other subordinate CAs. The terminal does not need to remove the root CA. This thereby narrow the impact scope of leakage events. Figure 2 shows a two-level CA hierarchy.
Three-level CA hierarchy	The root CA issues level-2 subordinate CAs, and the level-2 subordinate CAs (with the path length set to 1) issue level-3 subordinate CAs. The level-3 subordinate CAs (with the path length set to 0) issue private certificates.	This structure is also a common CA hierarchy. It is suitable for organizations with complex structures. The three-level structure enables fine-grained control over certificate distribution and management. The PKI system has more levels to separate the root CA and private certificates, which can better protect the confidentiality of root CA keys. Figure 3 shows a three-level CA hierarchy.
CA hierarchies with four to seven levels	The root CA issues level-2 subordinate CAs (path length range: 2 to 5). Level-2 CAs issue level-3 subordinate CAs (path length range: 1 to 4), and level-3 CAs issue level-4 subordinate CAs (path length range: 0 to 3). The bottom level subordinate CAs are responsible for issuing private certificates.	This structure is seldom used. Although the CA hierarchy is very fine-grained, it has too many levels between the root CA and the private certificates. This leads to a large certificate chain file, which uses heavy network transmission overhead and takes long time for certificate validation. Figure 4 shows the CA hierarchies with four to seven levels.