Problem
Chrome says “Not secure” on your client’s site
Three unrelated faults produce the same word in the address bar. Until you have told them apart, you are repairing at random.
Open the address over https:// and watch what happens. A warning screen before the page: it is the certificate. The page loads with a grey chip: it is mixed content, and the console names the culprit. The address drops back to http://: the redirect is missing.
Do this right now
Three moves, and the first is a glance. It saves you from reissuing a certificate that is perfectly fine.
Look for a screen before the page
1 minIf the browser shows a warning before you reach the site, the fault is the certificate and nothing else: go and fix that, the rest can wait. If the page loads normally and only the chip in the address bar has changed, the certificate is fine and the cause is inside the page.
Open the console and search for “Mixed Content”
3 minThe browser console prefixes these warnings with “Mixed Content” and gives the exact address of the offending resource. It is usually an image, a font, a stylesheet or a script requested over http:// on a page served over https://. Fix the resource, not the page: most of the time a single URL is responsible, and it came from content rather than code.
Check the redirect, on the bare domain and on www
5 minRequest the address over http:// and see where you land. A permanent redirect should send you to the https:// version of the same name. Test both entry points: the classic case is a bare domain redirected correctly and a www left in the clear, or the other way round.
What the console actually says
The browser does not only grey out the chip: it names the resource that downgraded the page. That is the line to look for, and the only one that saves you time.
The page loads normally. No warning screen came before it.
Mixed Content: … requested an insecure element 'http://example.com/logo.png'
The padlock is gone from the address bar, replaced by “Not secure”.
- Page loads, no screen before it: the certificate is valid. Do not reissue it, you would lose half an hour on a part that is working.
- The console prefixes these messages with “Mixed Content” and quotes the offending address. That is your culprit, already named. Filter the console on that phrase instead of rereading the code.
- The chip is a consequence, not a cause. It clears on its own once the last cleartext resource is fixed — reload with the cache emptied before you conclude anything.
Three symptoms, three faults, three moves
Open the address over https:// in a private window — so your own cache cannot lie to you — and find the branch that describes what you see.
What exactly do you see when you open the address over https://?
- A warning screen before the page
It is the certificate.
The code under the message names the fault: expired, hostname not covered, or incomplete chain. Nothing else can be fixed until that one is.
- The page loads, chip says “Not secure”
It is mixed content.
A resource is requested over http:// on a page served over https://. The console names it; fix the resource address, not the page that calls it.
- The address drops back to http://
The redirect is missing.
The site can answer over HTTPS, but nothing forces the switch. Add the permanent redirect, on the bare domain and on www.
The four traps of this particular fault
They are the reason people announce “it’s fixed” twice before it is true.
The www everyone forgets
The certificate covers the bare domain, the redirect does too, and www stays in the clear. A good half of visitors still type the www, and your own test never catches it because you do not.
The image the client uploaded
Mixed content is not always in the code: it arrives through the content management system the day somebody pastes an image hosted elsewhere over http://. Fixing the code will not be enough, you have to fix the content.
Your own cache
After the fix your browser keeps showing the old state for a while. Reload with the cache emptied, or test in a private window, before you tell the client it is done.
HSTSadded too earlyThe
HSTSheader tells browsers to accept this site over HTTPS only, for as long as you declare. Added before everything works, it makes the site unreachable without even offering the “proceed anyway” link — and you have to wait out the duration you declared.
Why it happened
Because “secure” is not a setting, it is an outcome: the certificate has to be valid, the page has to be served over HTTPS, and everything the page loads has to be too. One of the three slipping is enough to lose the label.
The most common case is not a misconfiguration, it is content added after launch. The site shipped clean; six months later somebody pasted an image, embedded a map or dropped in a tracking script over http://, and the page was downgraded without anything visibly breaking.
The other common case is a half-finished migration: the site answers over HTTPS, but the old HTTP redirect was never restored, or it was only applied to one of the two hostnames.
How to avoid it next time
Put the check in your handover routine: bare domain and www both answer over HTTPS, both redirect, and the console is free of “Mixed Content” on the three busiest pages. Three minutes at handover against half a day six months later.
Block the cause rather than its effects: if the content management system lets editors paste external addresses, it will produce mixed content sooner or later. A written instruction to the client plus a periodic check beats fixing this one image at a time.
And watch the state from the outside, continuously. A downgraded page triggers no alert, breaks no form and appears in no log: nobody notices before a customer does, sometimes months later.
Rule out the certificate in thirty seconds
For the first branch of the tree: the tool reads the certificate actually served, its end date, the names it covers and the state of its chain. If it comes back green, look at the content instead.
The kind of decay that breaks nothing.
DomainVigil rereads the certificate, the redirect and the site’s response the way a visitor would, several times a day, across every client domain. Five domains free, forever.
Five domains free, forever. No card required.