Public Key Infrastructure

6 min readJan 31, 2024

Asymmetric cryptography combines secured communication with a reasonable degree of practicality since, in many cases, it exempts password use. Yet, it also brings with it the need to ensure that the public-private key pair, used to encrypt messages and to sign digitally, belongs to the person or entity it claims to be owned by.

Public Key Infrastructure (PKI) is a set of tools, entities, and policies to provide authentication necessary for asymmetric algorithm implementations. Certificate Authorities (CAs) are one of the central components of PKI. They are the organs responsible for checking the subject’s identification data and signing a digital certificate, which attaches the subject’s identity to its public key. CAs have pairs of public-private keys, signing certificates with their private keys. Their public keys can be used to verify the certificate’s authenticity.

Certificate Authorities

Trust is built into the concept of CAs since, to trust their signatures, one must first trust their competence and ethical commitment to do the job of identity confirmation and proper internal management of its authentication processes. This same logic applies to government agencies that issue official identification documents to individuals and organizations.

To establish and enforce trust, CAs can be organized in one of three trust models:

Single CA: one single CA is responsible for signing all the certificates in an organization. A PKI with a single CA is easy to manage and adequate for small companies. But they are pretty vulnerable: if the CA is down, there are no alternates that can take its place, and if the CA’s private key is compromised, the entirety of its issued certificates lose their validity;
Trust Hierarchy: CAs are organized hierarchically, with a root CA at the top and subordinate CAs at lower levels. The root CA’s job is to ensure the validity of its subordinate CAs, verifying their keys with its key. In other words, a root certificate verifies the authenticity of intermediate certificates. This process can be organized like a chain named certificate chaining or chain of trust. It starts with the root CA providing a certificate to its immediate subordinate CA, which, in turn, verifies the next CA on the chain, continuing the process until the chain ends. This model is the most often adopted across different PKIs;

Illustration of the trust hierarchy model. Extracted from: https://www.manageengine.com/key-manager/information-center/certificate-authority-ca.html?pam-glossary.

Web of Trust (AKA Cross-Certification Model): a decentralized trust model where CAs establish a network of mutual trust relationships. While more organic and intuitive, this PKI model can be hard to manage. This problem may be addressed by adopting bridge CAs, which are CAs that act as nodes where trust can be centralized and distributed across the web.

To facilitate the CA’s job, organizations may implement Registration Authorities (RA), which collect and verify proof of identity and inform the resulting clearance to the CA.

Digital Certificates

Certificates result from attaching the subject’s public key to its verified identity. They follow the X.509 version 3 standard, which determines the information they must contain:

The adopted version of the X.509 standard;
Issuer’s identification;
Signature Algorithm Identifier, which includes details regarding the cryptographic algorithm the issuer used;
Signature value, which is the digital signature from the CA’s;
Subject’s identification;
Subject’s public key;
Certificate’s serial number;
Certificate’s validity period;
Optional information, known as extensions. They may be added for use by specific applications;

Example of a digital certificate and its components. Extracted from: https://spinnaker.io/docs/setup/other_config/security/authentication/x509/.

Certificates vary according to the degree of reliability and their intended function. The main categories are:

Domain Validation (DV): only the domain’s name is used as proof of identity, which a simple whois lookup can verify. Because of this, DVs are cheap and quickly issued yet have a low level of trustworthiness;
Organization Validation (OV): the organization’s identity is verified through an often manual lookup process on government databases. This more rigorous process can take days and is more expensive, but it provides a good level of trust, making OV certificates one of the most often adopted, especially by public-facing companies;
Extended Validation (EV): the organization’s business information is thoroughly verified. This process can take weeks and is the most expensive of the three types, but it provides an excellent trust level.

The certificate’s role defines additional categories:

Wildcard certificates: cover all of the organization’s subdomains (e.g., companyname.com, sales.companyname.com, and financial.companyname.com);
Subject Alternate Name (SAN) certificates: used when the organization has multiple domains (e.g., companyname.com, subsidiary1name.com, subsidiary2.com);
User certificates: validate an individual’s identity;
Machine certificates: similar to a user certificate but aimed at verifying a system’s identity;
Email certificates: provide confidentiality and authentication for messages sent. S/MIME is a known example;
Code signing certificates: dedicated to digitally signing software packages, ensuring legitimacy for the vendor;
Root signing certificates: these certificates are signed by an organization’s CA that is appropriately recognized by the community outside of the organization;
Self-signed certificates: implemented only for internal testing since they lack accepted trust levels.

Obtaining a Certificate

Acquiring a digital certificate starts with the applicant submitting a Certificate Signing Request (CSR). This document includes the subject’s public key and other essential data, such as the Fully Qualified Domain Name (FQDN), legal name, email, location (city, state, and country), and department name.

The applicant then signs the CSR with its private key and forwards it to the CA (or to the RA, which, in turn, forwards the CSR to the CA after their verification process). After checking the validity of the applicant’s identity, the CA signs the applicant’s certificate with its private key.

Certificates Validity

Digital certificates have a validity determined by a predefined period, often of 1 year. A certificate may also be invalidated before such time due to a CA’s private key compromise.

The certificate’s validity may be manually verified, but more practical methods exist. CA’s Certificate Revocation Lists (CRLs) aggregate information on invalid certificates, being periodically updated. Anyone interested in checking the certificate’s validity must download the CRL.

Online Certificate Status Protocol (OCSP) servers provide similar information but in a more dynamic way. The interested party contacts the CA’s OCSP servers for the certificate’s serial number. The server then sends a message indicating whether the certificate is valid.

With the ever-increasing internet traffic, OCSP servers can easily be overwhelmed with constant lookups. So, they send the web server a response with a time stamp (usually valid through 24 hours) and attach it to the certificate, eliminating the need to query OCSP servers frequently. The next time a user connects, it checks the certificate with the stapled OCSP response provided directly by the web server. This process is called certificate stapling.

Diagram illustrating the certificate stapling process. Extracted from Mike Chapple’s LinkedIn course.

To safeguard against certificate spoofing, CA’s may implement certificate pinning. In this procedure, the user is asked to pin the certificate, i.e., to expect no changes in the certificate for a long time. Any unauthorized changes must be reported.

Key Escrow and Digital Signatures

PKI provides the necessary infrastructure for the use of asymmetric encryption. Remember that public keys encrypt and private keys decrypt messages (confidentiality), while the latter digitally sign and the former verify the signature (authentication).

To provide a more agile digital signature process, some PKIs may incorporate what is known as key escrow. In this practice, a copy of the certificate subject’s private key remains in the CA’s possession, providing quick digital signature services.

There are reasonable objections against key escrow use in the PKI field, mainly because if the CA is compromised, numerous private keys will also be compromised. However, it can be helpful in closed corporate environments, where internally valid certificates and signatures may be used for communications between the organization’s entities. This corporate PKI can implement and enforce information security policies on its employees for an additional safeguard.