PKI (Public Key Infrastructure): Definition, How It Works, and Where You’ll See It

PKI (public key infrastructure) is the trust system that issues and validates digital certificates, binding a public key to an identity (a website, user, service, or device) so systems can authenticate each other and encrypt traffic reliably. You’ll see PKI behind TLS/HTTPS, mTLS, VPN authentication, enterprise Wi‑Fi (802.1X), S/MIME email, and code signing—and it’s best treated as ongoing certificate lifecycle management, not a one-time setup.

How PKI works

At a practical level, PKI answers two questions:

1) Who is this?
2) Can I trust them?

It does that by combining asymmetric cryptography (public/private keys) with a trust model (certificate authorities, validation rules, and revocation).

1) Keys: public vs. private

• A private key is secret and proves control/ownership. If someone steals it, they can impersonate that identity.
• A public key can be shared. Others use it to verify signatures or establish encrypted sessions.

In PKI, identities don’t typically exchange raw keys directly. They exchange certificates that contain the public key plus identity and policy metadata, all signed by a trusted party.

2) Certificates: “ID cards” for machines and people

A typical X.509 certificate includes:

• Subject (who the cert represents): e.g., CN=api.example.com or a user/device identity
• Subject Alternative Names (SANs): DNS names, IPs, email addresses, URIs
• Public key
• Validity period: Not Before / Not After
• Key usage / extended key usage (EKU): what it can be used for (server auth, client auth, code signing, etc.)
• Issuer (who signed it): a CA
• Signature: cryptographic proof the CA issued it

3) CAs and the chain of trust

A Certificate Authority (CA) is trusted to vouch for identities by signing certificates. Trust is usually structured as a chain:

• Root CA: the ultimate trust anchor (self-signed). Its certificate is distributed widely (OS/browser trust stores) or installed internally in enterprises.
• Intermediate CA: signed by the root; used to issue end-entity certificates. This limits blast radius—roots are kept offline more often, intermediates do day-to-day issuance.
• End-entity certificate: for a server, user, device, or service.

When a client (browser, API client, OS) sees a certificate, it builds and validates a chain from that certificate up to a trusted root.

4) Issuance: proving identity and getting a cert

The flow usually looks like:

1. A system generates a key pair (ideally on the endpoint or in an HSM/TPM).
2. It creates a CSR (Certificate Signing Request) containing the public key and identity info.
3. The CA or Registration Authority (RA) validates the request based on policy: - Public web PKI: domain control validation (and sometimes org validation). - Internal PKI: identity proofing via AD, device enrollment, ticketing approvals, etc.
4. The CA signs and returns the certificate.

5) Validation: what clients check

Before trusting a certificate, clients typically verify:

• The certificate chain ends at a trusted root.
• The certificate is within its validity period.
• The certificate is intended for the purpose (EKU/key usage matches).
• The identity matches: hostname in SAN matches the site/service name.
• The certificate is not revoked (depending on client behavior and network access to revocation endpoints).

6) Revocation: removing trust before expiry

If a private key is compromised, an employee leaves, or a cert was issued incorrectly, you need to revoke it. Common mechanisms:

• CRL (Certificate Revocation List): periodically published list of revoked serial numbers.
• OCSP (Online Certificate Status Protocol): real-time query to an OCSP responder.
• OCSP stapling (for TLS): the server “staples” a recent OCSP response to reduce client lookups.

In practice, revocation is imperfect (clients may “soft-fail” if they can’t reach OCSP/CRLs). That’s why short lifetimes and automation have become increasingly important.

7) Lifecycle management: the admin reality

PKI isn’t “set and forget.” Operational success depends on:

• Inventory: know where certificates live (load balancers, ingress controllers, servers, endpoints, SaaS).
• Automation: renew before expiration; rotate keys; deploy without downtime.
• Monitoring: alert on upcoming expiry, unexpected issuance, policy violations, and revocation failures.
• Protection: store private keys securely (HSM, TPM, encrypted key stores) and restrict access.

Technical notes: quick certificate inspection (practitioner-friendly)

Inspect a server’s TLS certificate (chain + SANs)

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Decode a certificate and review validity, SANs, issuer

openssl x509 -in cert.pem -noout -text | egrep -n "Subject:|Issuer:|Not Before|Not After|Subject Alternative Name"

Check a certificate’s expiration date

openssl x509 -in cert.pem -noout -enddate

Common log patterns you’ll see when PKI breaks

• TLS handshake failures due to trust/chain:
• x509: certificate signed by unknown authority
• unable to get local issuer certificate
• Name mismatch:
• certificate is valid for foo.example.com, not bar.example.com
• Expiration:
• certificate has expired
• NotAfter: <date> in monitoring outputs

When you’ll encounter PKI

PKI shows up anywhere you need strong identity + encrypted communications, especially at scale.

TLS/HTTPS (web apps, APIs, load balancers)

Every HTTPS connection relies on a server certificate. Internally, you’ll also see certificates on:

• Reverse proxies and CDNs
• API gateways
• Kubernetes ingress controllers and service meshes

What to do next: ensure you have automated renewal and can prove which hosts/services depend on each cert.

Mutual TLS (mTLS) for service-to-service authentication

With mTLS, both sides present certificates. This is common in:

• Zero Trust service communication
• Service mesh (east-west traffic)
• Partner integrations and B2B APIs

What to do next: define issuance policy (which workloads can get client certs), automate rotation, and validate EKUs.

Enterprise Wi‑Fi and network access (802.1X / EAP-TLS)

Organizations use certificates to authenticate devices/users to Wi‑Fi or wired networks without shared passwords.

What to do next: confirm device enrollment and certificate renewal workflows; expired client certs can trigger widespread access outages.

VPNs and remote access

Some VPNs use certificate auth (client certs) alone or combined with user credentials. If you’re evaluating consumer or SMB VPN options for travel or remote work, pick providers that clearly document their security posture and support modern authentication—NordVPN (Check NordVPN pricing →) and Surfshark (Try Proton VPN →) are common starting points for comparison.

What to do next: ensure revocation/disablement is tied to offboarding and device-compromise processes.

Email security (S/MIME)

S/MIME uses certificates to sign and encrypt email, proving sender identity and protecting content.

What to do next: plan for certificate distribution, key escrow (if required), and end-user support overhead.

Code signing and software supply chain

Code signing certificates verify software publisher identity and integrity. This is central to:

• CI/CD release pipelines
• Driver signing
• Internal script signing (PowerShell)

What to do next: protect signing keys (often with HSM), enforce signing in pipelines, and monitor for unauthorized signing.

Device identity (MDM, IoT, internal services)

Certificates are often used as device identities for:

• MDM enrollment and compliance
• IoT fleets
• Internal service authentication

What to do next: map how devices store keys (TPM/secure enclave vs. filesystem) and design for rotation at scale.

Technical notes: a simple PKI “health checklist”

1) Do we have a certificate inventory (including ephemeral/cloud/K8s)?
2) Are renewals automated (ACME or internal tooling), with safe rollout?
3) Do we monitor expiration at least 30/15/7 days out?
4) Are private keys hardware-protected where risk warrants it?
5) Can we revoke/replace certificates quickly after compromise?
6) Are trust stores consistent across endpoints, servers, and containers?

Practical next steps (optional tooling)

If your biggest PKI risk is operational (missed renewals, key reuse, weak secrets hygiene), you’ll usually get immediate wins by tightening credential storage, access controls, and endpoint security around key material:

• A password manager with strong admin controls (e.g., 1Password: Try 1Password →) can reduce credential sprawl around CA consoles, issuance portals, and break-glass accounts.
• Endpoint malware protection (e.g., Malwarebytes: Get Malwarebytes →) can help lower the chance that private keys or admin tokens are stolen from developer/admin machines.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.