Read time: 25 minutes
With the ever-changing and expanding enterprise infrastructure, it has become extremely important that every organization have their own robust and mature Public Key Infrastructure (PKI) set up that can establish trust between their systems, applications, users, and devices on untrusted networks. The adoption of private cloud, public cloud, DevOps, microservices, and the addition of IOT and network connected devices presents a wide range of areas to protect. A Public Key Infrastructure not only provides trusted identities to users and devices, but also provides a secure channel to protect communications in-transit.
What is a PKI and how does a PKI work?
Components of PKI
- Root CA
The Root CA is the most important 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 power to issue certificates for the Rot CA, as it is normally kept offline.
- Intermediate CA
An Intermediate CA, also known as a Subordinate CA, is a Certificate Authority that is set between the Issuing CA, which issues certificates on behalf of the root CA. Root CAs can have a lot of Intermediate CAs underneath them in the PKI hierarchy, but each Intermediate CA can only have one Root CA. The Intermediate CA is normally only used in a three-tier PKI architecture.
- Issuing CA
The Issuing CA issues certificates to end-users, devices, and other certificate requestors. Issuing CAs act like online Root CAs, issuing certificates to users who need them. Issuing CAs are used in both two-tier and three-tier CAs.
- Public Key
A cryptographic key which is created by an asymmetric key algorithm, such as RSA, and that can be issued to the public along with a digital certificate. A public key is not required to be stored securely and is used for public distribution. The public key is one half of the asymmetric key pair created with an asymmetric key algorithm.
- Private Key
A cryptographic key which is the other half of an asymmetric key pair. The private key is the most important component of authentication and should be stored securely.
- Certificate Store
A certificate store is used to store root certificates issued from multiple CAs. Certificate stores 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 is a list that that contains information on revoked certificates, including their certificate information and the reason for the certificate’s revocation. CRLs are published at certain time intervals, potentially causing issues with certificates revoked between CRL publication times.
- Delta CRLs
Delta CRLs are CRLs 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.
- HSM (Hardware Security Module)
An HSM is a very important component of a secure PKI setup and is advised to be used to store the Root CA’s private key. HSMs can also be used to store the private keys of Intermediate Certificate Authorities. HSMs are extremely secure, with tamper-resistant and tamper-evident safety mechanisms.
- Certificate Management
Certificate Management is an important aspect of a PKI infrastructure, as it helps with keeping certificates up-to-date and secure. The following are different phases of the Certificate Lifecycle that are used for Certificate Management.
- Certificate Enrollment
This phase relates to the initial creation of a certificate for the certificate requestor. An online user, organization, or device sends out a Certificate Signing Request, or CSR, to the Certificate Authority. The CSR contains the public key of the requestor and other information relating to the requestor. The CA then verifies the given information and, if it is legitimate, creates the certificate and enrolls the user in the PKI. The Certificate Authority used to create the certificate can be owned by the organization that desires the certificate, or by a third-party. If the certificate is obtained from a third-party, then it must be purchased from them.
- Certificate Issuance
Once the certificate has been created, and the user has been enrolled in the PKI, the certificate is issued to the user. As previously mentioned, the user now uses this certificate to identify themselves within the network. This ensures that each member of the PKI trusts the certificate holder.
- Certificate Validity
Certificate validity involves the checking of the validity of the certificate when interacting with another member of the network. The way this certificate is verified is by following the chain of trust of the certificate. This chain of trust, or certification path, shows the certificate of the Issuing CA that issued the certificate being verified. The certification path of the Issuing CA’s certificate is then checked, going all the way up until the Root CA’s certificate is reached. Once the chain of trust is verified up to the Root CA, that certificate originally being verified is now seen as valid.
- Certificate Revocation
This step only occurs if the certificate expires and is no longer needed, if the certificate is stolen and misused, or if the certificate in general is no longer needed. If any of these situations occur, then the certificate is revoked and can no longer be used. The revoked certificate is then added to the CRL.
- Certificate Renewal
When a certificate expires, it must be renewed. This process reissues the certificate, using the same key pair and information, but with a newly updated expiration date.
- Certificate Enrollment
- Certificate Policy (CP)
The Certificate Policy is a document setting forth standards of the PKI. The CP lets users and PKI maintainers know how to apply for a certificate, the naming standards for certificates, and more. The CPS follows the standards set forth in the CP.
- Certificate Practice Statement (CPS)
The Certificate Practice Statement sets forth the procedures used in the PKI. These procedures are based around the Certificate Policy’s standards. The CP tells a user or maintainer what to do, while the CPS tells them how to do it.
- Details of Certificate Issuer: The Issuer details include the name of the Issuing CA, shown on the General tab under the “Issued by” field and in the Details tab under the “Issuer” field. The “Issuer” field not only shows the name of the Issuing CA, but also the Common Name, Organization name, and Country of the the Issuer.
- Details of the Certificate holder: The Certificate holder details in the certificate include the holder’s public key, their public key, and the name of the certificate holder
- Certification Path: Also included in a digital certificate is the certification path of the certificate. This helps other users, applications, or devices within the network verify the validity of the certificate.
- Public key: As mentioned, the certificate holders public key is stored within the certificate. This, along with their own private key, verifies that the key holder matches the public key within the certificate.
- Key usage & extended key usage: The “Key Usage” field tells the viewer what the key is used for. There is also a chance that the certificate has an “Extended Key Usage” field, which tells of other uses for the key, that is not included in the “Key Usage” field.
- Digital signature of the issuer: One other important part of a digital certificate is the issuer’s digital signature. This helps with verification of the certificate, as it lets the viewer know who issued the certificate.
Common Use Cases of Digital Certificates
- SSL/TLS certificates to secure communication channels – One of the main certificate uses is for SSL/TLS communication. This involves keeping communications secure between a client and server or a client and another client.
- Digital signatures for documents – Certificates can also be used as digital signatures for documents. Digitally signing a document lets the recipient of the document know that the signer has sent the document and that there is nothing malicious within the document.
- Code signing – Code signing with certificates is very similar to document signing. When code is created, the code designer signs the code to verify they have created it and that no malicious code is hidden within.
- Client-server authentication – Client-server authentication verifies the identity of both the client and server to the other party of the communication. The respective communicators check the certification path of the other’s certificate, verifying that their certificate is valid.
- VPN authentication – Similarly to client-server authentication, VPN authentication verifies the identity of each member of the connection using their certificate’s certification path.
- Email & data encryption – Email and data encryption uses the sender’s private key to encrypt data. Once the email is received, since the certificate is public knowledge and contains the sender’s public key, the message can be decrypted and the recipient will know that the sender is who they say they are.
- Wifi authentication – Wifi authentication also verifies the identity of each member of the connection using their certificate’s certification path.
Key elements to setup your own PKI
- Identify your certificate requirements – You must first identify all current and future requirements for digital certificates. This refers to what your certificates within your PKI are, and will, be used for. See the Common Use Cases for Digital Certificates section above for more information.
- Selecting the Right Certificate Authority – Based upon your requirements, you must select the type of Certificate Authority you want to setup. If you are typically 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 for your organization. Other types of CAs are Google and Amazon CAs.
- Cloud vs On-premises hosting – Traditionally, all internal PKIs aare setup on-premises. More and more often, however, applications and services are migrating to the Cloud, so it is important to support Cloud requirements. In situations where the majority of services and products are on the Cloud, it is important to ensure that the CA you are setting up supports Cloud-based requirements.
- Certificate Management – Just setting up an internal PKI infrastructure does not ensure that your organization will be able to meet and manage all PKI-related requirements. One of the most important requirements of a PKI infrastructure is automating certificate management operations. More so with DevOps, continuation, and CI/CD pipeline, it is also very important to make provisioning and deprovisioning certificates zero touch and instant. This ensures all certificate operations necessary are quick to be completed and human error will not effect them.
- Securing your Root & Issuing CA private keys – The private keys of the Root and Issuing CA’s have to be stored with the utmost security because they form the root of trust. As such, it is important that these private keys are stored securely on an HSM. Typically the Root & Issuing CA private keys are stored on the HSM, which provides maximum security and stops any tampering or misuse with these keys.
- Creating CP (Certificate Policy) & CPS (Certificate Policy Statement) creation – The CP & CPS of the PKI define the policies for your Certificate Authorities and will help you design your PKI infrastructure. These documents also act as the framework and scope of your Certificate Authority, telling it to whom it can issue certificates, what the boundaries within which the CA will work are, and the procedures used to manage your CA.
- Certificate revocation and CRL checking – One more important step in creating your PKI is ensuring that certificates are revoked when necessary, and that when they are revoked, they are placed into the CRL. It is also important to have your CAs regularly check for new CRLs, allowing them to be up-to-date on the latest revoked certificates.
The two most common PKI architectures are the two-tier and three-tier architecture. Below are the PKI components that make up each type of PKI architecture:
Common Deployment Mistakes
- Lack of planning and tracking: One of the more common mistakes with a PKI 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 could exploit. Poor planning can also lead to poor certificate and key management, offering another avenue for attackers to exploit. Along with planning, poorly tracking PKI assets can also cause issues. To fix these issues, ensure proper planning is completed by PKI professionals, to ensure the best quality PKI. Utilizing SIEM tools can also help track the different components of your PKI, giving you more transparency into it’s inner workings.
- Root CA Security: As the root of trust, the Root CA is vitally important to the PKI, and thus must be well secured. If the Root CA were to be compromised, the entire PKI would need to be recreated from scratch, as no certificates issued within that PKI would be trusted any more. To fix this, utilize an HSM to keep the Root CA’s keys secure from outside attack.
- Bad Certificate Lifecycle management: Another common PKI deployment mistake is poor certificate lifecycle management. If certificates are compromised or left unused, malicious users could use the certificates to steal or access sensitive data. Also, if a user or application’s certificate were to expire 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.