openskills.info
Course catalog
Open Course

Public Key Infrastructure

Public key infrastructure, or PKI, is the system of authorities, policies, certificates, and trust stores that binds public keys to identities. It lets software decide which keys to trust for authentication, encryption, and digital signatures without arranging a separate secret with every party.

itIdentity, access, and cryptography

Don't Panic: Public Key Infrastructure

Public key infrastructure, or PKI, is the machinery that lets a public key arrive with a signed identity story rather than a note saying "trust me." Public-key cryptography gives you a public key and a private key. The public half is mathematically useful, but it does not tell you who owns it. PKI adds a certificate, a certification authority, policy, and a relying party that still has the final say. The paperwork is not decorative. It is the part that turns a key into a governed claim.

The central trick is a certificate, a signed record that binds a public key to a subject or other certified identity information. Before that binding, each party must find another way to decide whether a received key belongs to the intended server, person, device, or software publisher. A certification authority signs the record after an authorization process. This is a chain of introductions, which is a pleasant phrase until you remember that every introduction needs checking.

At the top sits a trust anchor, commonly represented by an offline root certification authority. It introduces intermediate authorities, and intermediates perform routine issuance for servers, users, devices, or other end entities. Keeping the root offline reduces its exposure. Separating intermediates also limits what one compromised issuer can affect. The root is therefore the widest trust boundary, not a magic certificate that wins arguments by being older and more self-signed.

Issuance begins with a key pair and a certificate signing request. The subject protects the private key and asks for a particular identity. A registration or authorization process checks that request against a profile. The issuing authority signs an approved certificate. Then comes the ambush hidden inside the word "issued": the certificate and its intermediate chain must reach every intended endpoint. A successful renewal in a CA record does not help if one load balancer keeps serving the expired predecessor.

A relying party performs path validation. It builds a path from the presented certificate toward a locally trusted anchor, verifies signatures and validity intervals, enforces CA constraints and key uses, matches the expected identity, and applies status and application policy. Passing one check does not excuse another. A valid chain for the wrong DNS name still fails, which is the system being fussy in precisely the useful way.

Certificates can need retirement before their normal expiry. A certificate revocation list publishes revoked serial numbers, while the Online Certificate Status Protocol reports status for one certificate. Shorter lifetimes reduce exposure only when renewal and deployment are dependable. The Automatic Certificate Management Environment protocol, called ACME, helps automate authorization, ordering, issuance, renewal, and revocation. It does not climb into every endpoint and install the result for you. Alas, no certificate protocol has yet been approved for that particular chore.

Start with the intro for the architecture and trust model. Use the slides for the issuance and validation flows. Keep the cheatsheet nearby when you need certificate fields, status mechanisms, failure signals, or an incident sequence. The practice reference and exercise build one local trust decision without changing a system trust store. Field Notes then covers the operational catches: distributed policy, repeated authorization, delivered chains, protected signing keys, and trust-store reach.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources