If you want the deep dive on the protocol-vs-certificate distinction, that is its own page: SSL vs TLS. This one is the primer.

01What “SSL” actually means in 2026

SSL stands for Secure Sockets Layer. The protocol was designed by Netscape in the mid-1990s. SSL 1.0 never shipped, SSL 2.0 shipped and was broken, SSL 3.0 shipped and was eventually broken too. The IETF formally deprecated SSL 3.0 in 2015 in RFC 7568. No serious public-facing server has accepted an SSL 3.0 connection in years.

What replaced it is TLS, Transport Layer Security. TLS 1.0 was effectively SSL 3.1 with the name changed; TLS 1.1, 1.2, and 1.3 followed. TLS 1.3 was published in 2018 in RFC 8446 and is what your server should actually be negotiating in 2026. TLS 1.0 and 1.1 are deprecated. TLS 1.2 is the floor for a lot of compliance regimes. TLS 1.3 is the default.

The vocabulary settled into a compromise. The protocol is called TLS. The certificate is called an “SSL certificate” in nine out of ten conversations, including conversations with the people who sell them. That is fine. It is the same artefact either way. The point of saying any of this out loud is so you are not surprised when a colleague says “SSL” and means TLS, or when a CA portal asks for your “SSL CSR” and the resulting cert ends up in a TLS handshake. Nobody is getting confused; the names just lag the engineering.

02What the protocol does

TLS does three things at once on every connection it sets up:

• Encryption. Once the handshake is finished, the bytes flowing in either direction are unreadable to any party that does not hold the session keys. That is the part people mean when they say “SSL means it is encrypted.”
• Integrity. The protocol authenticates each record so an attacker on the wire cannot flip a bit, drop a chunk, or splice in their own bytes without the other side noticing. Encryption alone would not give you this; you need the MAC layer that comes with the cipher suite.
• Identity. The server presents a certificate, the client validates that the certificate was issued by a CA the client trusts and that it was issued for the hostname the client is connecting to. This is the part the certificate is for.

People conflate these three jobs all the time. “We need SSL” usually means “we need encryption,” but the certificate part is what most of the practical hassle is about. Encryption and integrity are mostly handled by the cipher suite the two sides agree on; identity is the part where you, the operator, have to do work.

03What the certificate does (and doesn’t do)

An SSL certificate, narrowly, is an X.509 document that binds a public key to one or more hostnames. The CA that issued it has signed that binding with its own private key, and the chain of signatures eventually leads to a root certificate that the client already trusts. When the client validates the cert during a handshake, it is checking that the chain holds and that the hostname it is connecting to appears in the cert’s Subject Alternative Names.

That is it. That is the entire claim the cert is making.

It is worth stating out loud what the cert is not asserting:

• It does not say the site is “secure” in the colloquial sense. A site running a wide-open SQL injection on a beautifully validated TLS 1.3 connection still has a wide-open SQL injection. Operators sometimes get a security audit back that says “your TLS is fine” and read that as “your site is fine.” Those are different statements.
• It does not validate the business behind the site, at least not at the DV tier. A domain-validated cert proves you control the DNS for the hostname. It says nothing about whether the company on the other end of the form is real, solvent, or who they say they are. OV and EV go further, but DV is what most public sites use today.
• It does not protect against client-side compromise. If the user is on a machine running a TLS-intercepting proxy, or has installed a CA in their own trust store that is owned by an attacker, the handshake validates against that attacker’s cert and the encryption is essentially decorative. That is a known and accepted limitation.
• It does not prove the cert is “good” today. The cert can be revoked between issuance and the moment you connect. OCSP and CRL exist to communicate revocation, but enforcement on the client side is patchy. This is one of the running open problems in the ecosystem.

Knowing what the cert does not assert is more useful in practice than memorising what it does. Most of the time the cert is fine and the work happens around it.

04The handshake, in four sentences

You do not need to read RFC 8446 to use TLS, but the four-sentence version of the TLS 1.3 handshake is worth carrying around in your head:

1. The client sends a ClientHello with the cipher suites and groups it supports plus a key share.
2. The server picks a cipher and group, sends its certificate plus its own key share, and signs the handshake transcript with the cert’s private key.
3. Both sides derive the session keys from the shared secret implied by the two key shares; the client validates the cert against its trust store and against the hostname.
4. From that point onward every record is encrypted and authenticated under the session keys.

That is the whole protocol exchange in TLS 1.3. The previous versions had more round-trips and more state; 1.3 collapsed it down to one round trip in the common case and zero if the two sides have talked before. If you are debugging a handshake and the version on the wire is anything other than TLS 1.3, ask why.

05DV, OV, EV – the three validation tiers

SSL certificates come in three validation levels, in increasing order of how much the CA checked before issuing:

• DV (Domain Validated). The CA confirms you control the domain, usually by serving a token at a well-known URL or by adding a TXT record. Issuance can be fully automated and done in seconds. This is what Let’s Encrypt and most paid CAs default to today, and it covers the overwhelming majority of public web traffic.
• OV (Organisation Validated). The CA confirms domain control plus the existence of the organisation behind the request, typically against a public business registry. Takes hours to days. Slightly more expensive. Used by businesses that want their company name to appear in the cert details, mostly for B2B contexts where the customer might inspect the cert.
• EV (Extended Validation). The CA does the OV check plus a stricter identity-of-applicant check, with documented procedures defined by the CA/B Forum. The original selling point was the “green address bar” with the company name, which Chrome dropped in 2019 and Firefox dropped in 2020. EV still exists, still costs more, and still appears in the cert if you click through to inspect it, but the visual differentiation in the browser is gone.

The practical decision in 2026: DV unless a customer or compliance regime specifically requires OV or EV. The chain-of-trust mechanics are the same at all three tiers. The differentiation is paperwork at issuance time, not protocol behaviour. There is more on the EV side specifically in the EV buyer’s guide once that page is up.

06What you actually deploy in 2026

For a typical web property, the SSL setup looks like this:

• One DV cert issued via ACME, either from Let’s Encrypt for free or from a paid CA that supports the ACME protocol. The CA signs your CSR; you install the resulting certificate plus the CA’s intermediate as a bundle on your server.
• Automated renewal, either via your hosting provider, a sidecar agent like certbot, or your reverse proxy’s built-in ACME client (caddy, traefik, nginx-with-acme.sh). Manual renewal is no longer a viable workflow given where validity periods are heading.
• TLS 1.3 enabled, TLS 1.0 and 1.1 disabled, TLS 1.2 enabled as the floor for older clients. Cipher suite ordering is largely a solved problem; whatever your TLS library defaults to in 2026 is fine.
• OCSP stapling enabled if your reverse proxy supports it. Most do.

The thing that has changed since 2020 is the validity-period schedule. The CA/B Forum’s baseline requirements are tightening max TLS validity through 2027 in stages, on a path to 47 days. By the time the 47-day cap lands, the only sensible workflow is ACME-based automation. If your shop still has anyone running through a CA portal once a year and downloading PEMs by hand, that habit has to go before 2027 makes it impossible.

07Where chain-of-trust enters

The leaf certificate on your server is signed by an intermediate CA. The intermediate is signed by a root CA. The root sits in the client’s trust store, which the OS or browser ships pre-populated. When the client validates your cert, it walks back up that chain until it reaches a root it already trusts.

The catch: your server has to send the intermediate alongside the leaf. If you only serve the bare leaf, clients that have not seen this intermediate before will fail validation, even though everything else is correct. This is the single most common SSL deployment failure I see, and it is covered in detail in the chain of trust page.

For the purposes of this primer: when your CA tells you to install “fullchain.pem” instead of just “cert.pem”, do that. The handshake will quietly start working on more clients.

08Why we still call it “SSL”

You will see “SSL” used three ways in casual conversation, and you should not correct any of them:

1. “SSL certificate” to mean an X.509 cert used in a TLS handshake. Universal in the industry.
2. “SSL” as a verb-adjective meaning “encrypted in transit.” A non-technical colleague says “we need to SSL the API” and they mean “TLS in front of the endpoint.” Fine.
3. “SSL” used technically by people who actually mean SSL 3.0 and earlier. This is rare in 2026 outside of legacy-system documentation, and when it does come up the context makes it obvious.

The brand name stuck. Vendor portals say “SSL,” CA marketing pages say “SSL,” compliance auditors say “SSL.” The protocol is TLS. Both can be true at once. The only place the distinction actually matters is when you are configuring the protocol directly (TLS 1.3 vs TLS 1.2 vs SSL 3.0 in your nginx config) – and at that point you are talking to software, not people, and the software uses the precise names anyway.

09Working notes for 2026

Three things every team running their own TLS termination should be doing in 2026:

• Audit your cert inventory. Spreadsheet, Vault, whatever. Every public-facing hostname, the CA that issued the cert, the expiration date, who owns renewal. The horror story is always the cert that nobody owned, that quietly expired on a Saturday morning, and took down a checkout flow until someone noticed. Inventory first; everything else follows.
• Automate renewal via ACME. If you cannot, get on a CA that supports ACME. Most paid CAs now do. Manual renewal is fine in 2026, marginally tolerable in 2027 with the 47-day cap, and operationally impossible after that.
• Watch the trust-store reach of your client population, especially for B2B and embedded fleets. The intermediate that worked last year may have rotated. The cross-sign that papered over an old Android may have lapsed. Roots themselves are stable for 20-30 years; intermediates rotate every 5-10. The Mozilla CA inclusion list is the closest thing to a definitive trust-store reference for the public web; for embedded fleets you will need to ask the CA which roots cover your specific clients.

Reference material if you want to read primary sources: RFC 8446 for TLS 1.3, RFC 8555 for ACME, Let’s Encrypt’s chain-of-trust page for a worked example of how a real CA structures its hierarchy, and the Certificate Transparency project page for the public-log machinery your cert is going to land in regardless of who issues it.