Learn PKI - History, Background & Why You Need It

#Introduction

In episode 0 you prepared your environment: foundational cryptography skills, OpenSSL, and a lab container. Now it is time to understand why this technology exists. PKI was not born overnight; it is the product of decades of cryptographic research, standardization, and a shift in how the internet is trusted.

This episode's roadmap: we trace the history of public key cryptography, the birth of X.509, the evolution of SSL toward TLS, the era of commercial CAs that was later transformed by Let's Encrypt, and the trends shaping today's PKI. By the end of this episode you will know what real-world problems PKI solves, and why without PKI digital identity could be forged so easily.

#The Roots of Public Key Cryptography

#Diffie-Hellman and RSA

The history of PKI begins with the breakthrough of public key cryptography in the 1970s. In 1976, Whitfield Diffie and Martin Hellman published a key exchange scheme that allows two parties to share a secret over a public channel without ever meeting. This concept was revolutionary because previously encryption always used a single shared secret key.

A year later, in 1977, Ron Rivest, Adi Shamir, and Leonard Adleman released RSA, the first public key algorithm capable of both encryption and digital signatures. RSA uses a mathematically related key pair: one may be published, the other must be kept secret. This was the seed of all modern PKI.

#The Birth of X.509

Distributed public keys raised a new question: how do you make sure a public key truly belongs to the party it claims to represent? In 1988, the standards community gave birth to X.509, a certificate format that wraps a public key together with its owner's identity and the issuer's signature. It is this X.509 certificate that has become the building block of PKI to this day.

X.509 defines a data structure containing the subject, issuer, validity period, and public key, all signed by the issuing authority. With this document, trust can be inherited: if you trust the issuer, you can trust whatever it signs.

#From SSL to TLS

#Protocol Evolution

SSL (Secure Sockets Layer) was developed by Netscape in the mid-1990s to secure web transactions. In 1999, the protocol was refined and renamed TLS by the IETF. Since then TLS has kept evolving: TLS 1.0 in 1999, TLS 1.1 in 2006, TLS 1.2 in 2008, up to TLS 1.3 in 2018, which is far faster and more secure. Old SSL versions are now considered obsolete and are no longer used.

The journey from 1999 to 2026 demonstrates one principle: security protocols never stop evolving. Every generation of TLS fixes the weaknesses of its predecessor, and the PKI layered on top of it adjusts its best practices accordingly.

#Let's Encrypt and the Era of Open Access

For two decades, digital certificates were only affordable for large organizations because they had to be purchased from commercial CAs at a hefty price. This left many small websites running without encryption entirely. Everything changed in 2016 when Let's Encrypt launched free certificates with full automation through the ACME protocol.

Let's Encrypt changed the economics of public PKI: certificates can now be obtained and renewed automatically without human intervention, making TLS encryption the default across the internet. The effect is still felt today; most sites you visit rely on this kind of automation. Free certificates do not mean trustless; Let's Encrypt remains a legitimate CA with a root trusted by all browsers.

#2020s Trends: PKI in the Modern Era

#mTLS and Zero Trust

Modern network architecture is shifting from a perimeter model toward zero trust: no network is automatically trusted, every connection must be verified. This is where mTLS (mutual TLS) shines, because the client and server both verify each other's certificates, authenticating communication in both directions.

Service mesh and Kubernetes platforms use mTLS to give every workload an identity. Every pod or service has a certificate managed automatically, often with a short lifetime (short-lived) of just a few hours or days. Short-lived certificates limit the impact of a leak: a stolen key is only useful while its certificate is still valid.

#The Post-Quantum Transition

The biggest threat on the horizon is the quantum computer, which in the future could crack RSA and EC in a matter of seconds. Aware of this, NIST released standards for quantum-resistant algorithms in 2024: FIPS 203 for ML-KEM (key encapsulation), FIPS 204 for ML-DSA (signatures), and FIPS 205 for SLH-DSA. This transition is known as the post-quantum transition.

For PKI, this transition means CA hierarchies, signature algorithms, and certificate sizes will change over the coming years. Modern servers have already begun supporting hybrid handshakes that combine classical and post-quantum algorithms simultaneously. This is not a distant future issue; it is an issue unfolding right now.

#PKI Timeline Summary

To make it easier to remember, here is the important timeline we discussed:

• 1976: Diffie-Hellman publishes public key exchange.
• 1977: RSA is born, the first practical public key algorithm.
• 1988: X.509 is standardized as the certificate format.
• 1994: Netscape develops SSL to secure the web.
• 1999: SSL is adopted and transformed into TLS 1.0.
• 2016: Let's Encrypt and ACME open up free automated certificates.
• 2018: TLS 1.3 is released, the highest standard used today.
• 2024: NIST releases FIPS 203, 204, and 205 for the post-quantum era.

This timeline shows a pattern: every trust crisis or technical limitation gives birth to the next evolution. The public PKI you see today is the accumulation of five decades of decisions.

#Seeing the PKI Chain in Action

All the discussion above can be observed directly. Connect to an HTTPS server with OpenSSL to see the certificate chain the server sends:

openssl s_client -connect example.com:443 -showcerts

The output displays the server certificate and the intermediate certificates that form the chain toward the root. Note that the root is usually not sent by the server because it is already in your trust store — a concept we will explore more deeply in episodes 2 and 5. The server name above is just an example; replace it with a domain you control, and also try openssl s_client -connect example.com:443 -tls1_3 to force the TLS 1.3 protocol.

For a more concise result, use the -brief option, which only shows the handshake result and the selected cipher. Also compare the handshake details between two protocol versions:

openssl s_client -connect example.com:443 -brief
openssl s_client -connect example.com:443 -tls1_2 -brief

Notice the difference in handshake length and cipher lists. This difference is what makes TLS 1.3 faster than its predecessor, and both still rely on certificates issued through a PKI chain.

#Problems Solved by PKI

#Digital Identity That Can Be Forged

Without PKI, anyone could claim any identity. An attacker in the middle of the network could impersonate the server you are connecting to — an attack known as MITM (man-in-the-middle). Without a way to verify identity, you would never know whether you are talking to the real server or an impostor.

PKI solves this problem with a trust chain: you trust the root CA, the root trusts the intermediate, and the intermediate issues server certificates. This chain of signatures makes identity claims verifiable mathematically.

#Authentication, Integrity, and Confidentiality

Through TLS, PKI provides three guarantees at once:

• Authentication: the client is sure the server (and in mTLS, the server is sure the client) is the party it should be.
• Confidentiality: the session keys from the handshake encrypt all data so no one else can read it.
• Integrity: any data modification is detected because it breaks the authenticity of the encrypted message.

Without these three, e-commerce, banking, and email transactions could not be secure. PKI is the trust engine behind the scenes.

#Managing Machine, User, and Service Identity

PKI is also used to manage identity beyond the web: certificates for machines (devices), users, and internal services. Each identity type has its own lifecycle: issued, renewed, and revoked when no longer needed. In the following episodes you will practice managing these identities directly through your own private CA.

#Closing

In episode 1 you understood the journey of PKI from the public key cryptography of the 1970s, the birth of X.509, the evolution of SSL toward TLS 1.3, the changes brought by Let's Encrypt, to the trends of mTLS zero trust and the post-quantum transition. You also know the real problems PKI solves: preventing fake identity and guaranteeing authentication, integrity, and confidentiality.

Key takeaways:

• Diffie-Hellman and RSA laid the foundation of public key cryptography in 1976 and 1977.
• X.509 was born in 1988 as the certificate format still in use today.
• TLS evolved from SSL and reached TLS 1.3 in 2018.
• Let's Encrypt and ACME have made certificates free and automatic since 2016.
• 2020s trends: mTLS zero trust, short-lived certificates, and the post-quantum transition FIPS 203, 204, 205.
• Without PKI, digital identity can be forged through MITM attacks.

In the next episode, episode 2, we will dissect core concepts and the main PKI architecture — X.509 certificate anatomy, the role of CSR, chain of trust, the Root CA to Sub CA hierarchy, and revocation mechanisms with CRL and OCSP. Prepare yourself, because the next episode will be very technical!