What a Padlock Tells You About Your Website in 2026
What a padlock tells you about your website
Strip away the symbolism and the padlock certifies two things: the hostname in the address bar was signed by a certificate authority, and the connection to that host is encrypted. In Chrome 117, shipped in September 2023, Google went further and removed the icon from the address bar altogether. The May 2023 announcement on the Chromium blog argued the icon implied more than the connection it describes, and that had been true for years: the padlock said nothing about the people or the code behind the site.
That gap matters when the padlock gets read as a safety rating. A phishing page can hold a perfectly valid certificate, because issuers like Let’s Encrypt run domain validation, not a review of intent; their FAQ spells out what a certificate covers and what it does not.
If your site did not change and the icon disappeared anyway, the change was in the browser. Check the browser version before booking a developer.
Check 1: read the name behind the padlock
Click the icon at the left edge of the address bar, open the connection details, and read the certificate line. The field that matters is the Subject Alternative Name, the list of hostnames the certificate was signed for. The rule is exact matching: our certificate for www.mtufaildiagnosticcenter.com does not cover mtufaildiagnosticcenter.com, and the reverse misses just the same; that is why the diagnostic center holds two certificates instead of one.
Two patterns cover most small-business sites, and we run both. On warasat.com.pk a wildcard certificate signed for *.warasat.com.pk covers the bare domain, www, and any subdomain added later, with one renewal for all of them. On dev2production.com the bare domain and www each carry their own certificate. Both patterns work; only a missing entry for the hostname a visitor actually typed breaks the padlock.
What the probe returned for our eight hostnames this morning, September 27, 2026:
| Hostname | Certificate signed for | Expires (UTC) |
|---|---|---|
| dev2production.com | dev2production.com | Dec 8, 2026 |
| www.dev2production.com | www.dev2production.com | Dec 7, 2026 |
| warasat.com.pk | *.warasat.com.pk, warasat.com.pk | Dec 15, 2026 |
| www.warasat.com.pk | *.warasat.com.pk, warasat.com.pk | Dec 15, 2026 |
| mtufaildiagnosticcenter.com | mtufaildiagnosticcenter.com | Dec 7, 2026 |
| www.mtufaildiagnosticcenter.com | www.mtufaildiagnosticcenter.com | Dec 6, 2026 |
| truckaxic.com | truckaxic.com | Dec 17, 2026 |
| www.truckaxic.com | www.truckaxic.com | Dec 16, 2026 |
All eight came from Let’s Encrypt and negotiated TLS 1.3 when we connected, from the Vercel-hosted domains to warasat.com.pk on Apache. The dates are deliberately spread out: a shared renewal day is a shared point of failure.
Check 2: read the expiry date before it reads you
Certificates expire on purpose. Let’s Encrypt issues by default for 90 days and added a six-day short-lived option in 2025, because short lifetimes limit the damage of a stolen key and force renewal to be automated (their FAQ, updated April 2025). Renewal is also deliberately randomized in time, so a million hosts do not stampede the same minute; the request is written into their integration guidance.
When a certificate lapses, the browser does not degrade politely. Visitors hit a full-page warning, and on a host with HSTS, covered below, there is no click-through. A lapsed certificate takes the site away from every visitor until someone renews it.
The command we run on every hostname at handover, and again each quarter:
echo | openssl s_client -connect warasat.com.pk:443 -servername warasat.com.pk 2>/dev/null | openssl x509 -noout -dates -ext subjectAltNameIts output for warasat.com.pk this morning:
notBefore=Sep 16 19:00:20 2026 GMT
notAfter=Dec 15 19:00:19 2026 GMT
X509v3 Subject Alternative Name:
DNS:*.warasat.com.pk, DNS:warasat.com.pkTwo lines answer check 2, the SAN line answers check 1, and the whole thing is one round trip.
Check 3: read the references behind the page
A valid certificate does not stop a page from reaching back over plain HTTP. A page served over HTTPS that loads a script, an image, or a frame from http:// has mixed content. MDN’s mixed content guide splits it in two: active content such as scripts and iframes is blocked outright, and passive content such as images and audio is blocked or rewritten to HTTPS in current browsers, with Chrome blocking the blockable set since version 79. The practical result: the padlock shows a warning state, or the resource never loads, which is why an old site sometimes loses a map or a widget after someone finally turns HTTPS on.
This check needs no tool, only patience. Open the page, view its source, and search for http://. Every hit with src=, href=, or url( in front of it is a fetch waiting to happen; the rest is text. We ran the scan as a script this morning over the served HTML of all five of our live hostnames and found zero fetchable http:// references on all five.
The number was not literally zero, and the difference is the lesson. The HTML on truckaxic.com carries 20 strings that start with http://, and every one of them is the SVG namespace declaration, a name an XML parser expects rather than a request a browser fetches. An http:// string only becomes a problem when something fetches with it. Look at what precedes each hit before you edit anything.
Mixed content is one item on a longer list; the security baseline we apply to web apps covers the rest.
Two hostnames, one redirect chain, one habit
Open truckaxic.com in a fresh browser session and watch where it lands: HTTP 308 to HTTPS, then 308 to the www hostname, then the page. Dev2production.com runs the same shape. Two redirects is our bar. More than two is a laggard waiting for someone to fix it, and both of these move to one with a certificate that covers both names.
Warasat.com.pk sits on a wildcard certificate and answers on both hostnames without a redirect, which is why it serves the bare domain and www from one SAN list. The diagnostic center carries separate certificates for its bare domain and www, both names valid, pages answering on either address.
The habit that makes the padlock stick is HSTS, Strict-Transport-Security, one response header. Ours run a max-age of 31,536,000 seconds on warasat.com.pk, with includeSubDomains, and 63,072,000 elsewhere. MDN’s Strict-Transport-Security page spells out what a browser does once it has seen the header on a trusted connection: it rewrites http:// addresses to https:// before the request leaves, and it refuses to click through certificate warnings while the policy is active. That is the difference between one lapsed certificate costing you a visitor and costing you the whole domain.
Every HTTPS site should end up with this pair: one certificate per hostname you serve, one HSTS header on all of them.
What to fix when a check fails
Failures rank by the cost of leaving them in place.
First, a lapsed certificate. Renew it, redeploy, and the padlock returns on the next load; the openssl command from check 2 tells you which host and how much time is left. Let’s Encrypt certificates renew through the same automated client that issued them, which is why the expiry date is a maintenance item, not a project.
Second, mixed content. Rewrite the http:// references to https://, or drop them when a same-site copy exists. Scripts and iframes break first because browsers block them outright; images follow. If a third-party embed has no HTTPS endpoint, replacing it is part of the fix, not a compromise. This is the repair we run most after a redesign ships, and it is included in our maintenance and support work.
Third, a hostname the certificate does not cover, most often www after the bare domain was added. A wildcard certificate ends it, one renewal covering both names, the way warasat.com.pk runs today.
Two things we do not touch: SVG namespace declarations that merely contain the text http://, and the extra redirect hop itself. The first is not a resource, and the second is a preference, not a break.
Do not run this by hand if it needs to keep happening. Whatever renews the certificates needs to run without anyone remembering it, on a schedule, with a log of what renewed and when. We keep certificates, backups, and updates on that schedule with our own monitoring.
Where this sits in a launch
Certificate coverage, redirect shape, and mixed content are three checks on our launch list, and they pass before a domain goes live. Getting them right is cheap at build time and annoying after the fact, which is why they are default items and not options. The same reasoning put them in the security and observability baseline we wrote down in August.
The value is in the routine, not in the morning it takes. Run the three checks on a calendar, not once; the openssl line is a minute per hostname, the view-source scan is minutes more, and a repeat each quarter catches the certificate that quietly failed to renew. That cadence is the same one that keeps backups on schedule, and it is the part most owners skip.
If you would rather not hold the checklist, send the domain through the contact page and ask for the three-check report. It comes back with the dates, the hostnames covered, and any insecure references found, and it fits in an email.
FAQ
The padlock is there but the site still says “not secure”. What is broken? Mixed content on that page. Read the browser console: it lists every resource the page tried to load over http://. Fix the references to https:// or same-site copies and the warning clears.
How often do certificates renew? Every 90 days on the default Let’s Encrypt plan. The renewal is automated, and the point of the short window is to keep it that way. Six-day certificates are also available since 2025.
Can I fix mixed content myself? If the references are in your own templates, yes: it is a find-and-replace to https:// with a console check afterwards. If the warning survives the fix, the reference is inside a third-party embed, and the embed is what needs replacing.
Does HTTPS make the site faster? The modern TLS handshake is quicker than a plain connection: our probes negotiated TLS 1.3 on all eight hostnames this morning, and TLS 1.3 completes in a single round trip. Every HTTPS site we run also serves HTTP/2.