Why Chrome Says “Not Secure” (and What to Check First)

This page is the split: scheme versus certificate versus name versus cache. The TLS object itself is How SSL certificates work and how to check expiry. Headers after a good handshake are How to check security headers on a live site. A name that still resolves to last week’s IP is Why DNS changes aren’t showing. None of those articles is a license to probe hosts you do not operate.

DevOkk.com is a no-account toolkit. Image and PDF tools are built to run in the browser. Networking tools are not local-only. SSL Certificate Checker, HTTP Header Viewer, and DNS Record Lookup send the hostname you type so they can complete a lookup. That is the job. Type names you own or are allowed to test. DevOkk does not become a file host after the response comes back. The privacy policy and analytics still load on the page, same as the rest of the site.

The label is not the interstitial

Chrome uses more than one UI for “this is not a comfortable HTTPS page.” Mixing them is how a Friday deploy gets a useless cert reissue.

Gray “Not secure” on a page that loaded. Typical of the http:// scheme. The document arrived. There was no TLS for that navigation. Chrome is labeling the scheme, not arguing with a CA.

Full-page “Your connection is not private.” Typical of HTTPS that failed authentication: expired leaf, name not in SAN, unknown issuer, some captive portals. Error codes look like NET::ERR_CERT_COMMON_NAME_INVALID, NET::ERR_CERT_DATE_INVALID, NET::ERR_CERT_AUTHORITY_INVALID. The page body you wanted often never renders.

Broken lock or mixed-content warnings on an HTTPS URL. The HTML came over TLS. A subresource did not. Images over http:// are the quiet version. Scripts and iframes over HTTP are treated more harshly. The address bar can still look “almost fine” while DevTools is loud.

chrome:// pages. Settings, flags, GPU, and other internal surfaces are not websites. They are not HTTP and they are not HTTPS. They are not a padlock problem and they are not something SSL Certificate Checker can fetch. If the bar is showing a Chrome internal URL, you are not debugging TLS.

The search chrome says not secure often means the gray HTTP label. It also often means the red interstitial. Read the scheme first (http vs https vs chrome), then decide which layer you are in.

HTTP in the bar is a scheme problem

If the URL still starts with http://, Chrome is not confused. TLS never ran for that navigation. Renewing a certificate will not change the label until the next request is HTTPS.

That can be intentional (a device UI, a lab, a “we have not bought a cert yet” marketing page). Chrome still says Not secure. The product decision and the browser label are different questions. Shipping HTTP on a public hostname you care about is a finding even when nobody “hacked” anything. The launch pass that is supposed to catch this is A pre-launch checklist for a new web page.

Compare that to HTTPS that redirects from HTTP. Users type the bare name. The first hop may still be HTTP. HTTP Header Viewer on the http:// URL you operate should show a 3xx and a Location that is https:// for the same host (or the canonical host you actually want). If the viewer returns 200 HTML on HTTP, there is no redirect. If it returns HTTPS already, your laptop may be following HSTS and you are looking at a different first hop than a cold visitor.

The viewer sends the hostname. It is not DevTools on your cookies. It is not a port scanner. Use it on origins you are allowed to fetch. How to read the rest of the envelope is How to read HTTP headers when debugging a site.

Mixed content is HTTPS with HTTP leftovers

The document is https://. An <img>, stylesheet, or old embed still points at http://. Chrome treats active mixed content (scripts, XHR in older models, some plugins) more strictly than passive mixed content (images, video, audio). The user-visible result is a warning, blocked pixels, or a lock that does not match the “we turned on HTTPS” announcement.

This is not a certificate expiry. The leaf can be perfect. The HTML is the problem. CDNs that rewrite HTML but not a hard-coded asset host are a common source. So is a CMS that stores full http:// URLs in the database from 2016.

Do not treat mixed content as a puzzle to weaponize against someone else’s site. On a property you maintain, the comparison is: did the page handshake succeed, and are subresources still on HTTP? DevTools’ security or network panel on a page you own is the right microscope. A public header viewer will not list every image URL in the body.

A valid cert plus mixed images still fails a “looks professional” test. It is also a different ticket from “Chrome blocked the whole site.”

Name mismatch after a www cutover

You pointed www at a new host. The certificate on that host lists example.com only, or the old load-balancer hostname, or a wildcard that does not cover what you think it covers. Chrome’s interstitial will talk about privacy and names. People file it as Not secure. The leaf is the wrong names, not “HTTP.”

SAN versus CN still trips people who learned certificates from a 2012 panel. Modern Chrome uses Subject Alternative Name. www.example.com is not free because the apex is on the cert. A wildcard *.example.com does not cover the apex. One extra label (a.b.example.com) is not covered by a single-level wildcard. After a rebrand, type the hostname humans type, not the one the dashboard highlights.

SSL Certificate Checker reports the leaf the checker’s network saw for the name you entered. That sends the hostname on purpose (SNI). Checking a raw IP without the name can show a default vhost cert nobody in Chrome ever sees. Prefer the name. Do not point it at a competitor, a random government box, or an internal VIP you cannot authorize.

The companion explanation of chain, notAfter, and wildcards is the SSL guide. This article only needs the cutover pattern: DNS moved, TLS name did not.

Expired TLS is a clock, not a padlock style

notAfter in the past produces NET::ERR_CERT_DATE_INVALID (and cousins). Chrome will not “grace” a Let’s Encrypt leaf because you were going to renew on Monday. Staging clocks that are wrong look like expiry. Client clocks that are wrong look like expiry. The leaf can be fine.

Expiry is not mixed content. It is not HTTP. It is not “Chrome hates our brand.” Compare the date on the leaf to “did we actually ship the new cert to this hostname.” GeoDNS can present different leaves in different regions. The checker sees one vantage point.

Let’s Encrypt-style 90-day certs without automation are an operations problem that presents as a security UI. Purchased year-long certs that nobody calendared are the same UI. The checker is for names you operate. It is not a calendar product and not a stealth scan of the internet.

HSTS changes who even sees HTTP

Strict-Transport-Security tells a browser that has already seen a valid HTTPS response to skip HTTP next time (for max-age). A missing HSTS header is not why Chrome printed Not secure on a first-time http:// visit. HSTS is why a later visit never hits HTTP, and why a broken HTTPS setup can feel “stuck” once the browser has memorized the policy.

Preload lists are a stronger commitment. Do not treat preload as the same ticket as “we should redirect HTTP to HTTPS.” Header meaning and the usual gaps are in the security-headers guide. HTTP Header Viewer on an origin you own is how you see whether Strict-Transport-Security is actually on the response the edge sends. The viewer sends the URL. Only yours.

HSTS on a host whose certificate is wrong is a trap: browsers that already have the policy will refuse HTTP fallback and show the cert interstitial. That is working as designed. Fix the cert, do not hunt for a “disable HSTS” ritual on users’ machines.

Self-signed on localhost is expected

https://localhost with a certificate you minted is a development bargain. Chrome should complain. That complaint is not a production outage and not evidence that DevOkk’s checker is broken when it cannot see your laptop.

Public checkers cannot complete a handshake with 127.0.0.1 on your desk. They speak to public DNS names. If the task is “does our staging hostname on the internet present a publicly trusted leaf,” use the public name you control. If the task is “does my mkcert setup work,” stay in the browser on that machine.

Telling a whole company to click through certificate warnings trains people to click through certificate warnings. Localhost is the exception you already know is local. A public marketing site is not.

Captive portals impersonate a cert problem

Hotel, airport, and school Wi-Fi often intercept the first HTTPS request and present a portal. The certificate will not match the bank or the SaaS hostname you typed. Chrome’s UI looks like a name mismatch or an untrusted issuer because that is what the handshake was.

Compare: you are on a network you do not control, many unrelated HTTPS names fail the same way, and a HTTP captive page sometimes loads. That is the network in front of you, not an expired cert on your origin. Phone off Wi-Fi is a cheap split. It is not a scan of anyone else’s infrastructure.

A checker run from DevOkk’s network will not see your hotel portal. If the public checker says the leaf is fine and your laptop on café Wi-Fi screams, believe the split. You are not looking at the same path.

Parking pages, leftover A records, and the wrong leaf

The padlock fight is sometimes DNS. The name still points at a registrar parking server, an old “coming soon” host, or a previous tenant on a shared IP. That server presents a certificate for its name. Chrome reports a mismatch for your name. Teams reissue certificates on the new app that nobody is hitting.

DNS Record Lookup for A, AAAA, CNAME, and NS on the hostname people type. The tool sends the name to public DNS. It is not ipconfig /flushdns. Public new / local old is cache. Public still parking / dashboard claims the new A is the wrong zone or the wrong DNS host. Why DNS changes aren’t showing is that incident.

Then SSL Certificate Checker on the same name you own. If the leaf SANs are the parking brand, you do not have a Chrome bug. You have the wrong origin. Fix DNS (and wait the TTL you already advertised) before you rotate certs on a host that is not in the path.

IPv6 leftovers belong in the same bucket. You updated A. Stale AAAA still aims at a box with an old or default certificate. Dual-stack Chrome prefers v6. Half the office sees a clean padlock on v4-only networks. Lookup AAAA on purpose.

Do not use these tools to map hosts you do not own. “I am curious about their padlock” is not permission.

What a browser tool can and cannot prove

SSL Certificate Checker is a handshake from the checker’s network: names on the leaf, validity window, often the chain that was sent. It does not prove the business is honest. HTTPS encrypts the connection to that server. It does not encrypt the site away from the operator. A phishing host with a valid Let’s Encrypt cert for a lookalike name will padlock. Chrome’s Not secure label on HTTP is unrelated to whether a HTTPS site is a scam.

HTTP Header Viewer is the HTTP layer after (or instead of) TLS: status, Location, HSTS, cookies. It will not list certificate SANs. People paste a cert problem into a headers ticket and waste a cycle.

Neither tool is a penetration test. Neither stores your site as a hosted project. DevOkk.com does not host files. File-side tools on the same domain still load the site’s own analytics and privacy policy - that is not the same as uploading a certificate private key, which you should never paste into a web form.

If you need DevTools, use DevTools on a page you control. If you need a CA to issue a name, that is ACME or your vendor, not a blog post.

HTTP versus HTTPS versus “we proxied it”

A CDN in front of origin HTTP is still HTTPS to the visitor if the edge terminates TLS correctly. Chrome’s bar reflects the browser’s hop. Origin HTTP behind a good edge is a different architecture discussion than “the bar says Not secure.” If the bar shows HTTP, the browser did not use TLS for that navigation, whatever the origin does.

A reverse proxy that serves the wrong certificate for the SNI name is a name-mismatch incident, not mixed content. A proxy that forwards HTTP URLs into an HTTPS page is mixed content. Same company, different tickets.

Comparison, not a ritual:

• Scheme http:// → Chrome Not secure is the scheme. Look for redirects with the header viewer on your URL.
• Scheme https:// plus interstitial → leaf names, expiry, issuer, or a portal. SSL checker on a name you own; DNS if the origin is unexpected.
• Scheme https:// plus page loaded plus warnings → mixed content or a later subresource. Your own DevTools.
• Fine on the checker, bad on one laptop → local cache, VPN, split DNS, captive portal, hosts file.
• Fine in Chrome, bad in a JVM or old IoT → missing intermediate, not “Chrome is wrong.” The SSL guide covers the chain.

HTTP on purpose is still a finding

An internal wiki on HTTP, a printer panel, a “temporary” campaign microsite, and a local demo all have reasons. Chrome will still label public HTTP as Not secure. Users have been trained to distrust that label. Password fields and cookies on HTTP are worse than a brochure, but the brochure still teaches the wrong lesson next to your HTTPS product.

Compare that to HTTPS with a matching, unexpired, publicly trusted leaf and no mixed HTTP assets: Chrome will not print the gray Not secure scheme warning. You can still fail HSTS, cookie flags, and CSP. Those are the security-headers article, not this one. You can still fail Open Graph and titles. That is the pre-launch checklist.

Intentional HTTP is a product choice you can document. It is not invisible. If the hostname is public and you care how it looks in a screenshot, treat the scheme as part of the launch, the same way you treat a cert that does not include www. The checker and the header viewer exist to show what your name presents from the public internet - hostname sent, no account, no file locker, no excuse to aim them at machines that are not yours.