TLS/SSL Protocol & Certificate Types Guide

What Actually Changed in TLS 1.3

TLS 1.3, finalized in 2018, cut the handshake down from two round trips to one in the common case, and removed an entire category of aging cryptographic options that had accumulated in TLS 1.2 over more than a decade of incremental updates. Static RSA key exchange, which let a client encrypt a session key using the server's long-term public key, is gone entirely — every TLS 1.3 handshake now uses ephemeral Diffie-Hellman key exchange, meaning a fresh, temporary key pair gets generated for every single connection.

That single change has a real practical consequence: TLS 1.3 provides forward secrecy by default, on every connection, with no configuration required. Forward secrecy means that even if a server's private key is later compromised, past recorded traffic still can't be decrypted, because the actual session keys used for each historical connection were never derived from that long-term key in the first place. Under TLS 1.2, forward secrecy was optional and depended on which cipher suite the server happened to be configured with — a detail that varied enormously across real-world deployments.

The One-Round-Trip Handshake, and What 0-RTT Actually Trades Away

In TLS 1.2, establishing a connection required the client and server to exchange messages across two full network round trips before any application data could flow — a real, measurable delay on high-latency connections. TLS 1.3 collapses this to one round trip in the standard case by having the client guess which key-exchange parameters the server will accept and send them upfront, rather than waiting for the server to specify them first.

TLS 1.3 also introduced an optional 0-RTT (zero round trip time) mode for resumed connections, letting a returning client send application data in its very first message, before the handshake even completes. This is a genuine performance win for reconnecting clients, but it comes with a real security trade-off: 0-RTT data isn't protected against replay attacks the way the rest of the handshake is, since a network attacker who captures that first message can resend it and have the server process it again. Because of this, 0-RTT is typically limited to genuinely replay-safe requests (like simple page loads) rather than anything that changes server-side state, such as a purchase or a password change.

Why Old Cipher Suites and Weak Algorithms Got Removed

TLS 1.3 doesn't just add new options on top of TLS 1.2's cipher suite list — it removes an entire generation of algorithms that had accumulated known weaknesses over the years: RC4, DES and 3DES, static RSA key exchange, and cipher suites using CBC-mode encryption combined with the specific MAC construction that enabled several padding-oracle attacks discovered against TLS 1.2 deployments. Rather than leaving these as legacy options a server could still be misconfigured into offering, TLS 1.3 simply doesn't support them at the protocol level.

The practical effect is that a server correctly configured for TLS 1.3 has a meaningfully smaller attack surface by default, without requiring an administrator to carefully audit and disable a long list of weak legacy options the way TLS 1.2 configuration always demanded. This is a large part of why current security guidance treats "does this server support TLS 1.3" as a genuinely useful quick signal of overall configuration quality, even before looking at anything else.

What a Wildcard Certificate Actually Covers

A wildcard certificate secures a domain and every direct subdomain at one specific level using a single certificate — *.example.com covers mail.example.com, shop.example.com, and any other single-level subdomain, all under one issued certificate. It does not cover the bare root domain (example.com itself, without a subdomain) unless the certificate is specifically issued to include both, nor does it cover a second-level subdomain like api.staging.example.com, since the wildcard only matches exactly one label depth.

The genuine appeal of a wildcard certificate is operational: one certificate to renew, monitor, and deploy, rather than a growing pile of individual certificates as an organization adds new subdomains over time. The trade-off is concentration of risk — a compromised wildcard private key exposes every subdomain it covers simultaneously, which is a meaningfully larger blast radius than a compromised single-domain certificate.

What a SAN (Multi-Domain) Certificate Actually Covers

A SAN certificate (Subject Alternative Name certificate, sometimes called a multi-domain or UCC certificate) lists a specific, explicit set of domain names — which can be completely unrelated to each other — all secured under one certificate. Unlike a wildcard, which covers an entire pattern of subdomains automatically, a SAN certificate covers exactly the domains named in it and nothing else; adding a new domain later means reissuing the certificate with an updated list, not something that happens automatically.

SAN certificates solve a genuinely different problem than wildcards do: consolidating several distinct, unrelated domains and root-level domains (not just subdomains of one parent) under a single certificate, which is common for organizations running several branded properties or handling multiple client domains through the same infrastructure. Most modern SSL certificates, including single-domain ones, technically include at least one SAN entry as a matter of current certificate authority practice — the distinction that matters in casual usage is really between a certificate covering one specific list of names versus one covering an entire wildcard subdomain pattern.

Wildcard vs SAN: Choosing the Right One

The two aren't mutually exclusive in practice — a wildcard certificate can itself include additional SAN entries beyond the wildcard pattern (covering the bare root domain alongside the subdomain wildcard, for instance), and checking exactly what a given certificate actually covers is something our SSL Checker shows directly rather than requiring you to guess from the certificate's name alone.

TLS 1.3's Middlebox Compatibility Mode

One quirk in TLS 1.3's design exists purely for practical deployment reasons rather than cryptographic ones: a "middlebox compatibility mode" that makes a TLS 1.3 handshake's early messages structurally resemble a TLS 1.2 handshake on the wire. This exists because a surprising number of network middleboxes — corporate firewalls, older load balancers, some ISP equipment — were built assuming TLS handshakes would always look a certain way, and would break or drop connections when they encountered a genuinely different-looking handshake format.

Rather than accepting years of broken connections through misbehaving middleboxes while the internet gradually replaced them, TLS 1.3 was designed to be superficially compatible enough to pass through unmodified, while still delivering all of its actual security and performance improvements underneath. It's a pragmatic compromise that prioritized real-world deployability over protocol elegance, and it's a large part of why TLS 1.3 adoption was able to happen as quickly and smoothly as it did.

Reading a Certificate's SAN List Yourself

Every certificate's Subject Alternative Name field is inspectable directly, without needing to trust marketing copy about what a certificate "should" cover. In a browser, clicking the padlock icon and viewing certificate details typically shows a "Subject Alt Names" or similarly labeled section listing every domain the certificate actually secures — the definitive answer to whether a given certificate is a wildcard, a SAN certificate covering specific names, or a straightforward single-domain certificate.

This matters because certificate names sold by different providers aren't always consistent or intuitive — what one vendor markets as a "multi-domain" certificate is functionally the same thing another calls a "SAN" or "UCC" certificate, and the only way to know exactly what you're actually getting is to look at the SAN field itself once issued, rather than relying on product naming alone.

Real Scenarios for Choosing a Certificate Type

A SaaS company gives every customer their own subdomain (customer1.app.com, customer2.app.com) and needs new subdomains covered automatically as customers sign up without manually reissuing a certificate each time. A wildcard certificate for *.app.com is the obvious fit — every new customer subdomain is covered the instant it's created.

An agency manages several completely separate client websites on shared infrastructure and wants to minimize the number of certificates to track and renew. A SAN certificate listing each client's specific domain consolidates them under one renewal cycle, without the blast-radius concentration a wildcard would create across unrelated clients.

A company runs a marketing site, a separate app subdomain, and an API subdomain, all under one root domain, and wants simplicity without reissuing certificates as new internal services get added. A wildcard covering *.company.com, combined with the bare root domain as an additional SAN entry, covers essentially everything with one certificate.

A security-conscious organization deliberately avoids wildcards specifically to limit the blast radius of a potential key compromise, issuing individual or narrowly-scoped SAN certificates per service instead, accepting the added renewal overhead as a reasonable trade-off for reduced concentrated risk.

How Certificate Type Interacts With TLS Version

The certificate type (wildcard, SAN, or single-domain) and the TLS protocol version are genuinely independent choices — any certificate type works over TLS 1.3, TLS 1.2, or (unfortunately, on some still-lagging servers) older versions. What actually matters for security is ensuring the server hosting any of these certificate types is configured to support TLS 1.3 and to disable TLS 1.0 and 1.1, which most major browsers now refuse to connect over entirely. A perfectly configured wildcard or SAN certificate sitting on a server still running TLS 1.1 provides meaningfully less real protection than the certificate type alone would suggest.

Checking What You Actually Have

Given how much certificate configuration varies in practice, the most reliable way to know exactly what protocol version and certificate type a given domain is using isn't to guess from documentation or the certificate's purchase page — it's to check the live server directly. Our SSL Checker shows the negotiated TLS version and the certificate's actual SAN list, including whether a wildcard entry is present, directly from the live connection rather than from what was originally configured or intended.

FAQ