Designing a PKI Certification Authority Hierarchy – Best Practice
The ever evolving and expanding enterprise infrastructure has made it extremely important that every organization has its own mature and robust Public Key Infrastructure (PKI) set up that establishes trust between the systems, applications, devices, and users on untrusted networks, in this article we explain the process of designing a PKI Certification Authority Hierarchy and best practices.
A Public Key Infrastructure provides trusted identities to users and devices and gives a secured channel to protect communications in transit. PKI deployments are 90% planning and 10% implementation and maintenance. It goes without saying that planning is the key to designing a PKI hierarchy.
Let us go through each of the planning best practices for designing a PKI hierarchy that will help you figure out how to map it in your scenario.
Applications that are using PKI
Before digging deep into how to design a PKI hierarchy, we need to understand the need. PKI implementation is typically launched when one or more applications that are dependent on the existence of PKI are introduced. This leads to defining requirements as to who will manage the applications, certificate distribution, number of users, and how certificates are used by the applications.
Certificate Holders
Certificate holders are those who request and require certificates. They include:
- Computers
- Users
- Network Devices
- Services
How Does PKI Work?
A PKI infrastructure is based upon asymmetric key cryptography utilizing a public key and a private key pair associated with a digital certificate issued by an issuing Certificate Authority (CA). This certificate authority establishes trust between two certificate holders with the help of these digital certificates.
What are the Components of PKI?
The components of PKI are significant in designing a PKI certification authority hierarchy. They include:
Root CA
Root CA is perhaps the most significant component of a PKI Infrastructure. The Root CA issues certificates and establishes the root of trust between identities to which it issues a digital certificate. The Root CA also issues certificates to issuing CAs, giving them the authority to issue certificates for the Root CA, as it is normally kept offline.
Intermediate CA
Intermediate CA is a Certificate Authority set between the Issuing CA, which issues certificates on behalf of the Root CA. In a PKI hierarchy, Root CA can have a lot of Intermediate CA or Subordinate CA, but every Intermediate CA can have only one Root CA.
Issuing CA
The Issuing CA issues certificates to devices, end users, and other certificate requestors. They act line online Root CA, issuing certificates to users who need them. Issuing CAs are used in both two tier and three tier CAs.
Public Key
Created with the help of an asymmetric key algorithm such as RSA, a public key is a cryptographic key. It is one half of the asymmetric key pair and can be issued to the public along with a digital certificate. It is not required to be stored securely and is used for public distribution.
Private Key
The private key is the other half of the asymmetric key pair. It is the most important component of authentication. The private key is a cryptographic key, and it should be stored securely.
Certificate Store
A certificate store is used to store root certificates issued from multiple CAs. The certificate store also contains Intermediate CA root certificates and end user certificates. The certificate store tells a computer which CAs are trusted CAs.
Certificate Revocation List (CRL)
A CRL contains all information on revoked certificates, including their certificate information and the reason for their revocation. CRLs are published at regular time intervals, causing issues with certificates revoked between CRL and publication times.
Delta CRL
Delta CRLs are CRLs that are published in the time interval between CRLs being published. This covers the potential for overlooking a certificate revoked before the publishing of the next CRL.
Hardware Security Module (HSM)
An HSM is another important designing component for a secure PKI setup. It should be used to store the Root CA’s private key. HSM can also be used to store the private keys of Intermediate CAs. Hardware Security Modules are tamper resistant and tamper evident safety mechanisms and are very secure.
Certificate Management
This is also an important component to be considered while designing a PKI infrastructure. It helps to keep certificates up to date and secure. Certificate Management has the following phases for Certificate Lifecycle:
- Certificate Enrollment: It refers to the initial creation of a certificate for the certificate requestor
- Certificate Issuance: This is the phase where the certificate is issued to the user after enrolling it in the PKI.
- Certificate Validity: This involves checking the validity of the certificate when interacting with another member of the network.
- Certificate Revocation: This step is followed if the certificate is no longer needed.
- Certificate Renewal: This process renews the certificate on expiry with the same key pair and information and the new expiry date.
Certificate Policy
Certificate Policy is a document that sets forth the standards of the PKI. The CP lets users and PKI maintainers know how to apply for a certificate, the naming standards, and more.
Certificate Practice Statement (CPS)
The Certificate Practice Statement follows the standard outlined in Certificate Policy. It mentions the procedures used in the PKI. These procedures are based on the Certificate Policy standards. The CP tells the user or maintainer what to do, while the CPS tells them how to do it.
Key elements to design a PKI certification authority hierarchy
Identify the certificate requirements
First of all, you need to identify the current and future requirements for digital certificates. This means you should know what your certificates within your PKI are, and will be used for.
Selecting the right Certificate Authority
Based on your requirements, you need to select the type of Certificate Authority you want to set up. If you are using your PKI to support your enterprise requirements which are mostly based on Microsoft services, then setting up a Microsoft CA would be a good option. Other types of CAs include Google and Amazon CAs.
Cloud vs. On premises hosting
Generally, all internal PKIs are set up on premises. However, currently, more and more applications are migrating to the cloud. So it is important to support cloud requirements. In situations where most of the products and services are based on the cloud, it is important that the CA you are setting up supports cloud based requirements.
Certificate Management
Just setting up an internal PKI infrastructure is not enough for your organization to meet and manage all PKI related requirements. One of the most significant requisite of a PKI infrastructure is automated certificate management operation. More so with CI/CD pipeline, DevOps, and continuation. This ensures all necessary certificate operations are quickly completed, and any human error will not affect them.
Securing your Root and Issuing CA private keys
The Root private keys and the issuing CAs have to be stored with utmost security because they form the root of trust. Hence these private keys should be stored securely on HSM where maximum security is provided. It also stops any misuse or tampering of these keys.
Creating Certificate Policy (CP) and Certificate Policy Statement (CPS)
The CP and the CPS of the PKI define the policies for your Certificate Authorities and help you design your PKI infrastructure. These documents also act as the framework and scope of your Certificate Authority, telling whom it can issue certificates, procedures for managing the CA, and within what boundaries the CA will work.
Certificate revocation and CRL checking
Another important step in designing your PKI infrastructure is ensuring that certificates are revoked when necessary. Also, it needs to be ensured that the certificates revoked are placed into the CRL. It is also crucial that CAs are regularly checked for new CRLs, allowing them to be up to date on the latest revoked certificates.
Number of Tiers
Designing a PKI infrastructure requires you to know your PKI tiers. The basic PKI architecture involves two tier and three tier architecture.
The two tier architecture is the most common form of PKI hierarchy and also the most balanced architecture. It involves only a Root CA and the Issuing CAs in the PKI. The design of a two tier PKI architecture works with simplicity and security in mind, allowing the Root CA to stay offline, protecting it from attack.
Three tier architecture is similar to two tier architecture. It includes a Root and Issuing CA, along with Intermediate CAs in between the Root and Issuing CA. The Intermediary CAs add another layer to the certification path, allowing users to see one more CA in the chain of trust. A three tier architecture is used much less often than a two tier architecture.
Common PKI Deployment Mistakes
Lack of planning and tracking
One of the more common mistakes with PKI designing is the lack of planning and tracking. Poor planning in a PKI can hurt a PKI critically, as there may be security gaps that an attacker can exploit. Poor planning can also lead to a poor certificate and key management.
Root CA security
As the root of trust, the Root CA is vitally important to the PKI and must be well secured. If Root CA is compromised, the entire PKI would have to be recreated from scratch, as the certificates issued would not be trusted anymore. To fix this, HSM should be utilized to keep Root CA’s key secure.
Bad certificate lifecycle management
Bad certificate lifecycle management is another common PKI deployment mistake. If certificates are compromised or left unused, sensitive data could be at the mercy of malicious users. Also, if a user or application’s certificate expires without renewal, a loss of service could occur for that user or application. Proper automation and monitoring of the certificate lifecycle can stop this mistake from occurring.
Also Read
Follow the best practices while designing a PKI
Doing PKI right from the beginning is extremely important, as later on, it becomes difficult to change things. You should consider putting a lot of effort and time into figuring out how to design a PKI Certification Authority Hierarchy. Remember, 90% of any PKI infrastructure is planning and designing, while 10% is implementation.
