Your certificate is valid. You checked it, it has months left, the authority is a real one. The browser still shows "Not secure" next to your address.
These are not in conflict. The padlock reports on the whole page, not just the certificate, and there are four distinct causes of that warning. Only one of them is a certificate problem. Working out which you have takes about a minute.
Start by separating the two kinds of warning
Before diagnosing anything, notice which warning you are getting, because they mean different things.
A full-page interstitial — a red or grey screen that blocks the site entirely, saying "Your connection is not private" with an error code — is a certificate failure. The browser refused the connection. Causes 1 and 2 below.
A "Not secure" label in the address bar, with the page loading normally behind it, is not a certificate failure. The connection worked. Causes 3 and 4.
People describe both as "my SSL is broken", but they have nothing in common. If the page loads, stop looking at the certificate.
Cause 1: the certificate does not cover this hostname
The most common genuine certificate failure, and the easiest to misread, because the certificate really is valid — just not for the name you used.
A certificate for example.com does not automatically cover www.example.com. They are different names, and the certificate has to list both. Plenty of certificates list only one, usually because whoever requested it typed one name into the form.
Wildcards are narrower than people assume. *.example.com covers shop.example.com and www.example.com, but not eu.shop.example.com — a wildcard matches exactly one label — and not the bare example.com either. A wildcard certificate that does not separately list the apex will fail on your root domain.
Run the site through the SSL Checker and read the Hostname match result. It performs the same RFC 6125 matching a browser does and tells you which name matched, or that none did.
The fix is to reissue the certificate with every hostname you serve listed. If you only intend to serve one, redirect the other — but note the redirect happens after the TLS handshake, so the certificate must still be valid for the name being redirected away from. A redirect does not rescue you from a certificate that does not cover the name.
Cause 2: the chain is incomplete
The failure that works perfectly on your machine and fails for a large share of your visitors, which is what makes it so persistent.
Your certificate is signed by an intermediate certificate, which is signed by a root the browser already trusts. Your server must send its own certificate and the intermediates, so the browser can follow the links up to a root it recognises.
If the server sends only its own certificate, some clients can recover — desktop browsers often cache intermediates from other sites, or fetch the missing one automatically. Many clients cannot: older Android devices, curl, and most programming-language HTTP clients simply fail.
So the site works for you, works for your colleague, and fails for a segment of visitors and every API client. Nobody reports it, because the people affected assume your site is down and leave.
The SSL Checker reports the number of certificates presented and flags a chain of one as a failure. The fix is to install the full chain file your authority supplied — usually named fullchain.pem or described as a bundle — rather than the certificate on its own. There is a longer walkthrough in fixing an incomplete certificate chain.
Cause 3: mixed content
Here is the one that produces "Not secure" on a page that loads perfectly, with a certificate that is completely fine.
Your page is served over HTTPS, but something on it — an image, a stylesheet, a script, a font, an iframe — is loaded over plain HTTP. The browser downgrades its assessment of the whole page, because an attacker who can modify that one HTTP request can affect the page regardless of how good your certificate is.
Browsers treat two categories differently. Active mixed content — scripts, stylesheets, iframes — is usually blocked outright, which breaks layout or functionality. Passive mixed content — images, video, audio — is often loaded anyway but downgrades the padlock.
Finding it takes seconds: open the browser console, reload the page, and look for warnings naming a specific http:// URL. The console tells you exactly which resource is at fault.
Common sources, roughly in order of likelihood:
- Hard-coded
http://URLs in page content, especially old blog posts with images pasted in years ago. - A CMS with its site URL still configured as
http://. In WordPress this is the Site Address setting, and it affects generated links across the whole site. - Third-party embeds — old widgets, tracking pixels, analytics snippets — that still use
http://. - A database full of absolute
http://URLs from before the site moved to HTTPS.
The fix is to change the URLs. Use protocol-relative or absolute https:// URLs, or run a search-and-replace across the database if the problem is historical. Adding upgrade-insecure-requests to your Content-Security-Policy header will paper over it by rewriting requests at the browser, which is a reasonable stopgap but leaves the underlying URLs wrong.
This is the one thing the SSL Checker cannot see. It inspects the connection, not the page. If all five certificate results pass and the browser still says "Not secure", mixed content is the overwhelmingly likely answer, and the browser console is the right tool.
Cause 4: the page is not on HTTPS at all
Worth ruling out, because it is embarrassing and common. Check the address bar: if the URL starts http://, the browser is correct and there is nothing to diagnose.
This usually means the site works over HTTPS but does not redirect to it, so anyone typing the bare domain gets the insecure version. The fix is a permanent redirect from HTTP to HTTPS at the web server, followed by an HSTS header once you are confident it works — that tells browsers to go straight to HTTPS in future without the redirect round trip.
Introduce HSTS carefully. It is cached by the browser for the duration you specify, so a long max-age set before HTTPS is fully working is difficult to undo.
If the site is on a hosted platform
The four causes above are the same everywhere. What changes on a hosted platform — a site builder, a managed WordPress product, or a shared control panel — is that the certificate is not yours to install. The platform issues and installs it; your job is to let it. That rules out most of the fixes above and narrows the diagnosis to three things.
Issuance never completed, because DNS is not fully pointed at the platform. A certificate authority verifies control of a name before it issues for it, and that verification runs against live DNS. If the domain still resolves somewhere else — an old host, a parked page, a half-updated set of records — issuance quietly never finishes and the platform serves the site without a certificate. This is the usual state immediately after moving a domain, and it presents as a certificate problem when it is a DNS problem. Confirm where the name actually resolves with the DNS Checker before touching anything else.
A certificate exists but HTTPS is not enforced. Most platforms expose one switch for this, labelled something close to "Force HTTPS", or an SSL mode offering a secure and an insecure setting. Left off, the site answers on both protocols and anyone typing the bare domain gets the plain HTTP version — cause 4 above, with a one-click fix. This is the answer when the padlock appears on some visits and not others.
Mixed content you added yourself. The platform serves its own assets over HTTPS. What it cannot control is what you pasted into a code block, a custom embed, a third-party widget, or an old imported post. Cause 3 applies unchanged, and the browser console still names the offending http:// URL.
Which of the three it is varies by platform, in a fairly predictable way. Builders that issue certificates automatically — Squarespace, Wix, Shopify — fail almost exclusively on the first and third: DNS that never finished pointing, or an insecure SSL setting left on, or an embed you added. Control-panel hosts such as Hostinger's hPanel and GoDaddy's hosting products issue a free certificate but often expect you to activate it for each domain and switch on the HTTPS redirect separately, so a site can sit for weeks with a valid certificate installed and no redirect in front of it. Older GoDaddy accounts add a fourth possibility: a certificate bought as a separate product and never installed against the site it was bought for.
The practical consequence is worth stating plainly. If you are on a hosted platform and the SSL Checker reports a valid certificate that covers your hostname with a complete chain, stop looking for a certificate to install — there is nothing to install, and the problem is a redirect setting or a resource on the page. If it reports no certificate at all, or one issued for the platform's own domain rather than yours, issuance has not completed: go back to DNS first, then to the platform's support, because the issuing step happens on their side and only they can retry it.
Working through it
- Does the page load, or is it blocked? Blocked means a certificate problem — continue to step 2. Loads means mixed content or plain HTTP — skip to step 4.
- Run the SSL Checker. It separates trust, expiry, hostname match, chain and TLS version, so the failing one is named rather than lumped into "SSL error".
- Fix what it names. Hostname mismatch means reissue with the right names. Chain of one means install the bundle. Expired means renew, and find out why renewal stopped.
- On a hosted platform, check DNS instead. You cannot install a certificate there, so a missing one means issuance never completed — confirm the domain resolves to the platform with the DNS Checker.
- If the certificate results all pass, open the browser console and look for mixed content warnings naming an
http://resource. - Check the address bar to confirm you are actually on
https://.
The short version
A blocking interstitial is a certificate problem; a "Not secure" label on a working page is not. Check the certificate for hostname coverage and chain completeness with the SSL Checker, and if it comes back clean, the answer is in your browser console — something on the page is still loading over HTTP.