What Is PKI? Understanding Public Key Infrastructure and Digital Certificates

PKI (Public Key Infrastructure) is a system that enables authentication of websites, users, and devices through digital certificates. This technology underpins HTTPS, electronic signatures, enterprise access control systems, and any scenario where verifying a public key's ownership is essential for secure communication.

What Is PKI and Why Do We Need Public Key Infrastructure?

Public Key Infrastructure (PKI) is a framework of rules and technical components that binds a cryptographic public key to a specific person, organization, website, or device. The core challenge of asymmetric cryptography is that a public key alone does not prove its owner's identity. For instance, when a server sends a public key to a browser, the browser must verify that the key truly belongs to the intended website, not an attacker trying to intercept the connection.

PKI solves this problem through digital certificates. These certificates contain the public key and owner information, with their authenticity confirmed by a digital signature from a trusted certificate authority. This allows clients to verify not only the key itself but also the entity it was issued to.

PKI handles multiple functions: validating participant identities, securely distributing public keys, and establishing a unified trust mechanism between systems that do not inherently trust each other. For example, when a user visits a site via HTTPS, the browser checks the site's certificate for trustworthiness. Similar principles apply to digital document signing, corporate authentication, secure email, and device connections to internal services.

It's important to note that PKI is not an encryption technology itself, but a structure for managing trust around cryptographic keys-determining who issued them, who owns them, whether they're valid, and if they can be used for secure connections.

PKI Components: Keys, Certificates, and Certificate Authorities

Public and Private Keys

At the heart of PKI is asymmetric cryptography, which uses a key pair: one public and one private key. These are generated together but serve different purposes. The private key must remain confidential and is used to create digital signatures and perform certain cryptographic operations proving ownership. If an attacker gains access to the private key, its trustworthiness is compromised.

The public key, on the other hand, can be freely shared. It's used to verify signatures and enable encrypted data exchange. The problem is that a public key by itself doesn't prove its origin; users cannot automatically determine if a key belongs to a particular company, server, or person. This is where digital certificates come into play.

What Is a Digital Certificate?

A digital certificate links a public key to its owner. Think of it as an electronic ID card containing information about the key's owner and confirmation of its authenticity. Certificates typically include the public key, owner data, issuing certificate authority, serial number, validity period, and other technical details. Certificates are signed by the certificate authority, so any alteration breaks the digital signature.

The most widely used certificates follow the X.509 standard. These form the backbone of HTTPS and many enterprise security systems. Importantly, a certificate never contains the private key, which must always remain with the owner. The certificate only distributes the public portion and confirms its legitimacy.

What Is a Certificate Authority (CA)?

A Certificate Authority (CA) is a trusted entity within PKI responsible for issuing digital certificates and verifying the link between a public key and its owner. Before issuing a certificate, the CA performs a validation process, which may vary in complexity: confirming domain control might suffice in some cases, while others require verifying organizational or individual identities.

Once validated, the CA signs the certificate with its private key. Any user or software can then verify this signature using the CA's public key. In large PKI systems, there are often multiple CAs: root CAs and subordinate intermediate CAs. This layered design ensures the most critical root key is used sparingly, minimizing the risk if any component is compromised.

In summary, the key pair provides cryptographic foundations, the certificate binds the public key to its owner, and the CA verifies this link with its signature. Together, these elements create a robust trust model.

How PKI Works: From Key Generation to Certificate Verification

PKI operates through a sequence of trust checks. First, a cryptographic key pair is generated. Then the public key is tied to its owner via a certificate, and when a client connects, it checks the certificate's issuer and trustworthiness.

Key Pair Generation

The process starts with creating a public and private key. Typically, this happens directly on the server, device, or within a secure cryptographic module, so the private key never needs to be transmitted over a network. The private key is kept by the owner, while the public key becomes part of a Certificate Signing Request (CSR) sent to the CA, containing information needed for certificate issuance. The CA verifies the request-for example, by checking domain ownership for a TLS certificate.

Issuing the Digital Certificate

If validation succeeds, the CA creates a certificate containing the owner's public key and signs it with the CA's private key. This digital signature allows others to confirm the certificate's authenticity and that it hasn't been altered since issuance. The completed certificate is installed on the server or device, while the private key remains securely stored and is never distributed to users.

Certificates can be openly shared-their security relies not on secrecy but on the impossibility of undetectable modification without breaking the CA's digital signature.

How Clients Verify Certificates

When a browser connects to an HTTPS site, the server sends its certificate along with any required intermediate certificates. The browser checks the certificate's validity dates, domain name, digital signatures, and whether the certificate chain leads to a trusted root CA.

If all checks pass, the browser confirms the public key is legitimately bound to the website, and uses it to establish a secure connection. Note that PKI is just one part of HTTPS. The TLS protocol handles encryption negotiation, session key creation, and protects actual traffic. For a deeper dive, see TLS 1.3: How Modern HTTPS Became Faster and More Secure.

If the certificate is expired, issued for another domain, has an invalid signature, or the chain doesn't lead to a trusted CA, the browser warns the user. Thus, a technically reachable site may not be properly authenticated without a valid PKI link.

The same logic applies beyond the web: enterprise PKI can issue certificates to employees, laptops, servers, VPN gateways, and other devices for automatic identity verification within internal systems.

The Certificate Trust Chain: Why Browsers Trust Websites

The certificate trust chain is a fundamental PKI mechanism. It lets browsers determine whether to trust a site's certificate, even for first-time interactions. Trust is not established directly between the user and the site but through a linked sequence of certificates:

• Root Certificate Authority (Root CA)
• Intermediate Certificate Authority (Intermediate CA)
• Website's certificate

Each entity in this chain confirms the next via digital signatures.

Root Certificates

At the beginning of the chain lies the root certificate, belonging to the root CA and forming the base of trust. These certificates are pre-installed in operating systems' and browsers' trusted stores, so devices "know" which root CAs to trust. Root certificates are usually self-signed, meaning their signature is made with the same key they contain. Trust comes not from another signature, but from OS or browser vendors including them by default.

Root CA private keys are highly sensitive and are used as little as possible, stored in secure environments since their compromise threatens the entire PKI structure.

Intermediate Certificates

To avoid using the root key for everyday certificate issuance, intermediate CAs are created. The root CA signs the intermediate CA's certificate, which then can issue certificates to end entities like websites and servers. This design limits risk: if an intermediate CA is compromised, its certificate can be revoked without changing the root certificate on every device. Large infrastructures may have several intermediate levels between the root and site certificates.

How Trust Chains Are Verified

When a browser receives a site's certificate, it first checks the issuer's digital signature, then checks the issuer's certificate and next CA's signature, and so on, until it reaches a root certificate present in the local trust store. If all signatures are valid, certificates are within their validity period, and the chain ends with a trusted root CA, the website's certificate is accepted as trusted.

If any link cannot be verified-say, a required intermediate certificate is missing, or the certificate is from an untrusted CA-the browser may flag the connection as unsafe. Thus, browsers trust sites based on a chain of cryptographic proof culminating in a root certificate already trusted by the device.

Certificate Validity and Revocation

Every digital certificate has a limited validity period, reducing the risk of long-term key use and requiring regular renewal and data updates by owners. Certificates have start and end dates; once expired, they're considered invalid, regardless of signature integrity or trust chain status. An expired certificate doesn't necessarily mean a server was compromised-often it's simply a matter of failing to renew or install a new certificate on time.

Revocation is a different matter-it means a certificate should no longer be trusted before its scheduled expiration. Reasons include private key compromise, erroneous issuance, changes in owner data, or discontinuation of key usage.

How Certificate Revocation Works

The classic method is the Certificate Revocation List (CRL), where the CA publishes a list of certificates that are no longer valid. Clients can download the list and check if a certificate's serial number appears. The drawback is that these lists can grow large and require regular updates.

Another option is the Online Certificate Status Protocol (OCSP), where the client sends a query about a specific certificate and receives a real-time response from the CA's server. This is faster for individual checks but introduces dependency on OCSP server availability and may impact connection speed. Modern systems may optimize further, for example by having the server send a pre-fetched OCSP response.

Revoked vs. Expired Certificates

An expired certificate is simply past its validity window-the owner may have no security issue; the certificate just ran out. A revoked certificate is deliberately invalidated. The CA alerts PKI participants that it must no longer be trusted. This is crucial if a private key leaks-waiting for expiry is too slow, so prompt revocation prevents further trust in the compromised certificate.

Ultimately, PKI trust depends not only on valid signatures, but also on the certificate's current status and validity period-ensuring keys that are no longer secure are not trusted.

Conclusion

PKI brings together cryptographic key pairs, digital certificates, and certificate authorities into a cohesive trust system. The public key enables cryptographic operations, the certificate connects it to a specific owner, and the CA's signature confirms this bond. When verifying a certificate, clients check the validity period, owner name, digital signatures, and the trust chain up to a known root authority. If a certificate is revoked or expired, trust in it is withdrawn.

This structure lets millions of websites, servers, users, and devices communicate securely without needing to exchange secret keys in advance. That's why PKI remains a cornerstone of HTTPS, electronic signatures, enterprise authentication, and modern information security infrastructure.