The Padlock Isn't Decoration

The Padlock Problem

You have probably noticed the padlock icon in your browser's address bar. Click on it and you will see something like “Connection is secure.” Most people accept that as a good sign and move on. Fewer people understand what it actually means, how it got there, or what happens to a site that does not have it.

The padlock indicates that your connection is protected by HTTPS, which stands for Hypertext Transfer Protocol Secure. The “Secure” part is not marketing. It reflects a real technical difference between HTTP and HTTPS that affects every visitor to your site.

What HTTPS Actually Does

HTTPS gives you three things that plain HTTP cannot provide.

Encryption

Without HTTPS, data sent between a browser and a server travels as plaintext. Anyone on the same network, whether that is a coffee shop Wi-Fi router or an internet service provider, can read the traffic. Passwords, form submissions, and session tokens are all visible.

With HTTPS, that traffic is encrypted end-to-end. Someone intercepting the connection sees only scrambled bytes that are computationally impractical to reverse.

Authentication

Encryption alone is not enough. You also need to know that you are talking to the right server. HTTPS uses certificates to prove that the server you are connecting to is genuinely controlled by the domain you typed. Without this, an attacker could intercept your traffic and impersonate the site while decrypting everything you send.

Integrity

HTTPS also ensures that data has not been tampered with in transit. A network middleman cannot inject content into the page you receive. This matters practically: without HTTPS, some ISPs have historically injected ads into web pages. Malicious actors on the same network can insert scripts.

How TLS Works

The security in HTTPS comes from a protocol called TLS, Transport Layer Security. You will also see the older name SSL (Secure Sockets Layer), which is technically obsolete but still commonly used as shorthand. Modern connections use TLS 1.2 or TLS 1.3. The older SSL versions have known vulnerabilities and are no longer accepted by current browsers.

Before any data flows, the browser and server run through a short negotiation called the TLS handshake. In TLS 1.3, this takes a single round trip: roughly one millisecond of overhead for a nearby server. Here is what happens.

1. ClientHello. The browser opens a connection and sends a message declaring which TLS versions and cipher suites it supports, along with a random value.
2. ServerHello and certificate. The server responds by picking a cipher suite, sending its own random value, and attaching its TLS certificate. The certificate contains the server's public key and is signed by a trusted Certificate Authority.
3. Certificate verification. The browser checks the certificate against its built-in list of trusted Certificate Authorities. It confirms the certificate is valid, has not expired, and matches the domain being visited.
4. Key exchange and finished. Both sides use the exchanged values to independently derive the same session keys. They each send a “Finished” message, encrypted with those keys, to confirm the handshake is complete.

From that point on, all data flows encrypted with symmetric keys that were never transmitted over the wire. Even someone who recorded the entire handshake cannot decrypt the session.

Certificates and Certificate Authorities

A TLS certificate is a file that ties a public key to a domain name. The file is signed by a Certificate Authority, or CA, which is an organization that browsers trust to verify domain ownership before issuing a certificate.

When a server presents a certificate, the browser checks whether the signature came from a CA in its trusted list. That list is built into the operating system and browser. If the signature traces back to a trusted CA and the domain matches, the padlock appears. If it does not, the browser shows a full-page security warning.

The most important thing to understand about certificates is that they expire. A certificate issued today is typically valid for 90 days to one year. When it expires, browsers reject it exactly the same way they would reject a certificate from an untrusted source. Visitors see a warning page and most will not continue. An expired certificate on a production site is one of the most preventable outages that exists.

Let's Encrypt Changed Everything

Until around 2015, obtaining a TLS certificate cost money, required manual verification, and needed to be renewed by hand every year. That friction meant many small sites simply ran on HTTP.

Let's Encrypt is a free, automated, open Certificate Authority launched in 2016. It issues certificates at no cost and provides a protocol called ACME that lets servers request and renew certificates automatically. Certbot is the most common client for this on a VPS. Managed platforms like Vercel and Netlify handle the entire process invisibly: you attach a domain, and HTTPS is live within minutes.

There is no longer any meaningful barrier to running HTTPS. The cost is zero. The setup on modern platforms takes no time at all. The only reason to run an HTTP site in 2026 is oversight.

Where Things Can Still Go Wrong

Having a valid certificate is not always enough on its own.

Mixed content

If your page loads over HTTPS but pulls in resources (images, scripts, stylesheets) from HTTP URLs, browsers block or flag those resources. This is called mixed content. The page itself is secure, but the insecure resource could be tampered with. When migrating a site from HTTP to HTTPS, tracking down hardcoded http:// URLs in templates is a necessary step.

Certificate mismatch

A certificate issued for example.com does not cover www.example.com unless the certificate explicitly includes both. Wildcard certificates (*.example.com) cover all subdomains one level deep. When adding subdomains, confirm that your certificate covers them or provision a separate one.

Expired certificates

Automatic renewal is reliable on managed platforms. On a VPS with Certbot, it runs as a cron job. The failure mode is when the renewal job silently stops running: a server migration, a configuration change, or a lapsed cron that nobody noticed. Set up monitoring on certificate expiry. Most uptime tools check this. Many registrars and CAs send email warnings at 30 and 7 days before expiry. Pay attention to them.

Practical Takeaways

• On managed platforms, HTTPS is automatic. Vercel, Netlify, and Railway provision and renew certificates for you. Attach your domain and it is done.
• On a VPS, use Certbot with Let's Encrypt. It is free, widely documented, and handles auto-renewal. Run certbot renew --dry-run to confirm the renewal process is working.
• Check your certificate covers all your subdomains. A cert for example.com does not cover app.example.com. Use a wildcard cert or provision one per subdomain.
• Redirect HTTP to HTTPS. Do not serve the same content on both. A permanent redirect (HTTP 301) sends every HTTP request to its HTTPS equivalent. Most platforms do this by default; on a VPS you configure it in Nginx.
• Fix mixed content after migrating. Search your templates and database content for hardcoded http:// URLs. A site that shows a padlock with a warning triangle has mixed content and is not fully secure.
• Monitor certificate expiry. One alert at 14 days is enough to prevent a preventable outage.

HTTPS is no longer optional and has not been for several years. Google has used it as a ranking signal since 2014. Chrome marks HTTP sites as “Not Secure” in the address bar. Browsers block insecure requests in certain contexts entirely. The infrastructure to support it is free. If you are building or migrating a site and want to make sure the full stack is set up correctly from the start, that is exactly what we handle at Code43.

HTTPS secures the connection, but it says nothing about who can find your site. Read our guide on SEO fundamentals to understand how search engines discover and rank your content, or learn how CDNs improve performance once your site is live and secure.