How to Fix a Security Warning That Only Some Visitors See

Your site loads fine on your laptop, and a customer sends a screenshot of a security warning. You open the same link and see nothing wrong. A second visitor reports the warning, a third says the site is perfect. A warning that only some visitors see is rarely one broken thing. It is usually different setups meeting the same site, and only some of them hit the weak spot. Stop asking whether the site is broken. Ask who sees the warning, on which address, and with which error message.

Start with the exact report

Collect four details from each person who saw the warning: the exact address they used, including www or not, the exact error code or wording, the browser and device, and whether they were on home Wi-Fi, mobile data, or a work network. Those facts split almost every case. A warning on www but not without www points one way. A warning only on an office network points another. A warning naming an expired certificate points at a server still serving the old certificate. One naming an untrusted issuer points at the certificate chain.

Cause 1: the certificate does not cover the address they used

A certificate lists the exact hostnames it covers, in a field called Subject Alternative Names. Browsers check the address bar against that list and ignore the older Common Name field. A certificate for example.com does not cover www.example.com, and one for both does not cover shop.example.com. A wildcard such as *.example.com covers one level only, so it covers shop.example.com but not api.shop.example.com. Run your domain through our SSL Checker with www and without, and for each subdomain you use. If a name is missing, reissue the certificate with every name you serve. A redirect will not fix it, because the browser checks the certificate before following the redirect.

Cause 2: the certificate chain is incomplete

A browser builds a chain from your certificate, through intermediate certificates, up to a root it trusts. If your server sends only your certificate and leaves out the intermediates, some browsers fill the gap from certificates cached from other sites, and others refuse. That is why the same site can look fine in one browser and untrusted in another, and fail on a phone while working on your desktop. Install the full chain your provider supplied. With Let's Encrypt, point the server at the fullchain file rather than the certificate file alone. Then test in a browser that has not visited the site before, so a cached intermediate cannot hide the problem again.

Cause 3: an old certificate is still served somewhere

Renewing a certificate writes new files, but it does not always change what visitors are handed. Servers read the certificate at startup and keep it in memory, so a server never reloaded after a renewal keeps serving the old one. The trap multiplies when more than one machine answers for your domain: a load balancer, a second server, or a CDN edge can each hold its own copy. Check every place that answers the secure connection, reload each service after installing the new certificate, and verify from outside your network, on a phone using mobile data, that visitors receive the new expiry date.

Cause 4: the warning is on some pages, not the whole site

Sometimes the certificate is fine and the problem is page level. A page loaded over HTTPS that pulls in one image, script, stylesheet, or font over plain HTTP is mixed content: the connection is secure, but part of the page is not, so the browser drops the padlock or blocks the insecure part. It looks intermittent because it only affects pages with the insecure item, often one template, one old post, or one widget. Open the affected page, open browser developer tools, and read the Console tab, which names each insecure resource. Change those addresses to HTTPS, or replace a third-party resource that does not support HTTPS.

Cause 5: the problem is on the visitor's side

When only one or two people see the warning and outside checks look clean, look at their setup. A device clock set to the wrong date makes a valid certificate look expired or not yet valid. Old browsers may not trust a newer root certificate. Antivirus software and some corporate networks inspect secure traffic by presenting their own certificate, and if the browser does not trust it, every secure site warns. Ask whether the warning appears on other well-known secure sites, whether the clock is set automatically, and whether they are on a work network. If other sites warn too, the cause is theirs. Never tell a visitor to click through a warning where they sign in or pay.

Cause 6: different visitors reach different servers

After a DNS change or server move, some visitors reach the new server and others still reach the old one, because DNS answers are cached, and networks expire caches at different times. If the old server's certificate has expired, only visitors still routed to it see the warning, and the split fades as caches expire. Our DNS Propagation Checker asks resolvers around the world the same question at once, so you can see whether some regions still get the old address. If so, make sure the old server also serves a valid certificate until the change has fully spread. A cached Strict Transport Security policy can also keep one browser refusing the plain HTTP version after you remove the header, until the policy expires.

What to do first

Do not reinstall the certificate yet. Collect the four details from people who saw the warning, then run the www and non-www checks and the chain check. Most cases resolve at one of those steps: a missing name or a missing intermediate, both short fixes once named. If those checks are clean, look for a stale certificate on a second server or CDN edge. Set a reminder to check the certificate a week before it expires, so the next renewal is verified from the outside. Our HTTP Headers Checker also shows your security headers, including Strict Transport Security. Fix the cause that matches your reports, verify it as a new visitor would, and the warnings should stop for everyone.