WebBuilding

Foundations

HTTPS and TLS

Summary

HTTPS is HTTP sent over an encrypted, authenticated connection made with TLS (Transport Layer Security), the successor to Netscape's SSL protocols of 1995 and 1996. The IETF published TLS 1.0 in January 1999 and TLS 1.3 in August 2018, and has since retired SSL and TLS 1.0 and 1.1. Certificates from trusted certificate authorities prove a site's identity, and free automated certificates from Let's Encrypt, launched publicly in December 2015, helped make HTTPS the default: as of October 2026, W3Techs finds 90.3% of websites use it.

Web Building Encyclopedia · Foundations · Last reviewed October 22, 2026 · 10 min read

What HTTPS and TLS are

HTTPS is the secure form of HTTP, the protocol browsers and servers use to exchange web pages. An https:// address tells the browser to open an encrypted, authenticated connection before any page data is sent, and it uses TCP port 443 unless the address names another port.1

The encryption comes from TLS, short for Transport Layer Security. TLS is a separate protocol that sits underneath HTTP. RFC 8446, the TLS 1.3 standard, says TLS lets programs talk over the internet in a way designed to prevent eavesdropping, tampering and forged messages.2 An RFC (Request for Comments) is a numbered document published by the IETF, the body that writes internet standards.

Mozilla’s developer documentation breaks the job into three parts:3

  • Encryption. Data is scrambled in transit, so anyone watching the network cannot read it.
  • Integrity. An attacker cannot change the data on the way without being detected.
  • Authentication. The server proves it is the site named in the address. On the web, servers usually prove who they are to visitors, but visitors usually do not prove who they are to servers.

The proof of identity is a certificate, a small signed file that ties the site’s public key to its domain name.3 Under RFC 9110, which has defined the https scheme since June 2022, a connection counts as secured only when the server has been “authenticated as acting on behalf of the identified authority” and the exchange has acceptable confidentiality and integrity protection.1 If the certificate does not match the address, the browser must either ask the user before going on or end the connection with an error.1

SSL, short for Secure Sockets Layer, is the older name. Mozilla describes SSL as the precursor of TLS.3 People still say “SSL certificate,” but those certificates are used with TLS.

SSL at Netscape (1995 to 1996)

SSL was designed at Netscape Communications, the company behind the Netscape Navigator browser. An Internet-Draft titled “The SSL Protocol,” written by Kipp Hickman of Netscape, describes version 2 of the SSL handshake. The IETF’s archived copy is dated April 1995 and was marked to expire in October 1995.4 RFC 6176 cites the same Netscape document with the date February 9, 1995.5

The draft described SSL as “a security protocol that provides privacy over the Internet,” with the server always authenticated and the client authenticated only optionally.4 That pattern, where the website proves its identity and the visitor does not have to, still holds on the web.3

SSL 2.0 had design flaws that later standards documents listed in detail. Its handshake messages were unprotected, so an attacker in the middle could push both sides toward a weaker cipher, the method used to encrypt the data. It used the same key for encryption and integrity checks, and it relied on MD5, an aging hash function, for message authentication.5

Netscape’s replacement, SSL 3.0, is credited to A. Freier and P. Karlton of Netscape and the independent consultant P. Kocher. Its last published version is dated November 18, 1996. SSL 3.0 was never formally published by the IETF at the time; it existed only in Internet-Drafts that later expired. The IETF published it in August 2011 as RFC 6101, a historical record of the protocol.6

TLS 1.0 to TLS 1.3 (1999 to 2026)

The IETF published its own version of the protocol under a new name. TLS 1.0 appeared as RFC 2246 in January 1999, written by T. Dierks and C. Allen of Certicom. The RFC states that it is “based on the SSL 3.0 Protocol Specification as published by Netscape,” but that the changes were large enough that the two cannot talk to each other directly.7 TLS 1.0 kept a way to fall back to SSL 3.0 when the other side did not support TLS.7

In May 2000, RFC 2818 described how to run HTTP over TLS and named port 443 as the default. It also told browsers to check the host name in the address against the name in the server’s certificate, to stop an attacker from posing as the site.8 RFC 9110 replaced RFC 2818 in June 2022.1

Three more versions followed:

VersionStandardPublished
TLS 1.1RFC 4346April 20069
TLS 1.2RFC 5246August 200810
TLS 1.3RFC 8446August 20182

TLS 1.3, written by Eric Rescorla of Mozilla, was the largest change.2 Its standard lists the main differences from TLS 1.2:2

  • Old and weak algorithms were removed. Only modern ciphers that encrypt and check integrity in one step remain.
  • Static RSA key exchange was removed, so every connection has forward secrecy: a key stolen later cannot decrypt traffic recorded earlier.
  • More of the handshake is encrypted, including everything the server sends after its first message.
  • An optional “0-RTT” mode lets a returning visitor send data in the very first message, at the cost of weaker protections for that data.

In July 2026, the IETF published RFC 9846, a revised TLS 1.3 standard that replaces RFC 8446 and marks the TLS 1.2 document, RFC 5246, as obsolete. It describes itself as a minor, backward-compatible update that keeps the version number 1.3.11 Among other changes, it forbids negotiating TLS 1.0 and 1.1.11 The same month, RFC 10015 deprecated the older finite-field Diffie-Hellman and RSA key exchange methods in TLS 1.2.12

As of October 22, 2026, Mozilla’s documentation describes TLS 1.3 as the current and most widely used version, and says TLS 1.2 is still used by some websites while TLS 1.1 and 1.0 should no longer be used.3

Retiring SSL and early TLS

Old versions stayed in use for years because browsers and servers kept them for compatibility and would fall back to them when a connection failed.13 The IETF retired them one at a time.

  • SSL 2.0, March 2011. RFC 6176 said TLS clients and servers must never negotiate SSL 2.0.5
  • SSL 3.0, June 2015. In October 2014, Google’s Bodo Möller described POODLE, a flaw in SSL 3.0 that let a network attacker work out the contents of secure connections. Attackers could trigger it by forcing a browser to retry with the older protocol. Möller noted that “SSL 3.0 is nearly 18 years old, but support for it remains widespread.”13 RFC 7568 followed in June 2015 and banned SSL 3.0 outright, saying it was not secure enough.14
  • TLS 1.0 and 1.1, March 2021. Mozilla announced in October 2018 that Firefox would disable both versions in March 2020, noting that Chrome, Edge and Safari had announced similar plans. Its telemetry showed only 0.1% of Firefox connections using TLS 1.1.15 RFC 8996, published in March 2021, made the rule formal: TLS 1.0 and 1.1 must not be used. It cited outdated ciphers, the lack of modern cipher suites and a dependence on the SHA-1 hash function.16

For a website, the practical result is that a server should offer TLS 1.2 and TLS 1.3 and nothing older.163

Certificates and certificate authorities

A certificate contains a signed copy of the site’s public key, the half of its key pair that can be shared. The signature binds that key to the domain name, so the browser knows it is talking to the real site.3 The browser checks the name in the address against the names listed in the certificate.81

The signature comes from a certificate authority (CA), a company or nonprofit that browsers have agreed to trust. Each browser maker keeps a root store, a list of the CA certificates it trusts.1718 Mozilla’s Root Store Policy, version 3.1, effective July 1, 2026, covers how that list is kept for Mozilla software and says Mozilla decides which CA certificates are included based on the risk to users.17

The shared rules come from the CA/Browser Forum, where certificate issuers and browser makers vote on the Baseline Requirements that every publicly trusted CA must follow.1920 Mozilla’s policy requires CAs to comply with those requirements.17

Trust can be taken away. In June 2024, Google said Chrome would stop trusting new certificates from Entrust, citing “a pattern of compliance failures, unmet improvement commitments.” Certificates whose earliest public log record came after November 11, 2024 were affected in Chrome 131 and later.18 Web Building’s news report on eMudhra covers a newer case from October 2026.

Some CAs sell extended validation (EV) certificates, which also check the company behind the site, and Chrome used to show that company name next to the address. In August 2019, Google said that starting in Chrome 77 it would move the EV badge out of the address bar and into the page information panel, after its research found that the EV display did not help users make safer choices.21

Let’s Encrypt and shorter certificate lifetimes

Let’s Encrypt is a free and automated CA run by the nonprofit Internet Security Research Group (ISRG), set up with the goal of making HTTPS the default on the web.22 Its first publicly trusted certificate went live on September 14, 2015.23 On December 3, 2015, it opened a public beta, so anyone could get free certificates without an invitation. It had issued over 26,000 certificates during its limited beta.22 It left beta on April 12, 2016, after issuing more than 1.7 million certificates covering more than 3.8 million websites.24

Let’s Encrypt relies on software, not people, to check that an applicant controls a domain. The applicant’s software proves control by placing a file at a set address on the site or by adding a DNS record, and the CA checks the result from several network locations.25 The IETF standardized this protocol, ACME (Automatic Certificate Management Environment), as RFC 8555 in March 2019.26

By late 2025, Let’s Encrypt said it was often issuing ten million certificates a day and was “closing in on protecting one billion web sites.”23 On August 6, 2025, it turned off its OCSP service, an online system browsers could ask whether a certificate had been revoked. It said OCSP was a serious privacy risk because the operator could see which sites people were checking, and it now publishes revocation information only through Certificate Revocation Lists.27

Certificates are also getting shorter lives. On April 11, 2025, the CA/Browser Forum passed ballot SC081v3, proposed by Apple. Certificate issuers voted 25 yes, 0 no, with 5 abstaining, and Apple, Google, Microsoft and Mozilla all voted yes.19 The ballot cuts the maximum lifetime of a certificate from 398 days to 47 days in steps.19 As of version 2.3.1 of the Baseline Requirements, dated October 4, 2026, the schedule is:20

Certificates issued fromMaximum lifetimeDomain check can be reused for
March 15, 2026200 days200 days
March 15, 2027100 days100 days
March 15, 202947 days10 days

Let’s Encrypt already issued 90-day certificates and said in December 2025 that it would cut them to 45 days by 2028, as the Baseline Requirements require.28 On October 7, 2026, it confirmed that every certificate issued or renewed from February 10, 2027 will be valid for 64 days by default, with shorter 45-day and 6-day options.29 Its default certificates move to 45 days on February 16, 2028.28

How browsers and Google pushed HTTPS

Browser makers and Google pushed sites toward HTTPS in a series of steps:

  • August 2014. Google announced that HTTPS would be a ranking signal in its search results.30 Google described it as a very light signal that affected fewer than 1% of searches worldwide and counted for less than high-quality content.31
  • January 2017. Chrome 56 began marking HTTP pages that collect passwords or credit card numbers as not secure, as a first step toward labeling all HTTP pages.32
  • July 2018. With Chrome 68, Chrome began showing “Not secure” in the address bar for every HTTP page. When Google announced the change that February, over 68% of Chrome traffic on Android and Windows was already protected by HTTPS, and 81 of the top 100 websites used it by default.33
  • November 2020. Firefox 83 added an HTTPS-Only Mode that upgrades links to HTTPS and asks permission before loading a site that does not support it.34
  • October 2025. Google announced a plan to turn on Chrome’s “Always Use Secure Connections” setting by default starting with Chrome 154, so that Chrome asks for the user’s permission before the first visit to any public site without HTTPS. It said users of its Enhanced Safe Browsing feature would get the setting first, in Chrome 147.35

Google’s own figures show how far the shift went. In its October 2025 post, the Chrome team said the share of Chrome page loads over HTTPS rose from about 30% to 45% in 2015 to about 95% to 99% around 2020, and then leveled off.35 As of October 2026, W3Techs finds that 90.3% of websites use HTTPS as their default protocol.36

Google’s search guidance has also changed since 2014. Its page experience documentation, last updated September 22, 2026, lists secure serving as part of page experience but says: “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results.”37

Timeline

  1. Let's Encrypt confirms 64-day default certificates from February 10, 202729
  2. RFC 9846 revises the TLS 1.3 standard and replaces RFC 844611
  3. Maximum certificate lifetime drops to 200 days under the Baseline Requirements20
  4. Google plans for Chrome 154 to ask before loading public sites without HTTPS35
  5. CA/Browser Forum passes ballot SC081v3, cutting certificate lifetimes to 47 days by 202919
  6. RFC 8996 deprecates TLS 1.0 and TLS 1.116
  7. TLS 1.3 is published as RFC 84462
  8. Chrome 68 marks all HTTP pages "Not secure"33
  9. Let's Encrypt leaves beta after issuing over 1.7 million certificates24
  10. Let's Encrypt opens its free certificates to the public22
  11. Google announces HTTPS as a search ranking signal30
  12. TLS 1.2 is published as RFC 524610
  13. TLS 1.0 is published as RFC 2246, based on SSL 3.07
  14. Last published version of Netscape's SSL 3.06
  15. Netscape's SSL version 2 Internet-Draft is dated April 19954

What it means for your website

Every website needs HTTPS on every page, including simple brochure sites with no forms. Without it, Chrome labels pages “Not secure,”33 and Google has said Chrome will ask visitors before their first visit to a public HTTP site.35 Many hosts and website builders issue free certificates automatically, so the job is mostly checking that it works.

  • Make renewal automatic. Lifetimes drop to 100 days in March 2027 and 47 days in March 2029,20 and Let’s Encrypt’s default falls to 64 days on February 10, 2027.29 Ask your host whether renewal is automatic. If you renew with your own script, Let’s Encrypt advises renewing at about two-thirds of the lifetime instead of a fixed number of days.29
  • Redirect and clean up. Send every http:// address to its https:// version with a permanent redirect, and fix mixed content: scripts, style sheets or fonts still loaded over http://, which browsers block on secure pages.38 This matters most during a website migration.
  • Turn off old versions. If you manage your own server, offer TLS 1.2 and 1.3 only.16
  • Add HSTS once everything works. The Strict-Transport-Security header tells browsers to use only HTTPS for your site and to refuse to bypass certificate errors. Its preload option requires every subdomain to support HTTPS, so add it last.39
  • Do not pay extra for the look of an EV certificate. Starting with Chrome 77, Google moved the EV company name out of the address bar.21 A free domain-validated certificate encrypts the connection just the same.
  • Keep SEO in proportion. HTTPS is expected, but Google says page experience factors other than Core Web Vitals do not directly raise rankings.37

Our glossary entry on the SSL certificate explains the padlock in short form, and our guide to domains and hosting lists what to ask a host about certificates before you sign up.

See also

References

  1. RFC 9110: HTTP Semantics. Internet Engineering Task Force, RFC Editor. 2022-06. accessed October 22, 2026.
  2. RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. Internet Engineering Task Force, RFC Editor. 2018-08. accessed October 22, 2026.
  3. Transport Layer Security (TLS). MDN Web Docs, Mozilla. accessed October 22, 2026.
  4. The SSL Protocol (draft-hickman-netscape-ssl-00). Kipp E.B. Hickman, Netscape Communications Corp., IETF Datatracker. 1995-04. accessed October 22, 2026.
  5. RFC 6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0. Internet Engineering Task Force, RFC Editor. 2011-03. accessed October 22, 2026.
  6. RFC 6101: The Secure Sockets Layer (SSL) Protocol Version 3.0. Internet Engineering Task Force, RFC Editor. 2011-08. accessed October 22, 2026.
  7. RFC 2246: The TLS Protocol Version 1.0. Internet Engineering Task Force, RFC Editor. 1999-01. accessed October 22, 2026.
  8. RFC 2818: HTTP Over TLS. Internet Engineering Task Force, RFC Editor. 2000-05. accessed October 22, 2026.
  9. Information on RFC 4346: The Transport Layer Security (TLS) Protocol Version 1.1. RFC Editor. 2006-04. accessed October 22, 2026.
  10. Information on RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2. RFC Editor. 2008-08. accessed October 22, 2026.
  11. RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3. Internet Engineering Task Force, RFC Editor. 2026-07. accessed October 22, 2026.
  12. Information on RFC 10015: Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2. RFC Editor. 2026-07-16. accessed October 22, 2026.
  13. This POODLE bites: exploiting the SSL 3.0 fallback. Bodo Möller, Google Online Security Blog. 2014-10-14. accessed October 22, 2026.
  14. RFC 7568: Deprecating Secure Sockets Layer Version 3.0. Internet Engineering Task Force, RFC Editor. 2015-06. accessed October 22, 2026.
  15. Removing Old Versions of TLS. Mozilla Security Blog. 2018-10-15. accessed October 22, 2026.
  16. RFC 8996: Deprecating TLS 1.0 and TLS 1.1. Internet Engineering Task Force, RFC Editor. 2021-03. accessed October 22, 2026.
  17. Mozilla Root Store Policy, version 3.1. Mozilla. 2026-07-01. accessed October 22, 2026.
  18. Sustaining Digital Certificate Security: Entrust Certificate Distrust. Chrome Root Program, Google Online Security Blog. 2024-06-27. accessed October 22, 2026.
  19. Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods. CA/Browser Forum. 2025-04-11. accessed October 22, 2026.
  20. Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.3.1. CA/Browser Forum. 2026-10-04. accessed October 22, 2026.
  21. Upcoming Change to Chrome's Identity Indicators. Devon O'Brien, Chromium security-dev group. 2019-08-08. accessed October 22, 2026.
  22. Entering Public Beta. Josh Aas, Let's Encrypt. 2015-12-03. accessed October 22, 2026.
  23. 10 Years of Let's Encrypt Certificates. Josh Aas, Let's Encrypt. 2025-12-09. accessed October 22, 2026.
  24. Leaving Beta, New Sponsors. Josh Aas, Let's Encrypt. 2016-04-12. accessed October 22, 2026.
  25. How It Works. Let's Encrypt. accessed October 22, 2026.
  26. Information on RFC 8555: Automatic Certificate Management Environment (ACME). RFC Editor. 2019-03. accessed October 22, 2026.
  27. OCSP Service Has Reached End of Life. Let's Encrypt. 2025-08-06. accessed October 22, 2026.
  28. Decreasing Certificate Lifetimes to 45 Days. Matthew McPherrin, Let's Encrypt. 2025-12-02. accessed October 22, 2026.
  29. 64-Day Certificate Lifetimes Coming Feb 2027. Sarah Gran, Let's Encrypt. 2026-10-07. accessed October 22, 2026.
  30. HTTPS as a ranking signal. Google Search Central Blog. 2014-08. accessed October 22, 2026.
  31. Google Starts Giving A Ranking Boost To Secure HTTPS/SSL Sites. Barry Schwartz, Search Engine Land. 2014-08-07. accessed October 22, 2026.
  32. Moving towards a more secure web. Emily Schechter, Google Online Security Blog. 2016-09-08. accessed October 22, 2026.
  33. A secure web is here to stay. Emily Schechter, Chromium Blog. 2018-02-08. accessed October 22, 2026.
  34. Firefox 83 introduces HTTPS-Only Mode. Mozilla Security Blog. 2020-11-17. accessed October 22, 2026.
  35. HTTPS by default. Chris Thompson, Mustafa Emre Acer, Serena Chen, Joe DeBlasio, Emily Stark and David Adrian, Google Online Security Blog. 2025-10-28. accessed October 22, 2026.
  36. Usage statistics of Default protocol https for websites. W3Techs. 2026-10. accessed October 22, 2026.
  37. Understanding page experience in Google Search results. Google Search Central. 2026-09-22. accessed October 22, 2026.
  38. Mixed content. MDN Web Docs, Mozilla. accessed October 22, 2026.
  39. Strict-Transport-Security header. MDN Web Docs, Mozilla. accessed October 22, 2026.

Web Building Encyclopedia. First published October 22, 2026. Last reviewed October 22, 2026. Every fact on this page is linked to a source we opened. Spotted an error? Write to [email protected].