Technote

Security Practical

Series Before your first security incident Part 6 of 8

SSL is on, so why is there no padlock?

The certificate is fine, yet the address bar shows a warning. The cause is usually one leftover http:// inside the page — and there is a set order for finding it.

You have a certificate, the site loads over https://, and yet the padlock is missing or the address bar says “not secure”. The certificate is not the problem. This is mixed content, and both its cause and its cure are well defined.

What the padlock is actually claiming

The padlock does not mean “this page is safe”. It means “everything used to build this page arrived over an encrypted connection”. So a single image or one script still loaded over http:// is enough for the browser to decide that promise is broken.

Not the certificate but one line inside the page decides the padlock

It is not only cosmetic. Browsers block outright higher-risk resources such as scripts and stylesheets when they arrive over http://. “Why is the layout broken on this page only?” frequently traces back to exactly this.

Where it hides

There is an order to the search. Open your browser’s developer tools and read the console: it names the offending URLs directly. From the URL you can tell which of the following it is.

Sources of mixed content — only the fourth cannot be fixed on your side

The most common by far is old absolute URLs in the database. Posts written before SSL was enabled carry image addresses beginning with http://, and changing a setting does not rewrite them.

The fourth item is different in kind. If an external service does not offer an encrypted connection, you cannot fix it from your side and must replace the service. It is rare now, but old analytics scripts and banners still turn up this way.

The order of the fix

Start under Settings › General and confirm that both the WordPress address and the site address begin with https://. If they do not, everything below is wasted effort.

Next, replace the old addresses stored in the database. Do this only after a backup — get the replacement scope wrong and it is hard to undo, which is where the restore drill from the previous part earns its keep. If doing it directly feels risky, a plugin that rewrites addresses at output time leaves your data untouched.

Finally, confirm that visitors arriving over http:// are redirected to https://. Without that, anyone following an old link or a stale search result keeps landing on the unencrypted version.

Verifying afterwards

Do not check only the home page. Open a blog post, your contact page and any payment screen and look at each padlock. Mixed content appears per page, so a clean home page and a warning on one specific article is entirely normal.

Articles on certificates and server configuration live in the servers and infrastructure archive, and if you want the padlock state watched across the whole site on a schedule, InfraGuard monitoring covers this check.

Next part

The next part returns to the login — this time the screen rather than the account. We will be honest about what rate limiting and moving the login URL each genuinely do.

More on this topic

All technotes

Security Practical

The first hour after you discover a compromise

The most common mistake in this moment is deleting things in a hurry. Here is what to stop first, what to preserve, and in what order to recover…

Founders 8 min read

₩270,000 · Join the program