Certificate Management Explained

There is a padlock at the top of your browser right now. Click it and you will find a certificate, issued to a website by an organization you have probably never heard of, valid until a date a few weeks or months out. Your browser runs a check against that file before it renders more than 95% of the pages it loads.

That check is the reason you can type a password into a website without it being stolen. It rests on a few connected ideas: public key infrastructure, TLS, and certificate authorities. All of them exist to answer one question. When your computer talks to a machine it has never met before, how does it know who that machine really is?

When a browser loads a site over plain HTTP, everything traveling between you and the server is readable text. That traffic crosses hardware you do not control: coffee shop WiFi, your ISP, and a chain of networks you will never see. Anyone on that path can read what you send, and the password you type and the cookie that keeps you logged in are sitting in the open.

Those networks are not just observing the traffic, they are forwarding it. Anything on the path can also change what comes back, rewriting a download link or injecting content into the page. That is the first problem: someone in the middle reading or rewriting your traffic.

Suppose you fix that, and everything on the wire becomes unreadable to anyone in between. A second problem remains. You still do not know who is on the other end.

If an attacker can steer your connection to their server instead of your bank's, unreadable traffic does not save you. You would be holding a perfectly private conversation with a thief. A secure connection needs two separate things: encryption, so nobody in the middle can read or alter the traffic, and identity, so you know the other end before you say anything secret.

HTTPS delivers both. It is ordinary HTTP wrapped in TLS, which is where the S comes from. TLS scrambles what you send so nobody in the middle can read or change it. Proving who is on the other side is the certificate's job.

So how does a server prove its identity to a browser it has never talked to, over a wire anyone can read? The answer is a key pair.

A machine generates two keys at once, and they are a matched set. The public key is built to be handed to anyone who asks. The private key stays with whoever generated it and is never sent or shown to anyone. The two are matched exactly: this private key goes with this public key and no other public key in the world.

They are not passwords for each other. Handing your public key to a stranger gives them nothing, because there is no practical way to work backwards from a public key to the private one.

What the pair buys you is signatures. The private key can produce a signature on a piece of data, and anyone holding the matching public key can verify two things: that the real holder of that private key produced it, and that the data has not been altered. Nobody without the private key can fake it. A signature is a claim only one specific machine could have made, and anyone in the world can check it.

A certificate is a small file that ties a domain name to a public key. It is an ID card for a server. The name on the card is the domain, say `shop.example.com`. The photo is the server's public key. The hologram, the part that makes it hard to falsify, is a signature from whoever vouched for it.

Open a real certificate and every field that matters is there: the domain it covers, the server's public key, who issued it, the dates it is valid for, the issuer's signature, and what the certificate is allowed to be used for. Those certificate components are the same wherever certificates show up.

When your browser connects to a site, the server presents its certificate and the browser checks it the way a bouncer checks a license. Does the name match the site I asked for? Is it still inside its valid dates? Is the signature from an issuer I trust? Only then does the browser use the public key on that card to confirm it is really talking to that server, set up the encrypted session, and show you the padlock.

The issuer is called a certificate authority, or CA. A CA works like a passport office. Your government runs one, and other countries accept your passport not because they know you, but because they trust the office that issued it.

Your browser and operating system ship with a list of CAs they already trust, roughly 150 of them for the entire internet. That list is not just a set of names. Every CA has its own key pair, and what ships inside the browser is the CA's public key. A CA signs a certificate with its private key, and your browser is already holding the public key it needs to verify that signature.

Let's Encrypt is one of these. It is free, run by a nonprofit, and it signs certificates for a large share of the public web. When a CA on that list signs a certificate, every browser on earth accepts it. That is the entire trust model: a short list of passport offices baked into your software. Issuance from public CAs is almost entirely automated now, usually through ACME, the protocol Let's Encrypt introduced.

This also explains why signing your own certificate does not get you far on the public web. Nothing stops you from making one, and it is called a self-signed certificate, but it is like printing your own ID at home. The name and the photo might be honest, and there is no hologram anyone recognizes.

If browsers accepted homemade IDs, anyone could print one claiming to be your bank. So your browser shows a full-page warning instead.

Inside your own network the calculation changes. Names that a public CA will never sign for still need certificates, which is why teams run an internal CA of their own and distribute its root to the machines that need to trust it.

Real certificates carry one more layer, for a good reason. A CA signs with its own private key, and that is the most dangerous thing it owns. If that key ever leaked, every certificate the CA had signed would be worthless at once, with no quick fix, because the matching public key sits inside billions of browsers and operating systems that would each need an update.

So CAs do not use that key for daily work. They keep it offline, powered down in a vault, often inside a hardware security module that will not export it at all. It comes out for one job: signing a certificate for a second key pair. That second pair does the day-to-day signing on a machine actually connected to the internet. The offline one is the root CA, and the working one is the intermediate CA.

The result is that a real certificate arrives as a chain, and three key pairs are involved. Your server made a key pair, and the intermediate signed a certificate for its public key. The intermediate has a key pair of its own, and the root signed a certificate for that public key. The root is what sits in your browser's built-in list.

The same move happens twice: somebody with a private key vouching that a name and a public key belong together. Your browser walks the chain from the bottom up, checking one link at a time until it reaches a root it already trusts.

Nobody signs the root. It signs itself, which makes it a self-signed certificate too. The difference is that the root is already in your browser's trusted list, baked in ahead of time, so it does not need anyone above it to vouch for it. The chain has to stop somewhere, and the root is where it stops.

To recap: HTTPS is HTTP wrapped in TLS, TLS needs a certificate, a certificate ties a domain name to a public key, and it counts because a certificate authority signed it. Your browser trusts a short built-in list of authorities and walks the chain from the certificate in front of it up to one of them.

That is public key infrastructure, and it is not only a web thing. The same pieces show up anywhere two machines need to be sure who they are talking to. Services inside a Kubernetes cluster prove their identity to each other over mutual TLS, with something like cert-manager issuing and renewing the certificates. Devices on a factory network check in, often enrolling through a protocol like EST. Code signing uses the same primitives so your laptop can tell where a binary came from. The browser is just where most people meet the idea first.

One field on every certificate deserves its own conversation: the expiry date. Certificates are built to stop working after a few weeks or months, and that window keeps getting shorter. Renewing by hand stopped being realistic a while ago, which is why teams treat the certificate lifecycle as something to automate, and put expiry alerts in front of the certificates they already have.

Why lifetimes are shrinking, and what handles the renewal once they do, is a subject of its own. Our walkthrough of certificate lifecycle management picks up exactly there, covering discovery, issuance, renewal, and revocation across an entire fleet.

If you want the full picture of how this works in practice, the certificate management documentation covers it end to end.