Public key infrastructure: certificates, certificate authorities and TLS

Public-key cryptography solves one problem and creates another. You can encrypt to someone’s public key, but how do you know the key really belongs to your bank and not to someone pretending to be your bank? Public key infrastructure (PKI) is the system of certificates, authorities and rules that answers that question, billions of times a day.

A certificate binds a name to a key

A digital certificate is a small signed document. It says, in effect: “this public key belongs to the domain example.com, and this is valid until this date.” The format, X.509, is defined in RFC 5280. What makes the statement trustworthy is the signature at the bottom, made by a certificate authority (CA), an organization whose job is to check that whoever requests a certificate for a domain really controls it.

Your operating system and browser ship with a list of trusted root certificate authorities. A website’s certificate is usually signed by an intermediate authority, which is itself signed by a root. Your device checks that chain, link by link, back to a root it trusts, and checks that the certificate has not expired and covers the exact name you typed. If any link fails, you see a warning.

How certificates are issued today

Before a CA issues a certificate, the requester must prove control of the domain, for example by placing a specific file on the website or a specific record in its DNS. Let’s Encrypt, a non-profit authority, automated this process with the ACME protocol and made certificates free, which is a large part of why most web traffic is now encrypted. Certificates are also increasingly short-lived, so a stolen or mis-issued certificate stops working sooner.

TLS: where certificates meet encryption

Transport Layer Security (TLS), the “S” in HTTPS, uses the certificate during its opening handshake. In TLS 1.3, defined in RFC 8446, the client and the server agree on fresh keys using an elliptic-curve exchange, the server proves it holds the private key matching its certificate, and from then on the traffic is encrypted with a symmetric cipher. Because the keys are fresh for each session, recording traffic today and stealing the server’s long-term key later does not unlock past sessions, a property called forward secrecy. NIST’s TLS guidance, SP 800-52 Rev. 2, asks systems to support TLS 1.3 and to stop using old versions.

What the padlock does not promise

• It proves you are talking to the holder of the certificate for that exact name. It does not prove the site is honest. Phishing sites routinely use valid certificates for look-alike names.
• It protects the content in transit. It does not stop the site itself from collecting, selling or leaking your data once it arrives.
• The name of the site you visit usually still travels in the clear at the start of the handshake (the Server Name Indication), and DNS lookups may too, unless encrypted DNS and Encrypted Client Hello are in use.

The practical advice follows directly. Read the domain name, not just the padlock. Treat certificate warnings as a real stop sign, especially on public Wi-Fi, where a warning can mean someone is intercepting the connection. And never install a “profile” or root certificate because a website, email or captive portal asks you to: a root you add can be used to vouch for any site.

Keeping certificate authorities honest

The whole system depends on certificate authorities issuing certificates only to the real owner of a name. To catch mistakes and abuse, publicly trusted certificates are recorded in Certificate Transparency logs, append-only public logs described in RFC 6962. Browsers expect certificates to appear in these logs, and anyone can search them. That gives domain owners a practical defense: they can monitor the logs and be alerted when a certificate is issued for their name that they did not request. When a private key leaks or a certificate was issued wrongly, it can be revoked before its expiry date, which is one reason the industry has moved toward shorter certificate lifetimes: a certificate that expires soon limits how long a mistake can be exploited.