What is PKI (Public Key Infrastructure)?
Updated: 3 days ago
PKI, or Public Key Infrastructure, is the framework used to issue, manage, validate and revoke digital certificates that bind identities to public keys. It matters because public-key cryptography alone does not tell you who a public key belongs to. PKI adds the trust system around those keys, allowing browsers, servers, VPNs, devices, email systems and software-signing processes to decide whether a presented identity should be trusted.
The key distinction is that PKI is not simply encryption. Encryption protects data, while PKI manages identities, certificates, trust relationships and certificate lifecycle. Protocols such as TLS use PKI certificates as part of authentication and secure session establishment.
What does PKI actually do?
A PKI creates a controlled way to answer a difficult question: when a system presents a public key, why should another system believe that key belongs to the claimed website, person, device or service? A digital certificate provides the binding, and a trusted Certificate Authority signs that certificate. The relying system then validates the certificate chain against a trust anchor it already accepts.
Issues certificates after an identity or control check.
Binds a public key to an identity or authorised subject.
Builds chains of trust from end-entity certificates through intermediate CAs to trusted roots.
Defines certificate lifetimes and renewal processes.
Supports revocation or status checking when trust should be withdrawn.
Protects the private keys used by CAs and end entities.
Provides policies, audit records and operational controls around certificate use.
Public keys, private keys and certificates
A public/private key pair is mathematically related. The public key can be distributed. The private key must remain secret. A digital certificate normally contains the subject identity, the subject public key, validity information, permitted uses, issuer information and the issuer's digital signature.
The certificate does not contain the subject's private key. That private key remains with the entity that proves possession of it. If the private key is compromised, the certificate can no longer provide the assurance originally intended and may need to be revoked or replaced.
The main components of a PKI
Root Certificate Authority (root CA): the top trust anchor in a hierarchy. In well-designed private PKI environments, the root CA is commonly kept offline and used sparingly.
Intermediate Certificate Authority: a CA signed by a root or another intermediate CA. It performs day-to-day certificate issuance without exposing the root key.
Registration Authority (RA): checks or approves the identity and entitlement of an entity requesting a certificate.
Digital certificate: a signed data structure that binds a public key to an identity and defines attributes such as validity and key usage.
Certificate repository: makes certificates and related information available where required.
Validation or status service: provides information used to determine whether a certificate remains acceptable, commonly through CRLs or OCSP.
Trust store: a collection of root certificates that a browser, operating system, device or application already trusts.
Private-key protection: secure storage and access controls, potentially including hardware security modules for high-value CA keys.
How PKI works step by step
An entity generates a public/private key pair. The private key should remain protected by the entity that will use it.
The entity creates a certificate signing request containing its public key and relevant identity information, together with proof of possession of the private key.
The registration and certificate authority process verifies that the request is authorised and that the claimed identity or control requirements are satisfied.
The Certificate Authority signs and issues a certificate that binds the approved identity to the public key.
When the certificate is presented, the relying system validates its signatures and certificate path back to a trusted root, along with validity, intended usage and other policy constraints.
Where applicable, the relying system also checks whether the certificate has been revoked or otherwise made invalid.
The authenticated public key can then be used by the relevant protocol, for example as part of TLS authentication, digital signatures or encrypted communication.
What is a certificate chain?
A certificate chain is the path from an end-entity certificate through one or more issuing CAs to a root certificate trusted by the receiving system. The root is trusted because it is already present in a trust store or has been deliberately installed by an administrator. The intermediate certificates delegate trust without requiring the root CA to sign every end-entity certificate directly.
This hierarchy limits exposure of the root key and allows separate intermediate CAs to be used for different technologies, organisations or risk boundaries.
Public PKI and private PKI
The Web PKI is the public trust system used by browsers and operating systems for internet-facing services. Public root CAs are included in browser and operating-system trust stores subject to the rules of those trust-store programmes and the CA/Browser ecosystem. A website certificate can therefore be validated by users who have never previously interacted with the site owner.
A private PKI is operated for a controlled environment such as an organisation. Its private root CA must be distributed to the devices and applications that should trust it. Private PKI is commonly used for internal services, enterprise WiFi, VPN authentication, device identity, mutual TLS and other managed environments.
How PKI is used with HTTPS and TLS
When you open an HTTPS website, the server presents a certificate during the TLS handshake. Your browser checks whether the certificate is valid for the requested hostname, whether the validity period is acceptable and whether it can build a valid path to a trusted root. Modern TLS then uses cryptographic key establishment to create session keys for the encrypted connection.
This is why a padlock is not evidence that a website is trustworthy in every broader sense. It primarily indicates that the browser established an encrypted connection to a service whose certificate passed the browser's authentication checks for that connection.
Certificate revocation, CRLs and OCSP
Certificates sometimes need to stop being trusted before their scheduled expiry. Reasons include private-key compromise, decommissioned devices, incorrect issuance or changes in authorisation. PKI therefore needs a mechanism for communicating certificate status.
CRL (Certificate Revocation List): a signed list of certificate serial numbers that have been revoked by a CA.
OCSP (Online Certificate Status Protocol): an online protocol used to obtain status information for a particular certificate.
Short certificate lifetimes: reduce the period for which an unwanted certificate remains useful and can reduce dependence on long-lived revocation information, although lifecycle automation becomes more important.
Where you encounter PKI
HTTPS websites and web services.
Remote-access and site-to-site VPN authentication.
Enterprise WiFi and 802.1X deployments.
Mutual TLS between services, APIs and devices.
S/MIME signed or encrypted email.
Code signing and software publisher verification.
Device certificates for managed endpoints, routers, appliances and IoT systems.
User or machine authentication in enterprise environments.
Document and digital-signature workflows.
PKI and VPNs
A VPN can use certificates to authenticate a server, client, device or user. In certificate-based deployments, PKI provides the mechanism for issuing those identities and withdrawing trust when a device or credential should no longer be accepted. PKI does not itself create the VPN tunnel. The VPN protocol uses the certificate-based identity as part of its authentication and key-establishment process.
PKI and multi-factor authentication
PKI and MFA solve different problems but can complement each other. A certificate may authenticate a managed device or cryptographic credential, while MFA requires evidence from more than one authentication factor. A certificate is not automatically 'multi-factor' merely because public-key cryptography is involved.
Why private-key protection matters
PKI trust ultimately depends on private keys being protected. If an end-entity private key is stolen, an attacker may be able to impersonate that entity until the certificate is revoked or expires. If an issuing CA key is compromised, the impact can be far wider because fraudulent certificates could potentially be issued under that CA's authority.
This is why high-assurance PKI designs separate duties, restrict access to CA systems, protect keys with strong controls, monitor issuance, automate renewal where appropriate and keep root CA keys offline or otherwise exceptionally well protected.
Common PKI misconceptions
PKI is not the same thing as encryption. It is the infrastructure for certificate-based trust and key management around public-key systems.
A certificate is not a private key. Certificates normally contain public keys and signatures, while private keys remain secret.
A certificate being valid does not prove that a website, person or organisation is safe in every sense. It proves specific identity or control assertions according to the certificate policy and validation process.
A root CA does not normally issue every website or device certificate directly. Intermediate CAs are commonly used.
Revocation is not the same as certificate expiry. Revocation withdraws trust before the normal end of the certificate's validity period.
Installing a private root CA changes what a device trusts. It should only be done when the operator and purpose are understood.
Techie Broadband practical trust-path check
A useful way to reason about PKI is to follow the trust path rather than focusing only on the certificate shown in a browser. For any certificate-based connection, ask these five questions:
What identity is the certificate claiming?
Which public key is bound to that identity?
Which CA signed the certificate, and can the chain be built to a root this device trusts?
Is the certificate currently valid for this purpose, hostname or key usage?
Has trust been withdrawn, or is there another policy reason the certificate should not be accepted?
This separates cryptographic validity from operational trust. A mathematically correct signature is only one part of the decision. The relying system also needs an acceptable trust anchor, identity match, validity period, usage constraints and certificate status.
PKI troubleshooting: why a certificate may not be trusted
Check the device date and time. A badly incorrect clock can make a valid certificate appear expired or not yet valid.
Check the hostname or identity. The certificate must be valid for the service or identity being contacted.
Inspect the certificate chain. A missing intermediate certificate can prevent a valid path from being built.
Check the trust store. A private CA certificate must be deliberately trusted by the relevant device or application.
Check the validity period and key usage or extended key usage constraints.
Check revocation or certificate-status behaviour where the application performs it.
Check whether TLS inspection, a corporate proxy or security appliance is substituting a locally issued certificate.
Test another device or network only after identifying whether the problem is local trust configuration or the remote service.
Does PKI depend on your broadband connection?
PKI is not a broadband access technology, and changing from FTTC to FTTP does not change how certificate trust fundamentally works. However, certificate validation and TLS handshakes occur across the network path, so DNS, connectivity, filtering, incorrect system time or inaccessible certificate-status services can affect whether a connection succeeds.
The distinction is similar to other end-to-end networking topics: IPv4 or IPv6 provide network-layer addressing, while PKI operates at a different layer to establish certificate-based trust for applications and services.
Frequently asked questions
Is PKI the same as SSL or TLS?
No. PKI is the trust and certificate-management infrastructure. TLS is a protocol that can use certificates and public-key cryptography for authentication and secure session establishment.
Does a digital certificate contain a private key?
No. A digital certificate contains a public key and related identity, issuer and validity information. The corresponding private key must remain secret and is stored separately.
What is the difference between a root CA and an intermediate CA?
A root CA is the top trust anchor. An intermediate CA is signed by a root or another intermediate CA and performs delegated certificate issuance. Using intermediates reduces routine exposure of the root key.
What happens when a certificate expires?
Once outside its validity period, a relying system should no longer accept the certificate as currently valid. The service or entity normally needs a replacement certificate before expiry to avoid disruption.
Can a certificate be revoked before it expires?
Yes. Revocation is used when trust needs to be withdrawn early, for example after private-key compromise, incorrect issuance or decommissioning.
Does PKI encrypt internet traffic?
Not by itself. PKI provides identities, certificates and trust relationships. Protocols such as TLS use those certificates and cryptographic key-establishment mechanisms to create encrypted sessions.
What is a trust store?
A trust store is the set of root certificates a browser, operating system, device or application accepts as trust anchors. Public Web PKI roots are distributed through major trust-store programmes, while private PKI roots must be deliberately deployed to the systems that should trust them.
Key takeaway
PKI is the infrastructure that turns public-key cryptography into an operational trust system. It connects identities to public keys through signed digital certificates, builds verifiable chains back to trusted roots, and manages the certificate lifecycle from issuance and renewal to validation and revocation. The security of the whole system depends not only on cryptographic algorithms, but also on identity checks, private-key protection, CA design, trust-store management and disciplined certificate operations.
Authoritative sources
UK National Cyber Security Centre: Design and build a privately hosted Public Key Infrastructure.
UK National Cyber Security Centre: Provisioning and managing certificates in the Web PKI.
NIST: Public Key Infrastructure glossary and certificate-authority definitions.
IETF RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
To explore the related technical concepts used in this PKI (Public Key Infrastructure) guide, visit our broadband terminology guide.
