SSL and HTTPS explained: what the padlock actually proves

What HTTPS proves, and what it doesn't

HTTPS does two specific jobs. It encrypts the connection between a visitor's browser and your website, so nobody on the same café Wi-Fi, or anywhere else along the route, can read or quietly alter what passes between them. It also confirms that the certificate presented was issued for the domain in the address bar, so the browser knows it is talking to that address rather than an impostor in the middle.

What it doesn't do is vouch for the people behind the domain. Chrome's security team put it plainly in 2023: nearly all phishing sites use HTTPS, and therefore also display the lock icon. An everyday certificate checks that the applicant controls a domain name, not that the business is real, honest or the one you think it is. A fake shop on a lookalike domain can get one just as easily as the genuine shop.

That cuts both ways for you as a site owner. Chrome marks plain HTTP pages as not secure, so a site without HTTPS looks neglected. But a secure connection won't win anyone's trust on its own. Clear contact details, a real address and plain policies still do that work.

How a certificate authority decides to trust you

A certificate is a small file that links your domain name to a cryptographic key kept on your server. Browsers accept it because it is signed by a certificate authority, an organisation they already trust to do the checking. Hosting plans still call it an SSL certificate, although the protocol in use today is SSL's successor, TLS. For the certificates most small websites use, the authority's check is deliberately narrow: does the applicant really control this domain?

Let's Encrypt, a certificate authority designed to work without human involvement, shows how this happens in practice. Software on your server asks for a certificate, and Let's Encrypt sets it a small test: put a file at a specific path on the website, or add a specific record to the domain's DNS. Only someone who controls the site or the domain's settings could do either. Let's Encrypt then checks the answer from several network locations at once, which makes it much harder for an attacker to fake, and publishes the finished certificate to public Certificate Transparency logs.

It is closer to a courier confirming that you can receive post at an address than to a reference check on whoever lives there. That is why issuing a certificate can be fully automatic, and also why it says nothing about your business. It also means every renewal repeats the test, so renewal depends on your domain still pointing at the right server. If your DNS is halfway through a move, the check can fail.

Certificates are getting shorter lives, on purpose

Let's Encrypt certificates have lasted 90 days. Under a schedule it announced in December 2025, the default falls to 64 days for certificates issued from 10 February 2027, and to 45 days from 16 February 2028. The period in which a successful domain check can be reused shrinks too, from 30 days to seven hours by 2028, which means your domain will have to pass the check more often.

This is not one company's quirk. Let's Encrypt says the change is required by the CA/Browser Forum Baseline Requirements, the industry rulebook for publicly trusted certificates, and that all publicly trusted certificate authorities will be making similar changes. The aim is to limit how long a stolen key or a wrongly issued certificate stays useful.

The practical upshot is that a certificate expiring every few weeks has to renew itself, and paying for a certificate won't exempt you. What matters is knowing who looks after renewal, and who hears about it if renewal fails.

Chrome is making HTTPS the default

In October 2025, Google announced that Chrome 154, due in October 2026, would switch on a setting called Always Use Secure Connections by default. Chrome tries the HTTPS version of every address first. If a public website can't be reached that way, Chrome asks the visitor's permission before opening it.

Google's reasoning is that progress towards HTTPS has largely plateaued since around 2020, and the plain HTTP links that remain are a weak spot: an attacker can hijack the navigation and load something else entirely in its place.

For a small business, the homepage is rarely the problem. Because Chrome tries HTTPS first, what matters is that every address you have ever published actually works over HTTPS: an old landing page on a subdomain, a booking page hosted somewhere else, the web address printed on last year's flyers. Any of those that only works over plain HTTP is where your visitors will meet the warning.

What to check after switching on HTTPS

Switching on a certificate is often a single setting. Making the whole site behave takes a little longer, and three things are worth checking.

First, redirects. Every plain HTTP address should send visitors to the same page over HTTPS, not drop them on the homepage. Mozilla's guidance is to redirect to the same resource on HTTPS and to keep the same domain name for that first step: move visitors from http to https first, and only then from the bare domain to www, or the other way round.

Second, mixed content: an HTTPS page that still loads a file over plain HTTP, often because an image or script address was typed in full years ago. Browsers block insecure scripts outright, which can quietly break a menu, a form or a payment button. Insecure images are treated more leniently but still trigger mixed content warnings. Open your browser's developer tools, choose the Console tab and reload each important page; mixed content is reported there.

Third, and only once everything above is reliable, ask about HSTS. It is a setting that tells browsers to use HTTPS for your site every time, even when someone follows an old http link. The trade-off is that browsers then stop letting visitors click past certificate errors, and they remember the instruction for as long as you specify, often months or years. If a certificate ever lapses, returning visitors are stuck at an error page until it is fixed. Mozilla also cautions that extending it to all subdomains can lock out any subdomain that doesn't yet support HTTPS.