Few website messages create panic as efficiently as “Not Secure.” It can feel as if the whole site has suddenly become dangerous—especially when a certificate was renewed only yesterday. Take a breath before changing anything. The browser is reporting a symptom, and the wording or icon tells us which part of the connection needs attention.

There is no single “SSL issue” behind every warning. The main document may still use HTTP, the TLS certificate may fail validation, an otherwise valid HTTPS page may load an insecure resource, or one device may be seeing a local clock, proxy, antivirus, DNS, or cache problem. Fixing the wrong layer wastes time and can make a working deployment less safe.

Read the browser state before touching the server

  • The address begins with `http://`: the main document is not using TLS. Make HTTPS work, then redirect HTTP to the same HTTPS path.

  • A full-page privacy or certificate interstitial appears: identity or trust validation failed. Record the exact error code before continuing.

  • The page opens over HTTPS but security details mention insecure content: investigate HTTP subresources, form actions, downloads, or other mixed-content behavior.

  • Only one device, browser, or network fails: compare its clock, trust store, extensions, HTTPS-inspecting software, proxy, DNS answer, and cached state.

  • Only some users or regions fail: suspect inconsistent CDN edges, load-balancer nodes, IPv4 and IPv6 destinations, or split DNS rather than a browser cosmetic problem.

The triage map: symptom, check, next move

Plain HTTP main page

  • Check: inspect the address bar and the first document request in DevTools Network.

  • Likely cause: an old internal link, canonical URL, CMS setting, reverse-proxy scheme header, or missing redirect still selects HTTP.

  • Next move: prove the HTTPS destination works first, then add a server- or edge-level permanent redirect that preserves path and query.

Certificate validation failure

  • Check: note the browser error and test the exact hostname with SNI and hostname verification.

  • Likely cause: expiration, hostname mismatch, missing intermediate, untrusted issuer, not-yet-valid certificate, or an incorrect local clock.

  • Next move: repair the certificate, served chain, endpoint routing, or affected client—not the page HTML.

Mixed or insecure page content

  • Check: open the Console and Network panels, reload, and filter for blocked or http:// requests.

  • Likely cause: a hard-coded image, script, stylesheet, font, iframe, API endpoint, form action, plugin setting, or stored CMS URL.

  • Next move: update the source configuration or content to a genuine HTTPS URL and retest representative pages.

One-client or one-network failure

  • Check: compare the same hostname on a clean device and another network; verify date, time, DNS, proxy, and certificate issuer.

  • Likely cause: stale DNS or cache, an outdated trust store, a captive portal, enterprise proxy, or antivirus performing TLS inspection.

  • Next move: isolate the local component. Never solve it by weakening verification for everyone.

Confirm which URL the server is actually serving

Terminalbash
curl -I http://example.com/account?view=compact
curl -I https://example.com/account?view=compact

Treat the headers as a route trace, not a victory badge

  • curl -I retrieves response headers without downloading the response body.

  • The HTTP response should redirect to the intended HTTPS hostname while retaining the meaningful path and query.

  • Follow each Location value and look for loops, accidental redirects to HTTP, or a different hostname whose certificate is not valid.

  • A successful HTTPS status confirms an HTTP exchange for this client; it does not by itself prove that the page has no mixed content.

  • This is a documentation-only placeholder command. Run it against the affected hostname and record the real status and Location headers.

Ask the TLS endpoint to prove identity

Terminalbash
openssl s_client -connect example.com:443   -servername example.com   -verify_hostname example.com   -verify_return_error   -showcerts < /dev/null

Each option closes a common diagnostic blind spot

  • -connect chooses the network endpoint and port.

  • -servername sends Server Name Indication so a shared host, CDN, or load balancer can select the correct virtual host.

  • -verify_hostname checks that the certificate Subject Alternative Name covers the requested DNS name.

  • -verify_return_error turns a chain-validation error into a failed command rather than continuing the interactive diagnostic session.

  • -showcerts displays what the server sent; it is not a substitute for the verification result.

  • Review the leaf validity dates and intermediates. A server generally sends its leaf and intermediate certificates, while the trusted root lives in the client trust store.

  • This command is documentation-validated but not evidence about your endpoint until you replace the placeholder and run it from a representative client.

If the clock is wrong, a perfectly issued certificate can appear expired or not yet valid. If the hostname is absent from the certificate SANs, an HTTP redirect cannot rescue it: TLS validation happens before the browser receives any redirect response.

Look beyond the first edge that answers

Renewal often succeeds in the control panel while the live listener keeps an older certificate. A CDN may have its own certificate, the load balancer another, and the origin a third. One node may miss a reload; an AAAA record may lead IPv6 users to an abandoned server while IPv4 looks healthy.

  • Test every public hostname, including www, apex, API, checkout, and regional names that real users visit.

  • Compare DNS A and AAAA destinations and verify both address families when both are published.

  • Inspect individual load-balancer or origin nodes only with authorized operational methods that preserve the correct SNI and Host values.

  • Confirm the certificate deployed at the serving edge, not merely the newer file stored by an ACME client.

  • Retest from outside the hosting network so internal DNS, a private proxy, or an origin-only route does not hide the public failure.

A valid certificate cannot sanitize an HTTP resource

Once the main document has valid HTTPS, open Chrome DevTools, select Security to inspect the origin state, then use Console and Network while reloading. The warning may come from one old image URL in a database field, a theme stylesheet, an analytics snippet, a font, an iframe, or an API call that appears only after login.

  • Fix the source URL in the template, plugin, environment setting, or stored content.

  • Confirm the third-party origin genuinely supports HTTPS; changing the text from http to https cannot create TLS support.

  • Avoid blanket database search-and-replace unless the CMS supplies a serialization-aware migration and you have a tested backup.

  • Check several content types and authenticated states. A clean homepage does not prove that checkout, embeds, or older articles are clean.

  • Do not place critical meaning in a resource that the browser blocks; blocked active mixed content can break scripts, forms, and application calls.

When the warning follows one laptop

  • Correct the operating-system date, time, and timezone, then retry.

  • Update the browser and operating-system trust store instead of downloading a random CA certificate.

  • Try a clean browser profile to separate extensions and cached state from the website response.

  • Compare another trusted network; captive portals can intercept the first request before authentication.

  • In managed environments, ask the administrator whether an approved proxy performs HTTPS inspection and whether its root is deployed correctly.

  • Inspect the issuer shown to the failing client. An unexpected local or enterprise issuer reveals interception that a server-side certificate renewal cannot fix.

Turn renewal into a check, not a calendar hope

Terminalbash
openssl s_client -connect example.com:443   -servername example.com < /dev/null 2>/dev/null   | openssl x509 -noout -checkend 1209600

Monitor the certificate users receive

  • 1209600 is 14 days in seconds; choose a window longer than your realistic renewal and deployment recovery time.

  • openssl x509 -checkend communicates success or failure through its exit status, making it suitable for monitored automation.

  • The pipeline checks the served leaf certificate, not whether a renewed file exists somewhere on disk.

  • Monitor each hostname and edge path that matters, from an external location, and alert before expiry rather than on it.

  • Keep HTTP reachability, redirect correctness, certificate validation, and application health as separate signals so one green check cannot conceal another failure.

  • The placeholder was not executed against a user-owned host; verified therefore remains false.

A calm final pass before closing the incident

  1. Reproduce the exact warning and record its browser error code or insecure-resource URL.

  2. Verify the system clock and compare a second clean client.

  3. Confirm HTTP redirects to the correct HTTPS path without a loop.

  4. Verify hostname, SNI, dates, issuer, and chain against the public endpoint.

  5. Check IPv4, IPv6, CDN, load-balancer, and origin differences relevant to the deployment.

  6. Reload representative pages with DevTools open and remove mixed-content sources.

  7. Test browsers, API clients, and devices the service actually supports.

  8. Only after HTTPS is stable, evaluate HSTS with an intentional rollback and subdomain plan.

  9. Add expiry and endpoint monitoring, then document what failed so the next renewal feels boring.

That last word—boring—is the goal. A security warning should lead to a precise check, not a frantic collection of cache clears and unsafe bypasses. Once each layer has its own evidence, the browser stops feeling mysterious and starts behaving like a useful witness.

Continue the diagnosis

Primary references