A Detailed Guide on Building your own PKI

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.

Today, most PKI setups in organizations are decades old and need to be revamped and upgraded to match the changing IT landscape. The biggest need for most organizations is to provide a highly secure and very robust PKI setup that can issue and manage digital certificates quickly through self-provisioned systems. An internal PKI setup by the organization should also support both on-premises and Cloud systems, to meet DevOps requirements. But how does a PKI work?

What is a PKI and how does a PKI work?

A PKI is a setup that provides digital certificates to end-users, systems, devices, and applications to provide them with trusted identities. These identities are used for authentication of the certificate holder, as well as for establishing secure communications to other certificate holders within the network. A PKI infrastructure is based upon asymmetric key cryptography utilizing a public key and 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. Along with providing the certificate holders with their identity, these certificates also provide access rights and enables the certificate holder to establish a secure channel between two certificate holders to communicate.

Components of PKI

1. Root CAThe 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.
2. Intermediate CAAn 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.
3. Issuing CAThe 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.
4. Public KeyA 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.
5. Private KeyA 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.
6. Certificate StoreA 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.
7. 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.
8. Delta CRLsDelta 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.
9. 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.
10. Certificate ManagementCertificate 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.
    1. Certificate EnrollmentThis 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.
    2. Certificate IssuanceOnce 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.
    3. Certificate ValidityCertificate 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.
    4. Certificate RevocationThis 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.
    5. Certificate RenewalWhen 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.
11. 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.
12. 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.

Certificate Details

A digital certificate contains the following information to prove the identity of the certificate holder:

• 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

The “Key Usage” field can offer a lot of different uses for the digital certificate. The following are some of the most common usages for 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.
Enterprise PKI Services

Get complete end-to-end consultation support for all your PKI requirements!

Learn More

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.

Basic Architectures

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:

Two-Tier Architecture

A 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. This format makes it simple to deploy a two-tier PKI, without losing the security of the PKI. The below image shows how the setup of a two-tier PKI looks.




The design of a two-tier PKI architecture works with security and simplicity in mind, allowing the root of trust, the Root CA, to stay offline, protecting it from attack. Since the Root CA cannot be compromised, there is no worry that certificates are being misused or given to untrusted users. Instead of the Root CA giving out certificates, it creates the certificates for its original Issuing CAs, and allows them to to issue certificates to end-users. Two-tier PKI architectures are the most common type of hierarchy used.

Three-Tier architecture



The three-tier architecture is the most secure, as there are more links in the chain that would need to be compromised by attackers. However, setting up a three-tier architecture is a much more complicated process than setting up a two-tier architecture. With Intermediate CAs added into the mix, there are many more CAs to set up and integrate within the PKI, especially if a large number of Issuing and Intermediate CAs need to be created. The more CAs needed in a PKI, the more complicated implementation and maintainence is. A three-tier architecture is used much less often than a two-tier 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.

PKI as a Service

One form of PKI becoming more and more common is PKI as a Service. The way PKI as a Service works is that a provider will have the PKI setup, whether at their own data center or within your organization, and handle all of the management and updating in the PKI. This allows the organizations purchasing this service to not need to train or hire PKI professionals, thus saving them money and manpower. If the PKI is setup at the provider’s data center, the organization purchasing their services will most likely have the PKI issue certificates to their users, without having their own Issuing CA. PKI as a Service is one of the many services provided by Encryption Consulting. We assist your organization in the design, implementation, and deployment of your PKI. Part of our PKI setup includes the use of an on-premises Thales-SafeNet, nCipher, or Utimaco HSM. We can implement it in our data center in Dallas, Texas, or onto your site. Whichever hardware security module you choose to use, they are all FIPS 140-2 Level 2 and 3 compliant, so you should reach all of your compliance requirements. Along with an HSM, we also help you build and design a backup for your PKI, for minimal to no loss of service from unseen circumstances. We can also implement different SIEM tools into your PKI, allowing you to monitor certificates and keys, to keep you up to date on revoked certificates, unused keys, etc. Our PKI as a Service can also be set up either on-premises or on the Cloud.