PKI in plain words

A certificate is a signed note

A certificate says: this public key belongs to this name, from this date to that date, and I, the authority, vouch for it. That is all.¹ The name is usually a hostname like api.example.com. The dates are the validity window. The authority's signature is what makes anyone believe the note.

Keys come in pairs, and the private one is the whole secret

Every certificate has a public key, which is printed on the note, and a private key, which is not. The private key is what lets a server prove it is the name on the certificate. Whoever holds the private key is that name, as far as every client is concerned. Losing custody of a private key is the failure everything else exists to prevent.

An authority is a notary everyone agreed to trust

A certificate authority (CA) is the party that signs certificates. Browsers and operating systems ship with a list of authorities they trust: the trust store. Those are root authorities. In practice a root signs a small number of intermediate authorities, and the intermediates do the daily work of signing your certificates, the leaves. Root, intermediate, leaf: that is the chain, and a client verifies it link by link back to a root it already trusts.

Nothing stops you from running your own authority for the machines inside your walls. Clients that trust your root will trust what it signs. Publicly trusted authorities are the ones the whole internet's trust stores include, and they play by the CA/Browser Forum's rules, including the 47-day schedule.²

Proving you own the name

Before a public authority signs a certificate for a name, it checks that you control the name. This is domain-control validation. The two everyday challenges are simple: publish a specific token as a DNS record (dns-01), or serve it at a specific URL over HTTP (http-01).³ Pass the challenge and the authority issues. The proof has a shelf life, and that shelf life is shrinking to ten days by 2029.²

ACME is the protocol that does all of this without people

ACME is how a machine orders a certificate, receives a challenge, proves control, and downloads the result, then does it all again before expiry.³ Let's Encrypt made it famous and now serves more than 700 million websites with it.⁴ Clients like certbot, acme.sh, Caddy and cert-manager speak it. The authority end of the conversation can be a public one or your own, as long as it implements the protocol. trstctl implements the authority end, so the clients that talk to Let's Encrypt can enroll against it too.⁵

1. OrderThe client asks for a certificate for a name.
2. ChallengeThe authority hands back a token.
3. ProveThe client publishes it in DNS or over HTTP.
4. IssueThe authority checks, signs, returns the chain.
5. RenewBefore expiry, the loop runs again.

Expiry is a hard stop; revocation is the emergency brake

When the validity window closes, clients refuse the certificate. There is no grace. That is why a missed renewal is an outage, not a warning.

Revocation is for the other case: the certificate is still within its window but should no longer be trusted, usually because the private key leaked. The authority publishes the certificate's serial on a certificate revocation list (CRL),¹ or answers "revoked" through an online status protocol (OCSP).⁶ Clients check unevenly, and the industry is moving away from OCSP: Let's Encrypt switched off its OCSP responders in August 2025 and points clients at CRLs instead, partly because every OCSP lookup tells the authority which site you are visiting.⁷ That unevenness is part of why short lifetimes won: a stolen key that expires in 47 days is a much smaller problem than one that lasts a year.

Transparency: every public certificate is on the record

Publicly trusted certificates are recorded in public, append-only Certificate Transparency logs, and Chrome will not accept a certificate that is not.⁸ Anyone can search the logs.⁹ That means you can watch for certificates issued in your names that you did not ask for, which is exactly what a discovery tool should do on your behalf.

The same idea, other envelopes

Once you see a certificate as a signed note binding a key to a name, the rest of machine identity falls into place. SSH certificates are the same idea for logins: one SSH authority signs a short-lived note saying this user may log in as alice until five o'clock, and hosts stop collecting stale keys in authorized_keys.¹⁰ Workload identity (SPIFFE) is the same idea for software: a service proves what it is, then receives a short-lived credential.¹¹ Code signing is the same idea for artifacts. Different envelopes, one mechanism.

The trstctl glossary defines every term above from zero, and the ACME and DNS page walks the protocol end to end.