How SSL/TLS certificates work

What a certificate actually does

A TLS certificate does two jobs at once. It proves identity: the certificate states which domain it belongs to, and the private key that matches it is held only by the legitimate server, so a client connecting to that domain can be confident it's actually talking to the right server and not something impersonating it. And it enables encryption: the certificate carries the public key half of a key pair used to set up an encrypted connection, so everything exchanged afterwards is unreadable to anyone intercepting the traffic in between.

Both matter together. Encryption without identity verification would stop eavesdropping but not impersonation, since anyone could generate a key pair and encrypt a connection while still pretending to be someone else. The identity proof is what closes that gap.

The chain of trust

A certificate's claim to represent a given domain isn't taken on its own word. It's backed by a signature from a Certificate Authority (CA), an organisation that verified the certificate applicant controls that domain before signing. The CA's own certificate is, in turn, one that browsers and operating systems ship already trusting, as part of a built-in list of trusted root certificates. Often there's an intermediate certificate in between the root and your server's certificate, so the full chain runs from your certificate, up through one or more intermediates, to a root that's already trusted out of the box.

When a browser connects to a server, it checks this whole chain: is the server's certificate validly signed by the intermediate, is the intermediate validly signed by a trusted root, and does the domain in the certificate match the domain being visited. If every link holds, the connection proceeds without a warning. If any link is missing, expired, or doesn't match, the browser flags it.

Self-signed vs. CA-issued certificates

A self-signed certificate is one where the server signs its own certificate instead of a CA signing it. Technically, it still enables encryption exactly as well as a CA-issued one. What it doesn't provide is the identity proof: there's no independent party vouching that the certificate actually belongs to who it claims to, so nothing in the chain connects back to a trusted root. Browsers respond to that by warning the visitor rather than connecting silently.

That makes self-signed certificates a reasonable choice for internal tools, local development, or testing, situations where you already know and trust the server and the warning is just noise. It's not a reasonable choice for anything public-facing, where visitors have no independent way to know whether the server they've connected to is genuine, and being trained to click through a security warning is exactly the habit that makes phishing sites work.

Shorter certificate lifetimes and automated renewal

Certificate validity periods have been shrinking industry-wide for years, down from the multi-year certificates once common to periods measured in months. Shorter lifetimes limit how long a compromised or wrongly issued certificate stays valid before it has to be renewed, and force the renewal process to actually get exercised regularly rather than being something nobody's touched in years by the time it matters.

The practical consequence is that manually renewing a certificate every year or two, workable when lifetimes were long, doesn't scale to lifetimes measured in weeks or months. That's why automated issuance and renewal, using the ACME protocol that services like Let's Encrypt are built on, has become the default approach rather than an optional convenience. An ACME client on the server (or in front of it) requests a certificate, proves control of the domain automatically, and renews it again well before expiry, without anyone needing to remember to do it by hand.