ArticlesAlmost every website you visit today begins with https:// and a small lock or similar icon in the browser. Most people know it means the site is secure, but not what is happening behind the scenes or what the lock does and does not promise. This article explains how HTTPS works, how a website proves its identity, how free certificates are issued, and which common mistakes weaken an otherwise encrypted site. It relies on documentation from Mozilla's MDN Web Docs and from Let's Encrypt, a nonprofit certificate authority.
HTTPS in one sentence
HTTPS is ordinary web traffic carried inside a protocol called Transport Layer Security, or TLS. MDN explains that after a TLS connection is set up, the client and server use a shared secret key to encrypt and decrypt every message, including both the HTTP headers and bodies [1]. That means someone who can watch the network, such as the operator of a public Wi-Fi hotspot, sees that you connected to a server but cannot read the pages you request or the forms you submit. Encryption protects what is sent. As we will see, other parts of the system exist to make sure you are sending it to the right place.
The TLS handshake
Before any page content is exchanged, the browser and server perform a handshake. MDN describes the handshake as setting the security parameters of the connection through several agreements [1].
First, the two sides agree on which version of TLS to use. MDN says the current version is TLS 1.3, defined in RFC 8446, and it is the most widely used. TLS 1.2 is still used by some websites, while TLS 1.1 and 1.0 should no longer be used [1].
Second, they agree on a cipher suite, which defines the algorithms for key agreement, authentication, encryption, and message authentication [1]. Think of the cipher suite as the toolkit both sides have chosen to use for the rest of the conversation.
Third, authentication takes place. MDN notes that the client and server can optionally authenticate each other, but on the web, client authentication is rare outside specialized applications. Server authentication, in which the server proves who it is to the client, is a fundamental part of web security [1].
Finally, they agree on a secret key used to encrypt and decrypt the messages that follow [1]. From there, the page loads as it would over plain HTTP, only protected.
The importance of server identity
Encryption alone is not enough. If you encrypted a message but sent it to an impostor, the impostor could read it. This is why server authentication matters.
MDN explains that to support it, a website needs a digital certificate containing a digitally signed copy of the public key that matches the site's private key. The certificate binds those keys to the domain name, so the browser knows it is really connecting to, for example, the intended site rather than a lookalike [1]. The signature comes from a certificate authority, or CA, an organization browsers have been configured to trust. The browser checks the signature and the domain name before it relies on the connection. The details of which authorities each browser trusts are set by the browser and operating system vendors, and are beyond the scope of the sources used here.
How a free certificate is issued
Certificates used to involve manual paperwork and fees. Let's Encrypt, which MDN describes as a widely used nonprofit certificate authority that issues free TLS certificates [1], automates the process. Its documentation says the goal of Let's Encrypt and the ACME protocol is to let a server set up HTTPS and obtain browser-trusted certificates automatically, without human intervention, by running an ACME client on the web server [2].
The process has two parts. First, the ACME client proves to the CA that the server controls a domain. The client generates an account key pair and asks the CA what it must do to prove control. According to Let's Encrypt, the CA may offer challenges such as provisioning a DNS record under the domain or placing a specific file at a well-known path on the domain's HTTP site [2]. The client completes one, and the CA checks that the challenge was satisfied.
There is a subtlety here that Let's Encrypt openly acknowledges: this validation cannot use HTTPS, which makes it vulnerable to certain attacks. To reduce the risk, the CA performs several validations in parallel from different network perspectives, making it significantly harder for an attacker to subvert the process [2].
Second, once the client is authorized for the domain, it can request a certificate. The client builds a certificate signing request asking the CA to issue a certificate for the domain with a specified public key, signed with the corresponding private key. It also signs the request with the authorized account key. The CA verifies both signatures, issues the certificate, and returns it. It also submits the certificate to public Certificate Transparency logs [2]. Renewing a certificate means repeating validation and issuance, and revocation works similarly: the client signs a request, and the CA publishes revocation information through a Certificate Revocation List so browsers know not to accept the certificate [2].
For many site owners none of this is visible. MDN observes that modern hosting services support HTTPS by default or through a setting, and the service is likely to manage the certificate and server configuration for you [1]. This is the situation for many static-site hosts, so a person publishing a blog may only need to enable an option rather than run an ACME client.
Mixed content: when one HTTP file spoils the page
A padlock for the main page does not guarantee that everything on the page is protected. MDN defines mixed content as a page loaded over HTTPS that includes scripts, stylesheets, images, or fonts over HTTP. Those subresources do not get the protection of HTTPS, so an attacker can read them and potentially modify them, which can undermine the whole page. MDN gives the example of an attacker changing a script so it behaves harmfully [1].
Because of this, browsers do not allow secure pages to load insecure subresources. Depending on the type of subresource, they either upgrade the request to HTTPS or block it [1]. A site owner who sees broken images or scripts after moving to HTTPS should look for old http:// links in the page source. If updating the code is impossible, for example for archived HTML, MDN says a content security policy with the upgrade-insecure-requests directive can make the browser upgrade those requests automatically [1].
Redirects and HSTS
People still type http://example.org or follow old links. MDN recommends that a site listen for HTTP requests and send a 301 Moved Permanently redirect to the HTTPS version. But it points out a weakness: the first request travels unprotected, so an attacker may intercept it and prevent the upgrade. This is sometimes called an SSL stripping attack [1].
The defense is the Strict-Transport-Security header, known as HSTS. It tells the browser the site wants HTTPS only, so subsequent visits go straight to HTTPS even if the user types an HTTP address. MDN notes the remaining gap: the first visit, or the first visit after the HSTS record has expired, is still exposed. To cover that, Chrome keeps an HSTS preload list of domains that are always upgraded, and Safari and Firefox use similar lists derived from Chrome's [1].
What the lock does not tell you
The sources above describe encryption, server authentication, and integrity. They do not claim that a site with a certificate is trustworthy in every other sense. A certificate links a key to a domain name, as MDN puts it [1]; it does not review the owner's honesty. A scam site can use HTTPS too, since Let's Encrypt automates issuing certificates to anyone who proves control of a domain [2]. That is an inference from how the automated process works, and not a claim either source makes in these words. Use the lock as evidence that the connection is private and goes to the domain shown, then still check that the domain is the one you meant to visit.
A short checklist for site owners
Use TLS 1.3, with 1.2 as a fallback if you must, and avoid TLS 1.0 and 1.1 [1]. Let your host or an ACME client manage certificates and renewal [1][2]. Load every script, style, image, and font over HTTPS to avoid mixed content [1]. Redirect HTTP to HTTPS and add the HSTS header [1]. MDN also points to Mozilla's recommended TLS configurations and its HTTP Observatory for testing your setup [1]. Run a test after any change.
Takeaway
HTTPS combines three jobs: encrypting traffic, proving the server's identity with a certificate, and detecting tampering. The TLS handshake sets all of that up in a moment, and automated authorities such as Let's Encrypt have made certificates something most sites can get without cost or manual effort. The remaining risks usually come from details around the edges, such as insecure subresources and unprotected first requests, which is why redirects, HSTS, and clean page assets are worth the attention.
Sources
[1] MDN Web Docs, Transport Layer Security (TLS) - https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Transport_Layer_Security
[2] Let's Encrypt, How It Works - https://letsencrypt.org/how-it-works/