What a public key infrastructure is actually for

A public key infrastructure is the machinery that lets a party who has never met you decide, in a few milliseconds and without consulting anyone, that a specific public key belongs to a specific name. Every TLS handshake in your estate rests on that one decision. When it goes wrong the service does not degrade gracefully; the client refuses to connect at all, and it refuses before your application code runs.

The problem that predates certificates

Public key cryptography by itself solves confidentiality and proof of possession. It does not solve the question that actually matters operationally: which public key belongs to api.example.com? A key pair carries no name. Anyone can generate one and claim any identity for it.

Without an infrastructure, the only answer is out-of-band distribution. Somebody transfers the public key over a channel that is already trusted, and the receiver pins it. That is exactly what SSH does on first contact, and it works: for a handful of hosts and a handful of engineers, reading a fingerprint aloud over the phone is a perfectly sound protocol.

The trouble is arithmetic. If every one of 400 services must authenticate every other, the estate needs 79,800 distinct pairwise verifications, because 400 times 399 divided by two is 79,800. Add one service and you add 400 more. Replace a compromised key and every peer that pinned it must be touched. Nothing about that model is wrong; it simply does not fit in a maintenance window.

• Pinning does not scale with change, only with size. The cost is not the initial distribution, it is every rotation afterwards.
• Out-of-band verification decays quietly. Nobody notices that the fingerprint check stopped happening until the day it mattered.
• There is no shared vocabulary for revocation. Each peer decides independently, so a compromised key stays live somewhere.

A PKI replaces those 79,800 relationships with 400 certificates and one trust anchor per relying party. The verification work moves from humans, once per pair, to software, once per connection.

What the binding actually is

A certificate is a signed assertion. RFC 5280 defines it as three fields: a tbsCertificate structure holding everything being asserted, a signatureAlgorithm identifier, and the signatureValue itself. The tbsCertificate carries the serial number, the issuer name, the validity window, the subject name, the subjectPublicKeyInfo, and the version 3 extensions that do most of the real work.

The issuer computes a digest over the encoded tbsCertificate and signs that digest with its own private key. That is the whole mechanism. Everything a certificate proves flows from the fact that the signature covers those exact bytes.

CERT=app.crt
openssl x509 -in "$CERT" -noout -subject -issuer -serial -dates

subject=CN=app.lab.example
issuer=O=RunBook Academy Lab, CN=RunBook Lab Server Issuing CA
serial=21173B360D80F4A69A91164F1067F4F81A1B1B6E
notBefore=Aug 26 21:19:00 2026 GMT
notAfter=Nov 24 21:19:00 2026 GMT

Read that as a sentence. An issuer calling itself RunBook Lab Server Issuing CA asserts that between those two timestamps, the key inside this file belongs to the named subject, and it labels the assertion with a serial number so that the assertion can later be pointed at and withdrawn. Nothing in the file is secret. You can publish it, email it, and commit it, because it contains a public key and a signature over public data.

flowchart LR
    A["Subscriber generates a key pair"] --> B["CSR carries the public key"]
    B --> C["CA verifies control of the name"]
    C --> D["CA signs the tbsCertificate"]
    D --> E["Relying party checks the signature offline"]

The diagram is deliberately linear because the trust flows one way. The subscriber never sends its private key anywhere. The CA never learns it. The relying party at the far right performs its check without any network call to the CA, which is the entire point: the expensive verification happened once, at issuance, and every subsequent connection reuses it.

What the certificate does not claim

Most production misunderstandings come from over-reading the assertion. A CA that issued for a DNS name has confirmed one thing: at validation time, the applicant demonstrated control of that name. It has not confirmed that the operator is honest, that the service is patched, that the private key is still exclusively held, or that the organisation behind the name is the one you were thinking of.

The identity itself lives in the subjectAltName extension, not in the Common Name. RFC 9525 is explicit that the Common Name RDN must not be used to identify a service, and that other RDNs in the subject must not be used either. A verifier that still falls back to CN is verifying free-form text.

The three jobs a CA performs

It helps to see the authority as three separable functions, because different PKIs do a good job of some and quietly skip others.

The first is validating the claim. Before signing, the CA must establish that the applicant genuinely controls the name being requested. Publicly that means demonstrating control of a domain, through a challenge served over HTTP, a record placed in DNS, or a protocol exchange on port 443. Internally it can be an enrolment credential, a device attestation, or a lookup against a directory of approved hosts. This is the only step in the entire system where the CA can be deceived rather than defeated, which is why it is the step attackers work on.

The second is binding and constraining. The CA signs a structure it composed, not the one it was handed. That distinction shows up plainly when you read a request: OpenSSL labels its extension section Requested Extensions, and requested is the operative word. A CA applies its own profile, so the subject alternative name, the key usages and the validity window in the issued certificate are the CA’s decisions. An applicant asking for a certificate that may sign other certificates is simply refused.

The third is providing a means of withdrawal. That means publishing a revocation list or answering status queries, and keeping a record that maps a serial number back to who asked, when, and on what evidence. A CA that performs the first two functions and not the third is common, particularly in internal deployments, and it is a legitimate design provided it is a conscious one. What it means in practice is that the only way to end a certificate’s usefulness is to wait for it to expire, and that makes the validity window the sole containment control you have.

Where each piece of material lives

Tracing the material for a single issuance is the fastest way to see where the trust boundaries actually sit.

• Subscriber private key. Generated on the host that will serve the traffic, never transmitted, mode 0600 and owned by the service account. Every process that can read that file can impersonate the name.
• Certificate signing request. Contains the public key, a proposed subject, requested extensions, and a self-signature proving the applicant holds the matching private key. It is not confidential.
• Issued certificate and chain. Served in the handshake, stored alongside the key, safe to back up anywhere.
• CA private key. Held by the issuer, on different hardware, under different access control. Its blast radius is every name the CA is allowed to sign for.

Production discipline

1. Treat every certificate as a dated statement, not a status. It asserts something about the moment of issuance. Keep the issuance record, not just the file.
2. Generate keys where they will be used. A key that has been through a laptop, a ticket attachment or a chat message is already in more places than your inventory says.
3. Record the serial at issuance. It is the only handle you have if the certificate later has to be withdrawn, and it is far easier to capture then than to reconstruct during an incident.
4. Check identity in the SAN, never in the subject. Tooling that greps the Common Name will pass certificates that no conforming client will accept.

Cross-course references

• Linux for Production Sysadmins - Part LXXI (TLS) covers the file layout and permissions that certificate and key material take on a host, which is where the boundary described here is enforced.
• Kubernetes for Production Sysadmins - Part LXXVI (Certs) covers a cluster PKI that issues for internal service names, and shows the same binding applied to workloads rather than public sites.
• Observability for Production Sysadmins - Part XI (Blackbox) covers probing an endpoint from outside, which is how you find out whether the binding you issued is actually the one being served.

Quiz