HTTP, HTTPS and SSL/TLS certificates: what the padlock really protects

HTTP, HTTPS, SSL, TLS, certificate and padlock are often used as if they meant the same thing. They belong to the same mechanism, but each plays a different role.

The simplest distinction is this: HTTP defines how a browser and a web server communicate. HTTPS uses that same language inside a channel protected by TLS. The digital certificate allows the browser to verify that it is establishing that channel with the requested domain.

Understanding these three layers avoids two common mistakes: believing that HTTPS guarantees a site is honest, or thinking a certificate only serves to display a padlock.

HTTP: the language of web exchanges

HTTP stands for Hypertext Transfer Protocol. When someone opens a page, their browser sends a request to the server. The server returns a response containing a status, headers and usually the requested content.

A request can ask for a page, submit a form, load an image or call an API. A response can indicate that everything went well, that the resource has moved to a new address or that it does not exist.

HTTP therefore structures the conversation. On its own, it does not protect the journey. On an unencrypted HTTP connection, someone able to observe the network could potentially read the information being exchanged or try to modify it. This is particularly dangerous on an untrusted Wi-Fi network or when a form sends a username, address or payment detail.

HTTPS: HTTP carried through a TLS channel

The S in HTTPS stands for secure. Before exchanging HTTP requests and responses, the browser and server establish a TLS connection.

This layer provides three main guarantees during transmission.

• Confidentiality: the data being exchanged is encrypted and cannot simply be read by an intermediary.
• Integrity: covert modifications to the traffic can be detected.
• Authentication: the browser checks that the certificate presented matches the requested domain name and traces back to a recognised authority.

HTTPS protects the headers and body of HTTP messages in transit. An internet service provider or someone on the same network may still observe certain technical information, such as the IP address contacted and the volume of traffic, but normally cannot see the details of the page, form or parameters protected within the connection.

SSL or TLS: which term should you use?

SSL, or Secure Sockets Layer, is the old protocol that preceded TLS. SSL versions are obsolete and should no longer be used. In a modern configuration, the correct term is TLS, usually version 1.2 or 1.3.

The expression “SSL certificate” nevertheless remains very common in hosting packages. It almost always means a certificate used with TLS. This is not necessarily a serious error in marketing terminology, but remember that actual security today relies on TLS, not the old SSL protocol.

The digital certificate: an identity card for the domain

A certificate contains, among other things, the domain name or names it covers, a public key, a validity period, the issuer’s identity and a digital signature.

When establishing the connection, the browser checks several things:

• the certificate covers the domain shown in the address;
• it is currently valid;
• its signature and the certificate chain lead to a recognised certificate authority;
• it is not being presented in an obviously invalid context.

The certificate authority does not hold the site’s private key. That key stays on the server and must never be disclosed. The certificate links the public key to the domain; the private key then allows the server to prove that it controls the corresponding key.

What happens when the connection is established

The full mechanism is complex, but its principle can be summarised in four steps.

1. The browser contacts the server and proposes the versions and cryptographic parameters it accepts.
2. The server chooses compatible parameters and presents its certificate.
3. The browser validates the certificate and both parties establish session secrets without transmitting them directly like a simple password.
4. HTTP requests and responses then travel through the encrypted channel.

Modern techniques therefore combine asymmetric cryptography, which is useful for authentication and establishing secrets, with symmetric cryptography, which is faster for protecting the volume of data being exchanged.

What HTTPS guarantees and what it does not

HTTPS means the connection to the displayed domain is protected. It does not mean that the domain owner is honest, that the published information is accurate or that the server will never be hacked.

A fraudster can register a name resembling a bank’s and obtain a valid certificate for that fake domain. The connection to the fraudulent site will then be encrypted, but the site will remain fraudulent. You therefore need to read the actual domain name, rather than simply look for a security icon.

HTTPS also does not protect data after it arrives. If a site stores passwords in plain text, shares information with third parties without a valid basis or has a vulnerability in its application, the certificate does not resolve those problems.

Finally, encryption does not replace updates, multifactor authentication, a privacy policy or secure development.

The most common certificate errors

Expired certificate

Every certificate has a start and end date. Renewal should be automated and monitored. Automation without alerts is not enough: the site needs to detect a failure before visitors discover it.

Different domain name

A certificate issued for a domain does not automatically cover every variation of it. The required subdomains and alternative names must be included in the certificate.

Incomplete chain

The server sometimes needs to provide intermediate certificates so that the browser can reconstruct the chain of trust. An incorrect configuration may work on some devices and fail on others.

Mixed content

A main page loaded over HTTPS can still request an image, stylesheet or script over HTTP. This mixed content weakens protection, and browsers generally block the most dangerous active resources.

Old TLS versions

TLS 1.0 and 1.1 are outdated. A modern server should support TLS 1.2 and favour TLS 1.3 when the environment allows it.

HTTPS redirection and HSTS

A site running over HTTPS must also handle people who still enter an address beginning with HTTP. The server normally redirects these requests to the HTTPS version.

However, that first unprotected request can be intercepted. The HSTS header tells the browser to use HTTPS directly on subsequent visits. Proper inclusion in an HSTS preload list can also protect the first visit, but requires all relevant subdomains to be configured carefully.

HSTS is useful, but a poor decision can make a subdomain inaccessible. It should be rolled out gradually, after confirming that everything within its scope runs reliably over HTTPS.

How should a visitor check a site?

• Read the full domain name, especially before logging in or making a payment.
• Watch out for substituted letters, added words and unusual domains.
• Do not ignore a certificate warning for a sensitive service.
• Open the official site yourself instead of following a link received in a message.
• Remember that an encrypted connection can lead to a fraudulent site.

The site owner’s checklist

• Serve all pages and resources over HTTPS.
• Redirect HTTP to HTTPS.
• Automate certificate renewal and monitor its expiry.
• Support TLS 1.2 and 1.3 with an up-to-date configuration.
• Remove mixed content.
• Test the main domain and all subdomains.
• Deploy HSTS carefully.
• Protect the private key and limit who can access it.
• Continue securing the application and data after transmission.

Conclusion

HTTP describes the exchange between browser and server. HTTPS protects that exchange through TLS. The certificate gives the browser the information it needs to authenticate the domain and establish the secure channel.

The padlock is therefore neither a quality label nor proof of honesty. It indicates that the connection to the displayed domain provides guarantees of confidentiality, integrity and authentication. This is essential on the modern web, but it is only one layer of overall security.

Useful sources

• An overview of HTTP — MDN Web Docs
• Transport Layer Security — MDN Web Docs
• Practical TLS configuration guide — MDN Web Docs
• TLS 1.3 specification, RFC 8446 — RFC Editor