SSL Certificates and HTTPS

What HTTPS protects, and what it does not

The most useful thing a hosting company can tell a non-technical business owner about HTTPS is that it does not mean the site is secure. It means the connection is private. Conflating the two is how people end up trusting the wrong websites and neglecting the things that actually protect their own.

What HTTPS does protect is the contents of the connection from anyone positioned along its path: the coffee-shop wireless network, the internet provider, a compromised router at either end. It stops passive eavesdropping, it stops passwords and card numbers being read off the wire, and it stops content injection — a network operator inserting advertising into your pages, or an attacker inserting a script. It also enables the modern, faster protocols browsers use, which is a real if unglamorous benefit.

What HTTPS does not protect is almost everything else. It does not mean the site is honest, safe, malware-free, or operated by a real business — phishing sites carry valid certificates, because basic certificates are free and automatic for criminals too. It does not protect data once it has arrived on the server, and it does nothing against a compromised administrator password, an outdated plugin, a defacement or a database breach.

The padlock certifies the pipe, not the people at either end. That is the entire meaning of the symbol, and it is worth knowing both as a site owner and as somebody who buys things online.

SSL, TLS, and what the certificate actually proves

Two pieces of vocabulary, then the mechanism.

"SSL" is the wrong word and everybody uses it anyway. SSL was the original protocol; it was deprecated and replaced by TLS years ago. Every certificate sold today as an "SSL certificate" is a TLS certificate. We use the old word here because it is what customers search for, but nothing on your server is running the old protocol.

The mechanism is straightforward. A certificate binds a domain name to a public key and is signed by a Certificate Authority browsers already trust. On connection the server presents it and proves it holds the matching private key; the two sides negotiate a session key, and everything after that is encrypted in transit.

What the Authority verified before signing is the part worth understanding. Domain Validation — the type nearly every small-business site uses — proves exactly one thing: whoever controls this domain asked for this certificate. It is confirmed automatically, by placing a file on the web server or publishing a record in DNS. No human checks who you are and no business registration is examined. That is all the padlock has ever meant, and it is enough for its purpose.

Organization Validation and Extended Validation certificates involve checking company records before issuing. That vetting used to appear to visitors as a green company name in the address bar. Chrome removed the display in version 77 in September 2019 and Firefox followed in version 70 a month later, so there is now no visible difference to a normal visitor between a free certificate and an expensive one.

Let's Encrypt, and the safety net that went away

Let's Encrypt is a non-profit Certificate Authority that issues certificates free of charge, automatically, through a standard protocol called ACME. Its certificates are valid for 90 days by default, and it recommends renewing at 60 so there is a month of margin if something goes wrong. Since early 2025 it has also offered an optional six-day profile.

These are the certificates every competent shared host issues automatically. They are cryptographically identical to a paid certificate of the same type, so a host charging a separate annual line item for a basic certificate in 2026 should be asked what you are buying.

One change caught a great many people out. Let's Encrypt stopped sending expiration reminder emails on 4 June 2025. For years an expiring certificate generated a warning email, which functioned as an informal safety net for anybody whose automation had quietly stopped working. That net is gone, and Let's Encrypt's own announcement ending the service points users at third-party monitoring instead.

So certificate monitoring stopped being filler and became a real service — not because certificates are fragile, but because the failure is now silent right up to the moment the site starts showing every visitor a full-page security warning.

Certificate lifetimes are shrinking on a published schedule

This is the change most hosting pages have not caught up with, and it converts renewal from a chore into an engineering requirement.

The CA/Browser Forum — the body where the Certificate Authorities and the browser makers set the rules together — passed ballot SC-081v3 on 11 April 2025, establishing a fixed schedule of reductions in the maximum lifetime of a public certificate:

• Until 14 March 2026: 398 days.
• From 15 March 2026: 200 days. This is already in force.
• From 15 March 2027: 100 days.
• From 15 March 2029: 47 days, with the permitted reuse of domain validation data falling to 10 days.

Some Authorities issue a day or two under the cap for safety margin; DigiCert moved to 199 days in February 2026. The reuse period for organization identity data in the more heavily vetted certificate types also dropped from 825 days to 398 on the same date.

The consequence is simple and non-negotiable: manual certificate renewal is finished. A yearly calendar reminder was a workable habit when certificates lasted over a year. At 200 days it is a scheduled outage waiting for the one time somebody is on vacation, and at 100 days next March it stops being defensible at all. Automated renewal through ACME — which is exactly what Let's Encrypt was built for and what any competent host runs by default — is now the only sane arrangement. If your certificate is not renewing itself, that is the finding, regardless of who issued it.

What Google actually said about HTTPS and rankings

This one attracts more folklore than almost any topic in search, so here is the primary source rather than a paraphrase of a paraphrase. Google announced HTTPS as a ranking signal on 7 August 2014, and said this, in full:

For now it's only a very lightweight signal—affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content—while we give webmasters time to switch to HTTPS.

That is the whole of it. Fewer than one percent of global queries, explicitly lighter than content quality. Google has never published an updated weighting in the years since, which means anybody telling you that HTTPS is a significant ranking factor is extrapolating from nothing. Google's original announcement is still online and still says what it said.

So why is HTTPS mandatory in 2026 despite a ranking effect too small to observe? Because of the browser, not the search engine. Chrome and every other modern browser mark unencrypted pages "Not secure" in the address bar, and interrupt insecure form submissions with warnings. A visitor from Gun Barrel City who lands on a page announcing it is not secure does not evaluate the risk. They leave. That cost dwarfs any ranking consideration, and it is the honest reason to have HTTPS on every site.

What actually goes wrong

Four failures account for nearly everything we see.

Mixed content

The page itself loads over HTTPS but pulls an image, script or stylesheet over plain HTTP. Browsers block the active kind outright — scripts and embedded frames simply do not load, so the site visibly breaks — and flag the passive kind by removing the padlock. It is almost always caused by hardcoded HTTP addresses left in the database after a migration or after HTTPS was first enabled, and it is fixed with a search and replace that understands serialized data rather than a blunt one that corrupts it.

The certificate installed but the redirect never configured

Both versions of the site continue to serve. Visitors arriving at the unencrypted address see the "Not secure" warning anyway, search engines see two copies of every page, and analytics splits in half. Installing the certificate is half the job; forcing every request to the secure version is the other half.

Encryption that stops at the middleman

A content delivery network is frequently sold as the way to obtain a certificate, and one configuration deserves naming: a mode in which the network serves visitors over HTTPS while connecting to your actual server over plain HTTP. The padlock appears, the visitor is reassured, and the leg between the network and your server is unencrypted. If we find that on a site we take over, we treat it as a finding, not a feature.

Wildcard certificates renewed by hand

A wildcard certificate covers every subdomain at once and requires DNS-based validation, which is fiddlier to automate. So it is the certificate people most often renew manually, and the one that most often expires.

When you do not need to buy anything here

We could sell certificates. We would rather explain why you almost certainly should not buy one.

Paid certificates are unnecessary for essentially every small-business website. A free Domain Validation certificate is cryptographically identical to a paid one of the same type, is trusted by every browser, and renews itself. If a host or designer charges an annual fee for a basic certificate, question the line item. The honest exceptions are narrow: a contract requiring a certificate with a warranty attached, a legacy device that does not trust the free Authority's root, or a documented reason to want vetted identity information inside the certificate.

Extended Validation certificates are not needed by anyone selling to consumers. The green company name in the address bar was the entire consumer-facing reason to buy one, and browsers removed it in late 2019.

You do not need a content delivery network to get HTTPS. Your host can issue and renew a certificate directly, at no cost. A CDN is a reasonable purchase for other reasons — genuinely global visitors, heavy traffic, absorbing attacks — but not for a business whose customers all live within thirty miles of Cedar Creek Lake.

You do not need HSTS preloading. Submitting your domain to the browsers' preload list is easy and getting it removed takes months, during which your site cannot be served without encryption at all. That is a real risk for a small business and it solves a problem you do not have. A plain permanent redirect covers the need.

You probably do not need a paid certificate monitoring service either, unless your renewal is not automated. If your host runs automated renewal properly, monitoring is a belt on top of braces. If any certificate is renewed by a person, it must be monitored, because since June 2025 nobody sends the warning email.

The one thing that is not optional is HTTPS itself. There is no small-business case for skipping it in 2026 — a rare instance where the honest answer is simply yes, always, and it should cost you nothing.