Public-key cryptography solved key distribution and immediately created a new problem: you can send someone a public key over an open channel, and you cannot tell whose it is.

May 1978: the thesis

Loren Kohnfelder, an MIT undergraduate, submitted Towards a Practical Public Key Cryptosystem as a bachelor's thesis. It described digital certificates and what is now called public key infrastructure, and it introduced the terms certificate and certificate revocation list along with much of the conceptual apparatus still in use.

Two years after Diffie and Hellman published, an undergraduate produced the structure that would carry commerce on the internet for the next fifty years. It is worth stating plainly against the assumption that foundational work requires seniority: the piece that made public-key cryptography usable at scale was a bachelor's thesis. Kohnfelder went on to co-create the threat model and spent his later career at Microsoft and Google.

The problem he was solving is precise. Retrieving someone's public key from a directory and verifying it meant pausing communication mid-conversation, which he described as inconvenient. A certificate removes the pause: a trusted party signs the binding between a name and a key in advance, and the relying party checks a signature instead of making a query.

1988 to 1995: the format and the market

The ITU published in 1988, defining the certificate format. The internet profile arrived later - 2459 in 1999, RFC 5280 in 2008 - and every implementation detail that gives operators trouble descends from a specification designed inside the same OSI programme as the X.500 directory in the identity article.

In 1995 the first public certificate authority appeared, alongside SSLv2, and the browsers adopted a trust model that has never been redesigned since: a list of root authorities shipped with the software, any of which may vouch for any name.

The structural problem, stated without euphemism

That model has a property nobody would choose deliberately.

Any trusted authority can issue a certificate for any domain. Not just yours - anyone's. The security of your name therefore depends not on the authority you chose and pay, but on the weakest of the hundred-odd authorities your visitors' browsers happen to trust, in whatever jurisdictions those operate in.

The failure was not hypothetical. In 2011 attackers compromised the Dutch authority DigiNotar and issued rogue certificates for hundreds of sites including Google. Because DigiNotar was in the trusted root stores, clients could not tell they were being intercepted - which is exactly what the model guarantees when an issuer fails.

That is the sharpest version of a pattern this catalogue keeps finding: a system where trust is distributed but not verifiable fails silently, and the failure is invisible precisely to the people it harms.

2013 onward: the fix was not more trust

The response was not to trust the authorities harder. It was to make issuance observable.

Certificate Transparency, proposed by Google after DigiNotar, is a set of append-only public logs recording every certificate issued. It does not prevent a bad certificate; it makes one impossible to issue quietly. A domain owner can watch the logs and see certificates for their own name that they never requested.

That is a governance answer rather than a cryptographic one, and it sits alongside the competition in the encryption article as the second great example in this corpus of the same move: when you cannot make a party trustworthy, make its actions public.

The price collapse

Certificates cost hundreds of dollars a year and required manual work, which had a security consequence nobody framed as one: encryption was a budget line, so most of the web went unencrypted.

Automated issuance and free certificates removed that, and the effect was structural rather than incremental. The web went from mostly plaintext to mostly encrypted in a few years, and every consequence traced in the other articles here - inspection losing ground, detection moving to endpoints, network sensors reduced to metadata - follows from that one change in price and effort.

It also changed operational practice. Certificates that renew automatically can be short-lived, and short-lived certificates make revocation - the part of Kohnfelder's design that never worked well in practice - much less important. The industry did not fix revocation; it made expiry fast enough that revocation matters less.

Jobs and practices

This family produces no dedicated job title and an enormous amount of recurring pain, which is unusual: almost everyone in infrastructure deals with certificates, and almost nobody owns them.

The practices exist because of that gap. Inventory, because the certificate that expires is always the one nobody knew about. Expiry monitoring, which every organisation implements after its first outage rather than before. Chain validation, because a certificate that works in a browser and fails in a client library is usually a missing intermediate rather than a bad certificate. And private key handling, which is where this family meets the hardware security module - the key that signs is the asset, and the certificate is only its public face.

The most common serious outage in this family remains an expired certificate on something nobody had inventoried, which is a documentation failure wearing a cryptographic costume.

The companies

VeriSign defined the commercial market and passed its authority business to Symantec, whose certificates were eventually distrusted by browsers after issuance problems - the clearest demonstration that root trust is revocable and that the browser vendors, not the authorities, hold the actual power in this system.

Today it is DigiCert, Sectigo, GlobalSign and the cloud providers' own services, with Let's Encrypt issuing an enormous share of all public certificates for nothing. Underneath, the browser and operating system vendors run the root programmes, which makes them the real governors of internet trust without ever having been appointed to the role.

Where it goes

Lifetimes keep shrinking. Certificate validity has fallen from years to months and continues downward, which forces automation and eliminates the manual renewal that caused most outages.

Automation is becoming mandatory rather than optional. At the lifetimes now being adopted, no organisation can renew by hand, which quietly ends a whole category of operational practice.

Post-quantum migration lands here early. Certificates chain, so the algorithms in them must change before the traffic does, and the transition described in the quantum threat article reaches this family first.

And the founding structure is still there. Every improvement of the last fifteen years - transparency logs, pinning, shorter lifetimes, automated issuance - is a compensating control around a trust model designed when there were a handful of authorities and everyone knew each other. Nobody has replaced it, because replacing it would require every browser, every operating system and every server on earth to agree on something at once. The web runs on a 1978 idea and a 1995 arrangement, patched continuously, and the patches are the interesting part.

Sources