Introduction
Asymmetric cryptography solves key distribution, but it introduces a new problem: how do you know a given public key really belongs to the entity you think it does? Public Key Infrastructure (PKI) is the system of policies, roles, and technology that answers this question at internet scale, enabling trust between parties who have never directly met.
Cricket analogy: Asymmetric cryptography lets you send an encrypted message to a teammate without meeting first, but PKI is like verifying that the person claiming to be your captain on a new phone number really is him.
Explanation
A digital certificate binds a public key to an identity, such as a domain name or organization, and is issued by a trusted third party called a Certificate Authority (CA). Before issuing a certificate, a CA verifies that the requester genuinely controls the identity being certified (for example, proving control of a domain). The CA then digitally signs the certificate with its own private key, vouching for the binding between the identity and the public key. Anyone who trusts that CA can verify the certificate's signature using the CA's public key and thereby trust the certificate's contents. Because a single root CA managing every certificate on Earth directly would be operationally risky, PKI uses a hierarchical chain of trust: a highly protected root CA signs certificates for intermediate CAs, and those intermediate CAs sign end-entity certificates (such as a website's TLS certificate) issued to individual organizations. A certificate is trusted if you can follow this chain — end-entity certificate signed by an intermediate CA, intermediate CA certificate signed by the root CA — up to a root CA that is already trusted (root CAs are pre-installed as trust anchors in operating systems and browsers). This layering means the highly sensitive root CA key can be kept offline and rarely used, while intermediate CAs handle day-to-day certificate issuance, limiting the damage if an intermediate is ever compromised (it can be revoked without invalidating the entire root).
Cricket analogy: A digital certificate is like the BCCI vouching that a player's central contract genuinely belongs to them; a root CA is like the ICC itself, rarely invoked directly, delegating day-to-day accreditation to national boards (intermediate CAs) it trusts, so revoking one board doesn't invalidate the ICC's own authority.
Example
import ssl, socket
hostname = "example.com"
context = ssl.create_default_context()
with socket.create_connection((hostname, 443)) as sock:
with context.wrap_socket(sock, server_hostname=hostname) as ssock:
cert = ssock.getpeercert()
print("Subject:", cert.get("subject"))
print("Issuer:", cert.get("issuer"))
print("Valid until:", cert.get("notAfter"))
# ssl.create_default_context() automatically validates the chain of trust:
# end-entity cert -> intermediate CA -> trusted root CA in the OS/browser storeAnalysis
When Python connects over TLS with ssl.create_default_context(), it does not just trust whatever certificate the server presents. It walks the chain: it checks that the server's certificate was signed by an intermediate CA, and that the intermediate CA's certificate was in turn signed by a root CA already present in the trusted root store on the operating system. If any link in that chain is broken, unsigned, expired, or issued for the wrong hostname, the connection fails with a certificate validation error. This is the practical, everyday application of PKI: it is what allows a browser to trust a bank's website without any prior direct relationship, because both parties trust the same root CAs.
Cricket analogy: Verifying a TLS chain is like a match referee checking a player's ID card was issued by a national board, whose authority to issue was itself certified by the ICC, refusing entry if any link in that chain is broken or expired.
Key Takeaways
- A digital certificate binds a public key to a verified identity.
- A Certificate Authority (CA) verifies identity and signs certificates to vouch for that binding.
- The chain of trust runs from a trusted root CA through intermediate CAs to end-entity certificates.
- Root CA keys are kept highly protected; intermediates handle routine issuance and can be revoked independently.
Practice what you learned
1. What is the primary role of a Certificate Authority (CA)?
2. In the chain of trust, what typically signs an end-entity (e.g. website) certificate?
3. Why do PKI hierarchies use intermediate CAs instead of having the root CA sign every certificate directly?
4. Where are root CA certificates typically stored so that a device can trust them?
Was this page helpful?
You May Also Like
TLS/SSL Basics
Understand how the TLS handshake establishes a secure session, and why SSL is the deprecated predecessor to modern TLS.
Hashing and Digital Signatures
Understand one-way cryptographic hashing and how digital signatures use hashing plus private keys to prove integrity and authenticity.
Symmetric vs Asymmetric Encryption
Compare symmetric and asymmetric encryption and see how real systems like TLS combine both for speed and secure key exchange.