TL;DR: SSL, TLS, and HTTPS are three distinct but related concepts. SSL is a deprecated encryption protocol from the 1990s. TLS is its modern, secure replacement, now in version 1.3. HTTPS is HTTP traffic secured using TLS (or historically SSL). When your provider sells you an “SSL certificate,” it is actually a TLS certificate. All three work as a chain: TLS encrypts the connection, the certificate authenticates the identity, and HTTPS is the result.
Most website owners know they need HTTPS. Fewer understand what that actually means, or why the certificate their provider sold them is labeled “SSL” when the protocol running beneath it is TLS. That confusion is not just semantic. It causes real mistakes: outdated server configurations, wrong certificate types, and security postures that look right on the surface while hiding gaps underneath.
SSL, TLS, and HTTPS are not synonyms. They are three layers of one system, and each layer has a specific job. Understanding the difference determines whether your site is configured correctly, which certificate you actually need, and how the changes rolling out in 2026 affect your renewal schedule.
The Security Layer Chain: How SSL, TLS, and HTTPS Work as a System
The most useful way to understand SSL, TLS, and HTTPS is not as three separate technologies but as three layers in a single security system. Each layer has one job, and they depend on each other. Mixing up the terms is not just imprecise: it is the root cause of the misconfigured servers, incorrect certificate purchases, and false trust assumptions that show up consistently in security audits.
In practice, SSL is the legacy protocol that started the system. TLS is the current protocol that replaced it. HTTPS is what the user sees when TLS is doing its job correctly. The “SSL certificate” your hosting provider sells you is a TLS certificate. The industry kept the SSL name for brand recognition and search familiarity, not because SSL is still in use.
What is SSL, and why is it no longer used?
SSL (Secure Sockets Layer): An encryption protocol created by Netscape in 1995 to secure communication between browsers and web servers over unsecured networks.
SSL was the first widely adopted solution to a concrete problem: how do you send a credit card number over the internet without someone in the middle reading it? Netscape released SSL 2.0 publicly in 1995, followed by SSL 3.0 in 1996. SSL 3.0 became the backbone of early e-commerce security.
The problem is that SSL has known, unfixable vulnerabilities. SSL 3.0 was deprecated by the IETF in June 2015 following the POODLE attack, which demonstrated that an attacker could force a browser to fall back to SSL 3.0 and then exploit its cipher-block chaining weaknesses to decrypt content. All versions of SSL are now considered cryptographically insecure. According to W3Techs data (January 2026), only 1.1% of surveyed sites still support SSL 2.0 or SSL 3.0, meaning the modern web has effectively abandoned the protocol entirely.
In practice, from conducting SSL/TLS configuration audits, the servers that still show SSL 3.0 support are almost never intentionally configured that way. They are forgotten load balancers, legacy endpoints, or inherited infrastructure that nobody has reviewed in years. Audits catch these, but routine scans from non-technical site owners do not.
What is TLS, and what version should your website use in 2026?
TLS (Transport Layer Security): The IETF-standardized successor to SSL, designed to secure network communications through encryption, authentication, and integrity verification. Current version: TLS 1.3, standardized under RFC 8446 in August 2018.
TLS 1.0 was released in 1999. It was essentially SSL 3.1 under a new name, a fact acknowledged in the original RFC 2246, which states that “the differences between this protocol and SSL 3.0 are not dramatic.” The renaming from SSL to TLS was partly a political decision: the IETF wanted to signal that the standard was no longer exclusively Netscape’s, and Microsoft needed a face-saving alternative to endorsing a competitor’s protocol outright.
TLS evolved significantly through four versions. TLS 1.0 and 1.1 were formally deprecated in RFC 8996 in March 2021. TLS 1.2 remains widely used but carries legacy algorithm support that creates unnecessary attack surface. TLS 1.3 eliminates all deprecated cryptographic primitives, mandates forward secrecy on every connection, and reduces the handshake from two round trips to one, making it measurably faster.
According to Qualys SSL Pulse data from June 2025, 75.3% of the top surveyed websites now support TLS 1.3. For any new server configuration in 2026, TLS 1.3 should be the minimum, with TLS 1.2 permitted only as a fallback for legacy clients. TLS 1.0 and 1.1 should be disabled entirely.
What is HTTPS, and what does it actually guarantee?
HTTPS (Hypertext Transfer Protocol Secure): HTTP traffic transmitted over a TLS-encrypted connection. HTTPS does not name a separate protocol: it is HTTP plus TLS. The “S” stands for secure.
When a user loads an HTTPS page, three things happen simultaneously. First, TLS encrypts the data in transit so that anyone intercepting the connection sees only ciphertext. Second, the TLS certificate authenticates the server’s identity, confirming the user is communicating with the legitimate domain owner and not an impersonator. Third, a message authentication code verifies that the data has not been modified in transit.
HTTPS does not guarantee the trustworthiness of the website itself. This is where many site owners and, more importantly, many users make a dangerous assumption. According to APWG data cited in the SSL Dragon 2026 SSL statistics report (January 2026), over 90% of phishing sites displayed a valid padlock in 2023. The padlock confirms the connection is encrypted. It says nothing about whether the entity on the other side of that encrypted connection is legitimate. Google confirmed in 2014 that HTTPS functions as a ranking signal, and Chrome has progressively flagged HTTP sites as “Not Secure” since 2018.
SSL vs. TLS vs. HTTPS: A Side-by-Side Comparison
The following table maps each term to its function, current status, and practical meaning for a website owner in 2026. This is the comparison the top 10 SERP articles do not provide: a decision-ready reference rather than a sequential list of definitions.
| Term | What It Is | Status in 2026 |
| SSL | An encryption protocol created by Netscape (1995). Handles authentication and encrypted communication. | Fully deprecated. SSL 2.0 and 3.0 are cryptographically broken. No version is safe for production use. |
| TLS | The IETF successor to SSL (1999-present). Current version: TLS 1.3 (RFC 8446, August 2018). Encrypts, authenticates, and verifies data integrity. | Active standard. TLS 1.3 is the recommended version. TLS 1.0 and 1.1 are deprecated. TLS 1.2 is supported but aging. |
| HTTPS | HTTP traffic secured over a TLS connection. The “S” denotes a TLS-encrypted tunnel between browser and server. | Mandatory baseline. 92.6% of the top 100,000 websites use HTTPS by default (W3Techs, January 2026). Chrome 154 will enable HTTPS-First mode by default in October 2026. |
| “SSL Certificate” | Industry shorthand for a TLS certificate. The name persists due to legacy convention, not technical accuracy. | Sold universally as “SSL certificates” by all major CAs, including DigiCert and Sectigo, but all issue TLS certificates in practice. |
The Padlock Paradox: Why HTTPS Is No Longer a Trust Signal
This is the section no competitor article in the current top 10 includes, and it is arguably the most important practical insight for 2026.
For years, the padlock icon in a browser’s address bar was treated as a shorthand for “this website is safe.” That assumption is now wrong. The padlock confirms only one thing: the connection between your browser and the server is encrypted. It says nothing about whether the website you are connected to is legitimate, run by a trustworthy entity, or free from malicious intent.
The consequence of this distinction is visible in phishing data. Over 90% of phishing sites used a valid SSL/TLS certificate as of 2023, according to APWG figures cited in the SSL Dragon 2026 report (January 2026). These sites obtained domain-validated (DV) certificates, which require only proof of domain ownership, not identity verification. A phishing site for “paypa1-secure.com” can obtain a DV certificate, display the padlock, and deliver malware over a fully encrypted HTTPS connection.
What does the padlock actually tell you about certificate validation levels?
The certificate type determines what has been verified, and this distinction matters for any site handling sensitive user data. Three validation levels exist:
- Domain Validation (DV): Confirms only that the certificate applicant controls the domain. Issued within minutes. No identity verification. Adequate for blogs and informational sites. Used by most phishing sites.
- Organization Validation (OV): Confirms domain control plus verifies the legal existence of the organization. The certificate includes the company name. Appropriate for business websites and login pages.
- Extended Validation (EV): The highest verification tier. Requires strict vetting of legal identity, physical presence, and operational status. Historically showed the company name in a green address bar, though most modern browsers have reduced this visual distinction.
In practice, from certificate audit work with e-commerce clients, DV certificates are appropriate for content sites and tools where data collection is minimal. Any site with a checkout flow, a login, or a form collecting personal data should be running OV at minimum. The certificate cost difference between DV and OV is negligible compared to the risk exposure.
How the TLS Handshake Works: What Happens Before You See a Web Page
Every HTTPS connection begins with a TLS handshake. Understanding this process clarifies why TLS version matters for both security and performance, and why misconfigured servers create vulnerability even on sites with valid certificates.
How does the TLS 1.3 handshake differ from TLS 1.2?
The TLS handshake is the negotiation phase that happens before any application data is exchanged. The client and server agree on which TLS version to use, which cipher suite will govern the encryption, and exchange the cryptographic material needed to derive session keys.
In TLS 1.2, this process requires two full round trips between client and server before data can flow. TLS 1.3 reduces this to one round trip through a redesigned handshake that removes the separate key exchange and cipher negotiation steps. IETF measurement data shows that TLS 1.3 connections are twice as likely to complete their handshakes in under 100 milliseconds compared to TLS 1.2 connections. For sites where Core Web Vitals metrics affect search rankings, this difference is measurable, particularly on high-latency mobile connections.
TLS 1.3 also removes support for cipher suites and key exchange mechanisms that have been exploited in attacks against TLS 1.2: RSA key exchange (vulnerable to future decryption if the server private key is ever compromised), CBC-mode ciphers (implicated in BEAST and POODLE attacks), and weak hash functions including MD5 and SHA-1. In TLS 1.3, forward secrecy is not optional. Every session key is ephemeral, meaning a compromised server private key cannot be used to decrypt past traffic.
Why Your Provider Sells “SSL Certificates” That Run on TLS
The naming disconnect between SSL and TLS is not an accident. Understanding why it persists clarifies a practical buying decision: what you are actually purchasing when you buy an “SSL certificate.”
When Netscape handed control of the SSL protocol to the IETF in 1999, the renamed protocol (TLS 1.0) was technically described in the original RFC as “not dramatically different” from SSL 3.0. The name change was partly political, and the SSL brand had accumulated years of recognition from consumers and developers alike. Certificate authorities kept selling products under the SSL name because that is what customers were searching for.
Today, no certificate authority issues an SSL certificate in the technical sense. Every “SSL certificate” sold by DigiCert, Sectigo, Let’s Encrypt, or any other CA is a TLS certificate. The certificate itself is a data file containing the public key and identity information of the domain owner. It is used during the TLS handshake to authenticate the server. The certificate does not dictate which version of TLS the server uses: that is a server configuration decision.
Why does it matter that certificates and protocol versions are separate?
This separation has a practical consequence that trips up many site owners. A server can have a valid, fully trusted TLS certificate and still be configured to accept connections using TLS 1.0 or 1.1, which are deprecated and vulnerable. The certificate does not enforce the protocol version. According to Qualys SSL Pulse data from June 2025, 28.7% of the top 134,380 surveyed websites failed to follow best practices for SSL/TLS implementation, despite having valid certificates. The most common failures were incomplete certificate chains and continued support for weak cipher suites.
The correct security posture requires two things to be right simultaneously: a valid certificate from a trusted CA, and a server configuration that disables deprecated TLS versions and weak cipher suites. Having only one of the two is insufficient.
2026 Certificate Changes Every Site Owner Needs to Know
The SSL/TLS certificate landscape is undergoing its most significant structural changes since Google mandated HTTPS in 2018. Two changes in 2026 directly affect how site owners manage certificates.
What is the new SSL/TLS certificate validity period in 2026?
For most of the past decade, SSL/TLS certificates could be valid for up to two years, and before 2020, for up to three years. In 2026, the CA/B Forum has approved a reduction to 199 days maximum validity. DigiCert implemented this change on February 20, 2026, and Sectigo followed on March 8, 2026, per Security Boulevard (February 2026). The CA/B Forum has also approved further reductions: by March 2029, the maximum validity period will be just 47 days.
The reason behind shorter certificate lifespans is straightforward: a shorter validity window limits the damage if a certificate’s private key is compromised. If an attacker obtains a certificate private key, they can impersonate the domain until the certificate expires. A 47-day window means any such impersonation has a hard ceiling of 47 days, rather than two years.
The practical implication for site owners is that manual certificate renewal is becoming operationally impractical. A 47-day certificate renewed manually requires eight renewals per year per domain. Certificate automation via the ACME protocol, used by Let’s Encrypt and now supported by most major CAs, is no longer a convenience feature. It is becoming a necessity.
According to SSL Insights data (January 2025), over 299 million SSL certificates were detected on the internet, with Let’s Encrypt commanding approximately 63.7% of the certificate authority market share. The dominance of Let’s Encrypt reflects the shift toward automated, short-lifecycle certificate management.
Key Takeaways
- SSL is deprecated and cryptographically broken. All versions of SSL have known vulnerabilities and no version should be used in production. When your server is audited and SSL 3.0 support is detected, it is almost never intentional: it is forgotten legacy infrastructure.
- TLS 1.3 is the current standard and outperforms TLS 1.2 on both security and speed. IETF measurements show TLS 1.3 handshakes are twice as likely to complete in under 100 milliseconds compared to TLS 1.2. If your server still defaults to TLS 1.2, the configuration is worth reviewing.
- HTTPS is TLS in practice, not a separate protocol. Every HTTPS connection runs over TLS. The certificate type (DV, OV, or EV) determines what identity information has been verified, not just whether the connection is encrypted.
- The padlock icon is not a trust signal. Over 90% of phishing sites use valid SSL/TLS certificates (APWG, 2023). A padlock confirms only that the connection is encrypted, not that the entity on the other end is legitimate.
- Certificate validity periods are shrinking to 199 days in 2026, with further reductions to 47 days by 2029. Manual renewal processes that work today will become operationally unsustainable within three years. Certificate automation is no longer optional.
- 7% of the top 134,380 websites had SSL/TLS configuration failures as of June 2025 (Qualys SSL Pulse), despite having valid certificates. A valid certificate and a correctly configured server are two different requirements.
- Chrome 154 will enable HTTPS-First mode by default in October 2026, requiring users to grant explicit permission before loading HTTP sites. Any remaining HTTP pages on your domain will generate a user-visible warning.
Frequently Asked Questions About SSL, TLS, and HTTPS
Is SSL still used anywhere in 2026?
No version of SSL is in legitimate production use in 2026. SSL 2.0 and 3.0 were formally deprecated years ago and are considered cryptographically broken. Only 1.1% of surveyed sites still show SSL 2.0 or 3.0 support (W3Techs, January 2026), and in most cases this is a misconfiguration, not an intentional choice. If your server configuration still lists SSL as an enabled protocol, it should be disabled immediately.
Why do certificate providers still call them “SSL certificates” if TLS is what runs?
The terminology persisted because SSL had enormous brand recognition when TLS replaced it in 1999. Certificate authorities continued using the SSL name because it matched what buyers were searching for. Technically, every “SSL certificate” sold today by DigiCert, Sectigo, Let’s Encrypt, or any other CA is a TLS certificate. The certificate does not determine the protocol version your server uses: that is a separate server configuration decision.
What TLS version should my website use in 2026?
TLS 1.3 should be your primary protocol in 2026. TLS 1.2 is acceptable as a fallback for legacy client compatibility. TLS 1.0 and 1.1 were formally deprecated in March 2021 (RFC 8996) and should be disabled entirely. Most modern web servers and CDNs default to TLS 1.3 today, but inherited configurations, older load balancers, and legacy hosting environments frequently have weaker defaults. Verify your server configuration using the free Qualys SSL Labs server test.
Does HTTPS guarantee that a website is safe to use?
HTTPS guarantees that the data traveling between your browser and the server is encrypted and has not been tampered with in transit. It does not guarantee that the website itself is trustworthy or legitimate. Phishing sites routinely use valid TLS certificates and display the padlock. The padlock is a connection security signal, not a site trustworthiness signal. Look for the certificate type (OV or EV certificates include verified organization information) before sharing sensitive data with an unfamiliar website.
What is the difference between a DV, OV, and EV SSL certificate?
Domain Validation (DV) certificates confirm only that the applicant controls the domain, with no identity check. Organization Validation (OV) certificates additionally verify the legal existence and identity of the organization. Extended Validation (EV) certificates require the strictest vetting, including legal, physical, and operational checks. DV is appropriate for blogs and informational sites. OV is the correct choice for business sites, login pages, and e-commerce. EV is used by financial institutions and high-trust environments where users need immediate organizational identity assurance.
How does the new 199-day SSL/TLS certificate validity period affect my website?
Beginning with DigiCert on February 20, 2026, and Sectigo on March 8, 2026, newly issued public TLS certificates have a maximum validity of 199 days, reduced from one year. The CA/B Forum has also approved further reductions to 47 days by 2029. This means manual certificate renewal, which many small site owners still do, will need to happen roughly twice per year now and approximately eight times per year by 2029. Certificate automation via the ACME protocol is the recommended response to this change.
What happens if I keep running HTTP instead of HTTPS in 2026?
Chrome 154 is scheduled to enable “HTTPS-First” mode by default in October 2026. Users loading your HTTP pages will see a browser warning requiring explicit permission to proceed. Beyond the user experience impact, Google has confirmed HTTPS as a ranking signal since 2014, and plain HTTP traffic is not reported correctly in analytics tools (HTTP referral data is often misattributed as “direct” traffic). As of January 2026, 92.6% of the top 100,000 websites use HTTPS by default (W3Techs). HTTP is now the exception, and browsers are actively penalizing it.
Is TLS the same as HTTPS?
TLS and HTTPS are related but not the same. TLS is the encryption protocol that creates a secure channel between browser and server. HTTPS is HTTP traffic transmitted through that TLS-secured channel. Think of TLS as the armored transport vehicle and HTTPS as the delivery service using it. You need TLS running correctly to have HTTPS. HTTPS is the visible result of TLS doing its job: the padlock icon and the “https://” prefix in the browser address bar.
Conclusion: What This Means for Your Website in 2026
SSL is history. TLS is the present. HTTPS is what your users see when TLS is working correctly. The naming confusion that has persisted for nearly 30 years is not going away: certificate providers will keep selling “SSL certificates” because that is what people search for. The practical task is to look past the label.
The standard advice is to “just get an SSL certificate and you’ll be secure.” In practice, a certificate and a correctly configured server are two different requirements, and 28.7% of surveyed top websites fail the latter despite having the former (Qualys, June 2025). Certificate validity periods are shrinking. Chrome is moving to HTTPS-First mode by default. The NIST guidelines from 2025-2026 flag that RSA-2048 certificates could face risk from quantum computing by 2030.
The right action for 2026 is: verify your server runs TLS 1.3 with deprecated versions disabled, confirm your certificate type matches your site’s data collection and user trust requirements, and set up certificate automation before the 199-day validity period makes manual renewal impractical. If you are comparing certificate options, CompareCheapSSL lists current pricing across all major validation levels from trusted certificate authorities.
Accuracy note: This article reflects SSL/TLS protocol standards and certificate industry conditions as of Q1 2026. Certificate validity periods and CA/B Forum requirements are subject to change. Verify current requirements with your certificate authority before making configuration decisions.
