HTTP vs HTTPS: Encryption, Certificates, and How HTTPS Works

HTTPS is HTTP protected by TLS encryption and server authentication. Plain HTTP provides no comparable protection for traffic in transit. With HTTPS, the browser checks the server's certificate and establishes an encrypted connection before exchanging protected web requests and responses. RFC 9110 defines the two URL schemes and their security requirements.

This article explains what HTTPS actually does, and walks through the concepts it is built from: encryption, ports, certificates, certificate authorities, and the ACME protocol that automates certificate issuance. It ends where every HTTPS chain ends if you follow it far enough down: at control of a domain name.

What plain HTTP leaves exposed

These are connection properties, not a promise that a site is safe to buy from. HTTPS protects communication with the named host; a phishing site can also use HTTPS.

HTTP, the protocol browsers and web servers speak, was designed as cleartext. A request for a page, the cookies attached to it, the form data in it, and the page that comes back all travel across the network as readable bytes. Anyone positioned on the path — the operator of a coffee-shop Wi-Fi network, an ISP, a backbone carrier, a compromised router — can read all of it.

Worse, they can change it. Cleartext HTTP has no integrity protection, so an intermediary can inject advertising into pages, rewrite a download link to point at malware, or swap the account number on a payment page, and neither side can tell. And because plain HTTP has no notion of server identity, the browser is simply trusting that whatever machine answered — usually whatever IP address the DNS lookup returned — really is the site it asked for. As our case studies of DNS hijacking incidents show, that assumption fails in practice, and it fails expensively.

The three guarantees of HTTPS

HTTPS wraps HTTP in TLS — Transport Layer Security — whose current version, TLS 1.3, was standardized in 2018 as RFC 8446. The specification states the goal directly: TLS lets applications communicate in a way designed to prevent eavesdropping, tampering, and message forgery. Those three verbs map to three concrete guarantees:

• Confidentiality. The traffic is encrypted, so an observer on the path sees only which server you connected to and roughly how much data moved — not the URLs, cookies, credentials, or content.
• Integrity. TLS authenticates protected traffic with a cryptographic integrity check, so altered data is rejected rather than silently delivered. Modern TLS uses authenticated encryption; this is more specific than simply attaching a hash to a message.
• Authentication. The server proves possession of the private key for a certificate the browser trusts for the requested hostname. That is authentication of the connection, not proof of rightful domain ownership or an honest business. Mandiant documented DNS hijackers obtaining valid certificates for redirected services, allowing browsers to connect without certificate errors.

A useful way to remember the division of labor: encryption seals the envelope, integrity checks detect alterations, and authentication checks the recipient's certificate and proof of its private key against the requested hostname.

Ports: the internet's door numbers

An IP address identifies a machine, but a machine runs many networked programs at once. A port is the number, from 1 to 65535, that identifies which program a connection is for — the apartment number after the street address. A web server, a mail server, and an SSH daemon can share one machine because each listens on its own port.

The IANA port registry assigns well-known defaults so clients don't have to guess: port 80 for HTTP, and port 443 — registered as "http protocol over TLS/SSL" — for HTTPS. That is why URLs don't mention them; when a browser opens https://example.com, the default port is 443 unless the URL says otherwise.

One caveat worth knowing: encrypting traffic on port 443 does not make the connection invisible. An observer still sees which IP you connected to, and the TLS handshake has historically sent the server's hostname (the SNI field) unencrypted — any intermediary can view which website you're visiting simply by checking the first packet for a connection, as Cloudflare puts it. Encrypted Client Hello (ECH) is the emerging fix, and encrypted DNS closes the parallel leak on the lookup side — a shift with its own consequences, which we cover in DNS over HTTPS vs enterprise split-horizon DNS.

The TLS handshake establishes authenticated keys

The illustration summarizes an older TLS 1.2 handshake. TLS 1.3 changes the message order, as the steps below explain.

Encryption comes in two flavors, and HTTPS needs both. Symmetric encryption uses one shared key for both sealing and opening messages — fast, but it assumes the two sides already share a secret, which strangers on the internet do not. Asymmetric (public-key) cryptography solves that bootstrap problem: the server holds a private key, publishes the matching public key, and anything encrypted to the public key can only be opened with the private one, while a digital signature made with the private key can be verified by anyone holding the public one.

A typical certificate-based TLS 1.3 handshake combines key agreement and authentication. RFC 8446, section 2 shows the message order:

1. The browser sends supported cryptographic parameters and a key share.
2. The server selects parameters and sends its key share. Both sides derive handshake keys.
3. The server sends an encrypted certificate and proves possession of its private key with a signature.
4. The browser verifies the certificate, hostname, and handshake. Both sides use derived traffic keys to protect application data.

HTTP/3 uses QUIC rather than TCP. RFC 9114, section 2 explains how QUIC integrates TLS 1.3 for HTTPS connections.

A note on names: this protocol family began life as SSL (Secure Sockets Layer) in the 1990s, was renamed TLS when standardization moved to the IETF, and modern browsers now speak TLS 1.2 and 1.3 only. The old name survives in everyday phrases like "SSL certificate," which today always means a TLS certificate.

Certificates and certificate authorities

Encryption without identity would be a private conversation with a possible impostor. The identity half of HTTPS rests on certificates: signed digital documents that bind a domain name to a public key. The signer is a certificate authority (CA) — an organization whose own signing keys are pre-trusted by browsers and operating systems through their root stores. Trust flows down a chain: a root CA signs an intermediate, the intermediate signs the certificate for example.com, and the browser accepts the site's key because the chain terminates in a root it already trusts — cryptographic security by delegation.

Before signing, the CA must validate that the requester actually controls the domain named in the certificate — that validation is the entire meaning of a standard (domain-validated) certificate. If a browser receives a certificate that doesn't chain to a trusted root, doesn't match the hostname, or has expired, the browser reports a certificate error. Browser indicators vary: Chrome announced a replacement for its padlock icon in 2023.

Certificate warnings require attention because the browser could not establish the expected authenticated connection. Do not bypass a warning to enter credentials or approve a payment. Diagnose the hostname, certificate chain, validity dates, and local clock before continuing.

Two developments keep the CA system honest at scale. Certificate Transparency (RFC 6962) records issued certificates in public, append-only logs — a protocol for publicly logging the existence of TLS certificates — so a domain owner can monitor the logs and detect a certificate issued for their name that they never requested.

Public TLS certificate lifetimes are shrinking. The current CA/Browser Forum Baseline Requirements, section 6.3.2, set maximum validity periods by issuance date. The limit became 200 days on March 15, 2026. The schedule reduces the limit to 100 days on March 15, 2027, then 47 days on March 15, 2029. Shorter lifetimes increase the need for reliable renewal automation.

ACME: certificates on autopilot

For the web's first two decades, getting a certificate meant paying a CA, generating a signing request by hand, proving control of the domain over email, and repeating the ritual every year or two. The cost and friction showed: as late as February 2018, Google's telemetry put Chrome traffic on Android and Windows at just over 68% protected.

ACME — the Automatic Certificate Management Environment, standardized in 2019 as RFC 8555 — automates certificate management. Let's Encrypt offers free certificates through ACME. The protocol itself does not set a CA's prices. RFC 8555 defines the automated verification and issuance process. An ACME client (such as EFF's Certbot) proves control of a domain by completing a challenge, and Let's Encrypt's documentation describes the two that matter:

• HTTP-01: the CA hands the client a token, and the client puts a file on your web server at http://<your-domain>/.well-known/acme-challenge/<token>. The CA checks the expected response to validate the challenge. This challenge cannot be used to issue wildcard certificates.
• DNS-01: the client proves control of the domain's DNS by putting a specific value in a TXT record at _acme-challenge.<your-domain>. Successful DNS-01 validation proves the applicant can answer that DNS challenge. DNS-01 supports wildcard issuance. A certificate for *.example.com matches shop.example.com, but not example.com or a.shop.example.com. RFC 9525, section 6.3 limits wildcard matching to one label.

Issuance and renewal then run on a timer with no human involved. In December 2025, Let's Encrypt reported it was frequently issuing ten million certificates per day and on track to serve a billion active sites. Encryption went from a paid add-on to the default state of the web.

Notice what both challenges have in common: the only identity being verified is control of a domain name — via its web server or via its DNS zone. In the HTTPS trust model, the domain is the identity.

Why HTTPS became non-negotiable

The browsers did not wait politely for adoption. Beginning in July 2018 with the release of Chrome 68, Chrome marked every plain-HTTP page "not secure" in the address bar, and other browsers followed the same arc. Google had already put a thumb on the scale years earlier, announcing in August 2014 that it was starting to use HTTPS as a ranking signal in search — only a very lightweight signal at the time, but a clear statement of direction.

Two more mechanisms lock the ratchet. HSTS (HTTP Strict Transport Security, RFC 6797) lets a site declare itself accessible only via secure connections: once a browser has seen that header, it refuses to load the site over plain HTTP again for as long as the declared max-age policy stays cached — a first-ever visit, or one after the policy expires, isn't covered unless the domain is also on browsers' hardcoded HSTS preload list. And browser vendors gate modern web capabilities to secure pages — in Chrome's words, HTTPS unlocks both performance improvements and powerful new features that are too sensitive for HTTP. For any domain that serves users, HTTPS stopped being a security upgrade and became the price of admission.

What HTTPS does not do

Clarity about the guarantees requires clarity about the gaps:

• It does not vouch for the site's honesty. A domain-validated certificate proves you reached the domain in the address bar — not that the domain is trustworthy. Phishing sites routinely serve valid HTTPS on lookalike domains they legitimately registered. The padlock means private, not safe.
• It does not hide that a connection happened. Destination IPs, timing, traffic volume, and (until ECH is universal) the SNI hostname remain observable metadata.
• It does not protect data at rest. TLS secures the pipe; a breached or malicious server exposes whatever you sent regardless of how well it was encrypted in transit.
• It is only as strong as control of the domain. ACME's challenges are honest about the trust model: an attacker who controls validation responses may obtain a certificate, subject to the CA's issuance checks. A compromised registrar account can expose DNS control. A domain hijacker doesn't need to break TLS — they become the identity TLS attests to, as our breakdown of how domain hijacking actually happens shows with real incidents.

The domain is the root of the chain

Follow HTTPS all the way down and every guarantee bottoms out in the same place. The certificate names a domain. The CA validated control of that domain. The ACME challenge was answered by that domain's web server or nameservers. Encryption, integrity, authentication — all of it is anchored not in the server hardware or the company behind the site, but in the domain name and the DNS that steers it.

That is why domain security is not adjacent to HTTPS — it is underneath it. Protecting the registrar account, locking transfers, controlling who can edit DNS records: these are certificate-security measures, whether or not they are labeled that way. Certificate automation also needs narrow DNS permissions, protected account credentials, and monitoring for unexpected issuance. Tokenized ownership alone does not secure a DNS provider account or an ACME credential.

The padlock is the last link in the chain. The domain is the first.

Choose certificate validation and hostname coverage before deployment. Compare free certificate options and renewal responsibilities. Then follow the certificate installation and verification guide.

Sources and further reading

• IETF — RFC 9110, sections 4.2.1–4.2.2, HTTP/HTTPS schemes, default ports, confidentiality, integrity, and authentication. Fetched 2026-09-15.

• IETF — RFC 9110, section 4.3.3, HTTPS authority based on certificate trust and use of the corresponding private key. Fetched 2026-09-15.

• Mandiant — Global DNS Hijacking Campaign: DNS Record Manipulation at Scale, technique 1, steps 6–7: attackers obtaining certificates after changing DNS records. Fetched 2026-09-15.

• IETF — RFC 9525: Service Identity in TLS — wildcard matching limits. Fetched 2026-10-22.

• IETF — RFC 9114: HTTP/3 — HTTPS over QUIC. Fetched 2026-10-22.

• Chromium — An Update on the Lock Icon — connection indicators and website trust. Fetched 2026-10-22.

• IETF — RFC 2818: HTTP Over TLS — defines HTTPS and the default port 443.

• IETF — RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (August 2018).

• IETF — RFC 8555: Automatic Certificate Management Environment (ACME) (March 2019).

• IETF — RFC 6962: Certificate Transparency and RFC 6797: HTTP Strict Transport Security.

• IANA — Service Name and Transport Protocol Port Number Registry — the port 443 registration.

• Let's Encrypt — Challenge Types and 10 Years of Let's Encrypt Certificates (December 2025).

• Chromium Blog — A secure web is here to stay (February 2018).

• Google Search Central — HTTPS as a ranking signal (August 2014).

• CA/Browser Forum — Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (April 2025); schedule detail via DigiCert — TLS Certificate Lifetimes Will Officially Reduce to 47 Days.

• Cloudflare — Encrypted Client Hello: the last puzzle piece to privacy (September 2023).

• EFF — Certbot, the ACME client.