Overview and Process of Using Private CAs and Private Certificates
Private Certificate Authority (PCA) is a private CA and certificate management platform. It allows you to set up a complete CA hierarchy and use it to issue and manage private certificates within an organization through simple and visualized operations. It authenticates application identities and secures data encryption/decryption within the organization's network.
Certificates issued by private CAs are trusted only within your organization but not trusted on the Internet. To use a certificate that is trusted on the Internet, purchase an SSL certificate. For details, see Purchasing an SSL Certificate.
For details, see Figure 1 and Table 1.
| Step | Operation | Description |
|---|---|---|
| 1 | Purchase a private CA as required. | |
| 2 | A private CA instance must be activated before it is used to issue certificates. You can activate the purchased private CA instance as the root CA or subordinate CA. A subordinate private CA takes effect and can be used to issue private certificates only after it is activated. | |
| 3 | Apply for a private certificate with the activated private CA. | |
| 4 | After the application is approved, you can download the private certificate and install it on the server. | |
| 5 |
|
Hierarchy of Private CAs and Certificates
A path length determines how many levels of subordinate CAs the current CA can issue. It is used to control the certificate chain length. A well-designed CA hierarchy can make fine-grained control over certificates a reality. With PCA, you can build a CA hierarchy with up to seven levels.
| CA Hierarchy | Remarks | Description |
|---|---|---|
| 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. |
| 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 narrows 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. |
| 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. |
Differences Between a Root CA and Its Subordinate CAs
A root CA serves as the top node of the certificate trust chain. It only issues certificates to subordinate CAs. The operation permissions and application scenarios of a root CA must be strictly controlled.
A subordinate CA mainly issues end-entity certificates. It is recommended that multiple subordinate CA systems be deployed independently based on business lines and organizational units. Certificates are issued by zone to ensure secure isolation of permissions, keys, and certificate data.
A private certificate is an end-entity certificate, which is installed on an end entity, including certificates used for the client (or client certificates) and certificates used for the server (or server certificates). An end-entity certificate is at the bottom layer of a certificate chain and is used to authenticate an entity. It cannot be used to issue a certificate and is a credential for HTTPS communication between the entity that owns the certificate and other entities.
What is your overall rating for this page?
Thank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot
