Type “SSL certificate” into a browser’s address bar settings and you will still find the phrase everywhere, from hosting dashboards to email marketing banners promising a “free SSL” with every plan. The protocol those certificates actually negotiate, though, has not been SSL for over a decade. It is TLS, and the gap between what people say and what their servers run has become a real operational risk in 2026, not just a naming quibble. Certificate authorities, browser vendors, and the IETF have spent 25 years quietly replacing SSL with TLS, and the final legacy holdouts are now running out of road.

This comparison breaks down what SSL and TLS actually are, how each version performs, what the current adoption numbers say across three independent measurement sources, what certificates cost in 2026, and exactly how to migrate a server that is still exposing anything older than TLS 1.2. The short version: SSL is dead, TLS 1.2 is the compliance floor, and TLS 1.3 is what you should be running by default.

The confusion is understandable. Browsers still show a padlock icon that most people mentally file under “SSL,” security vendors still run “SSL scanning” tools, and a generation of developers learned the term before TLS existed at all. But the engineering reality underneath that padlock changed completely, several times over, and the versions still technically reachable in 2026 are a much shorter list than the marketing language suggests.

What SSL and TLS Actually Are

Secure Sockets Layer (SSL) was Netscape’s original protocol for encrypting traffic between a browser and a server, built in the mid-1990s. Transport Layer Security (TLS) is the Internet Engineering Task Force’s successor to SSL, standardized starting in 1999. They solve the same problem: authenticate a server, negotiate a shared encryption key, and protect data in transit. But they are not interchangeable protocols running side by side today. TLS replaced SSL entirely, the same way USB-C replaced the original USB connector. The “SSL certificate” label survived purely as marketing shorthand, carried over by certificate authorities who found it easier to keep a familiar term than to retrain an entire industry.

Every certificate sold today as an “SSL certificate” is in fact a TLS certificate, and every connection it secures runs the TLS handshake, never the SSL handshake. The UK’s National Cyber Security Centre is blunt about this: all versions of SSL are formally deprecated, and TLS 1.0 and TLS 1.1 should no longer be used either. That leaves two protocol versions worth discussing for a live production system in 2026: TLS 1.2, which remains the floor for compatibility, and TLS 1.3, which is the IETF-standardized version every new deployment should default to.

The Full Timeline: From SSL 2.0 to TLS 1.3

SSL 2.0 shipped publicly in 1995 and was riddled with design flaws serious enough that the IETF formally retired it 16 years later through RFC 6176. SSL 3.0 followed in 1996 and lasted longer, but the 2014 POODLE attack exposed a padding weakness severe enough that the IETF deprecated it outright in June 2015 via RFC 7568, which states plainly that SSL 3.0 “must not be used.”

TLS 1.0 arrived in 1999 as RFC 2246, authored by Christopher Allen and Tim Dierks, essentially an SSL 3.0 successor with cryptographic cleanup. TLS 1.1 came in 2006 as RFC 4346, mainly fixing how the protocol handled CBC-mode encryption. TLS 1.2 landed in 2008 as RFC 5246 and became the IETF’s recommended baseline that same year. TLS 1.3 shipped a decade later, in 2018, as RFC 8446, cutting the handshake down and removing a long list of legacy cipher options that had caused real-world vulnerabilities.

The cleanup accelerated in March 2021, when the IETF published RFC 8996, moving both TLS 1.0 and TLS 1.1 to Historic status and stating they must not be used, with no fallback negotiation permitted from any newer version. Apple, Google, Microsoft, and Mozilla had already coordinated a joint announcement back in October 2018 to disable TLS 1.0 and 1.1 in their browsers starting in 2020, giving the industry a two-year runway to migrate before the protocols stopped working for ordinary users.

SSL vs TLS: Version-by-Version Specs Comparison

The table below lines up every SSL and TLS version against the specs that actually matter for a production deployment: release year, governing standard, handshake cost, forward secrecy, and whether it is still safe to run in 2026.

ProtocolReleasedStandardHandshakeForward SecrecyKnown BreakPCI DSS OK?2026 Status
SSL 1.0Never shippedInternal Netscape draftN/ANoN/ANoNever existed in production
SSL 2.01995Deprecated by RFC 61762-RTTNoMultiple design flawsNoMust not be used
SSL 3.01996Deprecated by RFC 75682-RTTOptional, rarely usedPOODLE (2014)NoMust not be used
TLS 1.01999RFC 2246, Historic (RFC 8996)2-RTTOptionalBEAST (2011)NoMust not be used
TLS 1.12006RFC 4346, Historic (RFC 8996)2-RTTOptionalNo direct break, but weak ciphers allowedNoMust not be used
TLS 1.22008RFC 5246, still current2-RTTOptional, widely enabledNone when configured correctlyYes, minimum floorCompatibility baseline
TLS 1.32018RFC 8446, current standard1-RTTMandatoryNone knownYes, preferredDefault for new deployments
TLS 1.3 (0-RTT resumption)2018RFC 8446 section 2.30-RTT on repeat connectionsMandatory for new keysReplay risk on early dataYes, with careUsed selectively
QUIC + TLS 1.32021RFC 90011-RTT, transport-integratedMandatoryNone knownYesGrowing share via HTTP/3
Post-quantum hybrid TLS 1.32024-2026 rolloutIETF draft, ML-KEM + X255191-RTT, larger key shareMandatoryNone knownYesEarly production adoption

Ten rows, one conclusion: everything above TLS 1.2 on that table carries a “must not be used” status, and everything from TLS 1.2 up is actively maintained. There is no version of SSL left that belongs anywhere near a server in 2026.

Why SSL Is Completely Dead in 2026

Every major browser pulled SSL support years ago. Chrome, Firefox, Safari, and Edge all refuse SSL 3.0 connections by default, and have for close to a decade. There is no fallback path, no compatibility flag, no enterprise policy that quietly re-enables it for a legacy intranet app, at least not without actively fighting the browser’s own security team. If a server today only speaks SSL, it is unreachable from a modern browser, full stop.

What keeps the term alive is pure branding inertia. Certificate authorities still sell “SSL certificates” because customers search for that phrase, hosting panels still show an “SSL/TLS” toggle because splitting it into two separate settings confuses more users than it helps, and marketing copy still promises an “SSL-secured checkout” because the phrase remains familiar to shoppers. None of that changes the wire protocol. Every certificate issued by Let’s Encrypt, DigiCert, Sectigo, or Google Trust Services in 2026 negotiates TLS, never SSL, regardless of what the product page calls it.

The practical risk shows up when “SSL” survives as a literal configuration setting rather than a marketing word. Some load balancers, embedded devices, and older enterprise middleware still ship with an SSLv3 cipher option left enabled by default, usually for backward compatibility with hardware nobody has touched since 2012. Those are the systems that fail a PCI scan, get flagged by Qualys SSL Labs with a capped grade, or become the entry point in an audit finding. Finding and disabling that one leftover toggle is usually a 20-minute fix once you know where to look, covered in the migration section below.

Cipher Suites: What Changed Under the Hood

A cipher suite is the bundle of algorithms a protocol version actually negotiates: one for key exchange, one for bulk encryption, one for integrity checking. SSL and the early TLS versions supported a sprawling list of these bundles, many of them added for export-compliance reasons during the 1990s, when US regulations limited the key strength American companies could ship overseas. Those weakened export-grade ciphers, things like 40-bit RC4 and 512-bit RSA, were never meant to survive past the mid-1990s, yet traces of them lingered in server configurations for 20 more years and became the entry point for downgrade attacks such as FREAK and Logjam.

TLS 1.2 narrowed that list considerably but still allowed CBC-mode ciphers, static RSA key exchange, and SHA-1-based MACs if an administrator picked them, which is exactly how misconfigured servers kept failing SSL Labs scans well into the 2020s. TLS 1.3 took a different approach: instead of leaving the dangerous options in place and hoping operators avoid them, it deleted them from the specification entirely. RFC 8446 defines a short list of five cipher suites, all built on authenticated encryption with associated data (AEAD), covering AES-GCM and ChaCha20-Poly1305 combinations only. There is no legacy cipher suite to accidentally select in TLS 1.3, because none shipped with the protocol in the first place.

That design choice is part of why TLS 1.3 configuration is simpler to audit than TLS 1.2. A security review of a TLS 1.3-only endpoint mostly checks whether TLS 1.3 is actually enabled and whether older versions are disabled alongside it. A TLS 1.2 review has to walk through the full negotiated cipher list, since the protocol itself does not stop an administrator from offering something weak next to something strong.

TLS 1.2 vs TLS 1.3: What Actually Changed

TLS 1.2 to TLS 1.3 is the comparison that actually matters for anyone configuring a server today, since SSL is off the table entirely. TLS 1.3 cuts the full handshake from two round trips down to one, and supports 0-RTT resumption for repeat connections to the same server, which trims real latency on every new session, especially for clients on high-latency mobile or satellite links.

TLS 1.3 also removes an entire category of legacy cipher suites that caused real vulnerabilities in TLS 1.2 deployments: no more RC4, no more CBC-mode ciphers paired with the old MAC-then-encrypt construction that enabled Lucky 13, no more static RSA key exchange, no more renegotiation in the old vulnerable form. Every TLS 1.3 cipher suite provides forward secrecy by default, meaning a compromised server private key years from now cannot retroactively decrypt traffic captured today. In TLS 1.2, forward secrecy depends on the administrator picking an ephemeral Diffie-Hellman suite instead of static RSA, which is a configuration choice, not a guarantee.

The tradeoff is compatibility. TLS 1.2 still has to stay enabled on most public-facing services because a meaningful slice of enterprise clients, older mobile devices, and internal tooling has not finished the jump. That is why the practical 2026 configuration for most sites is TLS 1.2 and TLS 1.3 both enabled, with TLS 1.3 preferred and every version below 1.2 explicitly disabled.

Adoption Data: Comparing Three Measurement Sources

Protocol adoption numbers vary a lot depending on what is actually being measured: live traffic, top-site support, or raw domain scans. All three methods agree on the broad trend, even if the exact percentage shifts.

SourceMeasurement basisTLS 1.3 shareTLS 1.2 shareNotes
Cloudflare Radar / Mozilla telemetry (2026 analysis)Live HTTPS requests~72.4%~27.3%Traffic-weighted, skews toward high-volume sites
Qualys SSL PulseTop-site TLS support capability75.3% (June 2025 snapshot)Near-universal supportMeasures what a site can negotiate, not what it actually uses
Independent 2026 Internet measurement studyRaw domain scan, 16,779 domains52.41%15.70%Domain-count basis includes many small, rarely updated sites

The traffic-weighted figure from Cloudflare Radar and Mozilla telemetry is the most useful number for planning purposes, since it reflects what real users actually experience: roughly 72% of secure web traffic now runs TLS 1.3, with most of the rest on TLS 1.2. The domain-scan figure is lower mainly because it counts every registered domain equally, including small or abandoned sites that never updated their server stack. None of the three sources report a measurable SSL share left in live traffic. SSL has effectively dropped off the chart.

Handshake Speed and Real-World Performance

A full TLS 1.2 handshake takes two round trips between client and server before any application data moves: one to agree on cipher parameters, one to exchange keys and verify the certificate. TLS 1.3 collapses that to a single round trip by having the client guess the server’s preferred key-exchange group upfront and send its key share in the very first message. SSL 3.0 and the early TLS versions share roughly the same two-round-trip structure as TLS 1.2, just with weaker cryptography underneath.

Exact millisecond savings depend heavily on network distance, DNS resolution time, TCP versus QUIC transport, and whether session resumption kicks in, so a single universal number does not hold across different deployments. What is consistent is the direction: cutting a round trip removes one full network-latency cycle from every new connection, and that effect compounds on long-distance or high-latency links such as mobile networks or satellite internet, where a round trip can cost well over 100 milliseconds on its own. For a site serving a global audience, switching from TLS 1.2-only to TLS 1.3-preferred is one of the simplest latency wins available without touching application code.

The gap widens further once a browser reconnects to a server it already trusts. TLS 1.3’s session resumption lets a returning client skip the full handshake almost entirely and send encrypted application data in its very first flight of packets, the so-called 0-RTT mode. That shaves an entire round trip off every repeat visit, which matters disproportionately for sites with high return-visitor traffic, such as logged-in dashboards, SaaS products, and mobile apps that reconnect constantly in the background. TLS 1.2 supports session resumption too, through session tickets or session IDs, but it still needs at least one round trip to confirm the resumed session before data flows, so the practical speed advantage stays with TLS 1.3 even on warm connections.

PCI DSS and Compliance Requirements

Payment card security standards moved against legacy TLS years before most other industries caught up. The PCI Security Standards Council set June 30, 2018 as the deadline for payment processors and merchants to migrate off TLS 1.0 entirely, requiring TLS 1.1 or higher at minimum, with TLS 1.2 strongly recommended in practice. Any system handling cardholder data that still negotiates SSL or TLS 1.0 today is not merely outdated, it is out of compliance, and a failed PCI scan over legacy TLS is one of the more common findings auditors still report on older infrastructure.

Beyond payments, the UK National Cyber Security Centre, most national CERTs, and internal security teams across finance and healthcare now treat anything below TLS 1.2 as a hard fail in vulnerability scans. The practical compliance target for 2026 is straightforward: disable everything below TLS 1.2, keep TLS 1.2 available for compatibility, and set TLS 1.3 as the preferred negotiation on every server that handles sensitive data.

SSL/TLS Certificate Pricing in 2026

Certificate pricing has split into two clear tiers: free, automated domain-validated certificates built for short lifespans, and paid certificates aimed at organizations that want extended validation branding or dedicated support. Let’s Encrypt issues domain-validated certificates at no cost, using the ACME protocol for fully automated issuance and renewal, which is why it now underpins a large share of the web’s HTTPS deployment. Paid certificate authorities still charge a premium for manual validation, warranty coverage, and the visible organization details that come with OV and EV certificates.

ProviderCertificate typePriceValidationTypical use case
Let’s EncryptDomain Validated (DV)$0, freeAutomated via ACMEMost websites, APIs, internal services
DigiCertStandard DV$218 base priceAutomated or manualBusiness sites wanting a named CA
DigiCertOrganization Validated (OV)$399 base priceManual business verificationCorporate and SaaS domains
DigiCertExtended Validation (EV)$995 base priceFull legal entity verificationBanking, finance, high-trust checkout flows
DigiCertBasic TLS subscription$39/month, standard domainAutomatedTeams wanting predictable subscription billing

One pricing shift matters more than any single dollar figure here: certificate lifetimes themselves are shrinking fast. Under the CA/Browser Forum‘s ballot SC-081v3, the maximum public TLS certificate validity dropped from 398 days to 200 days on March 15, 2026, meaning every certificate issued right now is already living under the shorter window. That maximum falls again to 100 days on March 15, 2027, and down to just 47 days starting March 15, 2029. Manual certificate renewal, which was already tedious on a one-year cycle, becomes impractical at 47 days. That schedule is the single biggest reason ACME automation has gone from a nice-to-have to a near-requirement for anyone running TLS in production.

Real-World Examples That Forced the Shift

Six concrete events explain why SSL disappeared and TLS 1.3 became the default, rather than this being a purely theoretical upgrade path.

  • POODLE (2014): researchers demonstrated a practical padding-oracle attack against SSL 3.0, giving the IETF the concrete justification it needed to formally deprecate the protocol via RFC 7568 the following year.
  • The 2018 joint browser announcement: Apple, Google, Microsoft, and Mozilla coordinated a public commitment to disable TLS 1.0 and 1.1 starting in 2020, forcing every site owner who had been ignoring the issue to finally act on a fixed deadline.
  • PCI DSS’s June 2018 cutoff: the payment card industry forced an entire sector, from small e-commerce shops to major banks, off TLS 1.0 well before browsers made it unavoidable.
  • Let’s Encrypt’s free, automated model: by removing both cost and manual renewal friction, it made TLS the default rather than a purchase decision, which is the main reason encrypted-traffic share climbed as fast as it did over the past decade.
  • The CA/Browser Forum’s 2026 lifetime cut: dropping maximum certificate validity to 200 days is already pushing hosting providers and cloud platforms to bake ACME automation into default configurations rather than treating it as an advanced option.
  • Post-quantum hybrid TLS rollout: major browsers and CDNs have begun shipping ML-KEM combined with X25519 as a hybrid key-exchange group in TLS 1.3, getting ahead of a future where a sufficiently capable quantum computer could threaten classical key exchange.

Migrating to TLS 1.3: A Step-by-Step Guide

Moving a server off legacy protocols and onto a TLS 1.2 plus TLS 1.3 configuration is usually a configuration change, not a code change. Most of the actual engineering work goes into verification and rollout sequencing rather than the protocol switch itself, since flipping the wrong setting on a load balancer serving live traffic can lock out a slice of users before anyone notices. Here is the sequence that keeps the process low-risk.

  1. Run a scan against the live server with Qualys SSL Labs or a comparable tool to see exactly which protocol versions and cipher suites are currently enabled.
  2. Check server logs or load balancer metrics for any client still negotiating TLS 1.0 or 1.1, so you know the real compatibility blast radius before disabling anything.
  3. Update the web server or load balancer configuration to explicitly disable SSLv2, SSLv3, TLS 1.0, and TLS 1.1, leaving only TLS 1.2 and TLS 1.3 in the allowed list.
  4. Reorder cipher suite preference so TLS 1.3’s AEAD suites (AES-GCM, ChaCha20-Poly1305) are preferred over any remaining TLS 1.2 CBC-mode suites.
  5. Re-run the SSL Labs scan and confirm the grade improved with no unexpected client breakage in error logs.
  6. Move certificate issuance to an ACME client (Certbot, acme.sh, or your cloud provider’s managed TLS service) so renewals survive the shift to 200-day, and eventually 100-day and 47-day, certificate lifetimes.
  7. If you run a CDN or reverse proxy such as Cloudflare, Fastly, or an AWS/Azure/GCP load balancer, check its TLS policy setting separately, since edge termination can override your origin server’s configuration entirely.
  8. Schedule a recurring quarterly scan rather than treating this as a one-time project, since cipher suite guidance and deprecated versions continue to shift.
# Example nginx config restricting to TLS 1.2 and TLS 1.3 only
ssl_protocols TLS1.2 TLS1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;
ssl_session_tickets off;

Post-Quantum TLS: The Next Transition

While most of the industry is still finishing the move off TLS 1.0 and 1.1, the next transition is already underway inside TLS 1.3 itself. The classical key-exchange groups TLS 1.3 relies on today, mainly X25519 and NIST P-256 elliptic curve Diffie-Hellman, would be broken by a sufficiently powerful quantum computer running Shor’s algorithm. NIST finalized its first post-quantum standards, ML-DSA under FIPS 204 and SLH-DSA under FIPS 205, and its lattice-based key-encapsulation mechanism ML-KEM is now showing up in hybrid TLS 1.3 deployments.

The hybrid approach combines a classical group like X25519 with ML-KEM in the same key exchange, so a connection stays safe even if only one of the two algorithms eventually proves vulnerable. This is additive, not a protocol replacement: a server running post-quantum hybrid TLS is still speaking TLS 1.3 as defined by RFC 8446, just with a larger key share in the handshake. Track NIST’s post-quantum cryptography project page for the current list of finalized standards before planning a hybrid rollout, since the specific algorithm set is still being refined.

None of this touches SSL or TLS 1.2 at all, since those protocols were never slated to receive a post-quantum extension. Any organization still running legacy TLS is, by definition, also years away from any post-quantum protection, which is one more argument for finishing the TLS 1.3 migration first rather than treating quantum risk as a separate, parallel project. The practical order of operations is: get off everything below TLS 1.2, make TLS 1.3 the default, automate certificate renewal, and only then start piloting hybrid key exchange on the handful of connections where it matters most, such as long-term confidential data transfers.

Best Use Cases for Each Protocol Version

Which version to prioritize depends on the kind of system you are running. These five scenarios cover most real deployments.

  • Public-facing websites and APIs: enable TLS 1.2 and TLS 1.3 together, prefer 1.3, and drop everything older. This covers the overwhelming majority of browser and mobile app clients without breaking anyone.
  • Payment processing and PCI-scoped systems: TLS 1.2 is the enforced compliance floor, but there is no reason not to run TLS 1.3 as the preferred version on top of it, since it only improves your scan grade.
  • Internal enterprise tools with old client software: you may be stuck supporting TLS 1.2 longer than you would like, but TLS 1.0 and 1.1 should still be fully disabled. Budget time to replace the client, not the protocol floor.
  • Latency-sensitive global services, gaming, or real-time APIs: prioritize TLS 1.3 with 0-RTT resumption, and consider QUIC-based HTTP/3 for the connection-migration benefits on mobile networks.
  • Long-lived IoT or embedded devices: TLS 1.2 may still be necessary where hardware cannot be updated, but any new hardware design should target TLS 1.3 from day one, since the device will likely outlive the next protocol transition too.
  • High-security government, defense, or financial infrastructure planning five-plus years out: start evaluating post-quantum hybrid TLS 1.3 now, even if full deployment is still a year or two away.

Pros and Cons: SSL vs TLS 1.2 vs TLS 1.3

SSL has no pros left to list for production use in 2026. Its only remaining relevance is historical: understanding why TLS exists in the first place, and recognizing the term when it shows up in old documentation or marketing copy that has not been updated. Every modern browser refuses it outright, so there is no realistic scenario where enabling SSL solves a problem rather than creating one.

TLS 1.2’s advantage is pure compatibility reach: it is supported by nearly every client still in active use, including older enterprise software and some embedded systems. Its downside is a slower two-round-trip handshake and configuration-dependent forward secrecy that an administrator can accidentally disable by picking the wrong cipher suite.

TLS 1.3’s advantage is a faster, simpler, more secure-by-default handshake with mandatory forward secrecy and a pruned cipher suite list that removes most of the footguns present in TLS 1.2. Its only real downside is the small tail of legacy clients that cannot yet negotiate it, which is why most production servers still keep TLS 1.2 enabled alongside it rather than cutting over completely.

Common Misconceptions About SSL and TLS

A few persistent myths keep showing up in support tickets and procurement conversations, and they are worth clearing up directly. The first is that “SSL” and “TLS” describe two different current security levels, with SSL somehow being the cheaper or weaker option a budget host might still offer. In reality, no certificate authority sells a working SSL product anymore. Every “SSL” line item on an invoice issues a TLS certificate, full stop, so the word choice on the price list has no bearing on what protocol version actually runs.

The second myth is that upgrading to TLS 1.3 requires a new certificate. It does not. The same certificate, containing the same public key and the same chain of trust, works across TLS 1.2 and TLS 1.3 without any reissuance. What changes is purely the handshake and cipher negotiation between the existing certificate and the connecting client, which is a server configuration change, not a certificate change.

The third myth is that disabling TLS 1.0 and 1.1 will break access for a meaningful share of visitors. For almost every public website in 2026, that is no longer true. Every actively maintained browser and mobile OS has defaulted to TLS 1.2 or higher for years, and the clients that cannot negotiate at least TLS 1.2 are typically unsupported operating systems or abandoned devices that are already blocked by other modern web requirements, such as current TLS-dependent CDN features or HTTP/2 support. The honest exception is internal enterprise software talking to equally old internal servers, which is exactly the scenario covered in the use-case section above.

The Verdict: What to Run in 2026

The data points in one direction. SSL in any version holds a 0% safe-usage share: no supported browser will negotiate it, no compliance framework permits it, and no current measurement source shows a meaningful live-traffic footprint for it. TLS 1.2 remains the practical compatibility floor, still carrying somewhere around a quarter of secure web traffic by Cloudflare Radar and Mozilla’s 2026 telemetry. TLS 1.3 is the clear majority choice, sitting at roughly 72% of live HTTPS traffic across the most traffic-representative measurement available, and climbing further once QUIC-based HTTP/3 connections are counted alongside it.

For a new deployment in October 2026, the configuration to ship is simple: TLS 1.2 and TLS 1.3 enabled, everything older explicitly disabled, ACME-based certificate automation in place ahead of the certificate lifetime drop to 100 days in 2027, and a plan on the roadmap for post-quantum hybrid key exchange. Treat “SSL” purely as a legacy label at this point. The protocol doing the actual work is TLS, and as of 2026 it has effectively finished replacing its predecessor across the live web.

Frequently Asked Questions

Is SSL still used anywhere today?

No supported browser or major client will negotiate any version of SSL in 2026. Any server still configured to accept SSL connections is misconfigured, not intentionally running a legacy mode, and should be treated as a security finding rather than a compatibility choice.

What is the actual difference between SSL and TLS?

TLS is the IETF’s successor to SSL, first published as TLS 1.0 in 1999. They solve the same problem, encrypting a connection between client and server, but TLS fixed a long list of cryptographic weaknesses present in SSL and has continued evolving through TLS 1.3, while SSL development stopped entirely after SSL 3.0.

Is an “SSL certificate” the same thing as a TLS certificate?

Yes. Certificate authorities still market them as “SSL certificates” for familiarity, but the certificate itself is used to negotiate a TLS connection. There is no separate SSL-specific certificate product sold by any major CA today.

Which TLS version should I run in 2026?

Enable TLS 1.2 and TLS 1.3 together, with TLS 1.3 preferred, and disable everything older including TLS 1.0 and 1.1. That configuration covers the large majority of clients while giving you the performance and security benefits of TLS 1.3 wherever it is supported.

Do any major browsers still support TLS 1.0 or TLS 1.1?

Apple, Google, Microsoft, and Mozilla jointly committed in 2018 to disabling TLS 1.0 and 1.1 starting in 2020, and the IETF formally deprecated both versions in RFC 8996 in March 2021. Current browser releases do not negotiate either version by default.

How do I check which TLS version my website is actually using?

Run your domain through Qualys SSL Labs’ server test, which reports every protocol version and cipher suite your server currently accepts, along with an overall letter grade. Browser developer tools also show the negotiated TLS version for any individual connection under the security tab.

Why are TLS certificate lifetimes getting shorter?

The CA/Browser Forum’s ballot SC-081v3 is cutting the maximum public certificate validity from 398 days down to 200 days as of March 2026, then to 100 days in 2027 and 47 days in 2029. Shorter lifetimes limit how long a compromised or misissued certificate stays trusted, and push the entire industry toward automated renewal instead of manual yearly purchases.

Will TLS need to change again for quantum computers?

Yes, though not by replacing TLS 1.3 itself. The industry is adding post-quantum hybrid key exchange, combining classical algorithms like X25519 with NIST’s ML-KEM, directly into the existing TLS 1.3 handshake. Early hybrid deployments are already live on some major browsers and CDNs as of 2026.

Does switching to TLS 1.3 require buying a new certificate?

No. The protocol version a server negotiates and the certificate it presents are separate things. An existing TLS certificate works unchanged on TLS 1.2 or TLS 1.3, so enabling TLS 1.3 is purely a server or load-balancer configuration change rather than a certificate purchase or reissuance.