Installing a certificate can feel like the finish line, so a warning icon afterward is maddening. The icon does not identify one universal “SSL problem.” It can represent a hostname or trust failure, an HTTPS page that fetches HTTP resources, an insecure form destination, or a browser-specific policy. Start with the exact browser message before changing the server.

Confirm the public URL and certificate identity

Any trusted external machinebash
host=example.com
printf "" | openssl s_client -connect "$host:443" -servername "$host" -verify_return_error 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates -ext subjectAltName
subject=CN = example.com
issuer=...
notBefore=...
notAfter=...
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

Read the certificate the real virtual host serves

  • SNI through -servername selects the certificate for that hostname on shared infrastructure.

  • The requested hostname must appear in Subject Alternative Name; a similar domain or only the other www variant is insufficient.

  • Validity dates must cover the current time on both client and server.

  • -verify_return_error exposes trust-chain failure rather than printing a certificate and implying success.

  • Test every production hostname and CDN/proxy edge, not only the origin IP.

Verify HTTP redirects to one canonical HTTPS URL

Any terminalbash
curl -sSIL --max-redirs 10 http://example.com/
curl -sSIL --max-redirs 10 https://example.com/
HTTP/1.1 301 Moved Permanently
Location: https://example.com/

HTTP/2 200

A redirect closes the plain-HTTP entry path

  • Port 80 should normally remain reachable and redirect to HTTPS rather than serve a second site.

  • Follow www and apex variants and ensure redirects do not loop or fall back to HTTP.

  • Update application canonical URLs, sitemap, OpenGraph URLs, and internal navigation to HTTPS.

  • A proxy must communicate the original scheme correctly so the application does not generate HTTP redirects behind TLS termination.

Use DevTools to find mixed content

  1. Open the affected HTTPS page in a private window.

  2. Open Developer Tools, then Console and Network.

  3. Reload with the Network log preserved.

  4. Filter for http://, blocked requests, redirects, and Mixed Content messages.

  5. Record the initiator: HTML, CSS, JavaScript, iframe, worker, API call, font, media, form, or injected extension.

  6. Repeat across representative templates, authenticated pages, and responsive variants.

Fix each resource at its owner

Before and after mixed-content cleanuphtml
<!-- Wrong: active content requested over HTTP -->
<script src="http://cdn.example.net/app.js"></script>
<form action="http://example.com/contact" method="post">
 
<!-- Better only when both destinations genuinely support HTTPS -->
<script src="https://cdn.example.net/app.js"></script>
<form action="https://example.com/contact" method="post">

Changing the scheme requires verification

  • Prefer same-origin relative URLs for resources owned by the application.

  • Confirm the third party supports HTTPS with a valid certificate before changing its scheme.

  • Self-host or replace a dependency that cannot provide trustworthy HTTPS.

  • Search database content, CSS url(), srcset, JavaScript configuration, API responses, templates, tag managers, and service-worker caches.

  • An HTTP form action can expose submitted data even when the page itself arrived over HTTPS.

Search a deployed page without sending it to a scanner

Maintenance workstationbash
curl -fsSL https://example.com/ -o page.html
rg -n "http://" page.html
42:<script src="http://cdn.example.net/app.js"></script>

Source scanning is useful but incomplete

  • curl -f fails on HTTP errors and -L follows redirects.

  • rg finds literal URLs in server HTML but not necessarily resources constructed at runtime.

  • Browser Network and Console evidence remains necessary for JavaScript, CSS imports, iframes, workers, and authenticated content.

  • Avoid uploading private staging URLs, cookies, or authenticated pages to public scanning services.

Check TLS termination and the full chain

  • Serve the leaf certificate plus required intermediate certificates; do not send only the leaf.

  • Keep the private key readable only by the terminating service and never paste it into diagnostics.

  • Ensure the CDN, load balancer, reverse proxy, and origin agree about who terminates TLS.

  • Reload the web server after renewal and confirm every node serves the new certificate.

  • Test IPv4 and IPv6 because stale AAAA routing can reach a different endpoint.

Add HSTS only after HTTPS works everywhere

HTTPS response headerhttp
Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS is a promise with a long memory

  • Browsers honor HSTS only when received over a valid HTTPS connection.

  • includeSubDomains is safe only when every current and future subdomain supports HTTPS.

  • Start with a short max-age, monitor, and increase deliberately.

  • Preload is a separate high-impact commitment with removal delays; do not add it as a cosmetic padlock fix.

  • HSTS does not repair mixed content or a broken certificate chain.

  • Mark session cookies Secure, choose an appropriate SameSite value, and normally use HttpOnly.

  • Regenerate sessions during authentication and ensure logout invalidates them.

  • Update OAuth callbacks, webhook URLs, CORS allowlists, payment callbacks, and absolute email links.

  • Review CSP in report-only mode before enforcing; upgrade-insecure-requests can assist migration but should not hide unsupported dependencies.

  • Do not use deprecated block-all-mixed-content as the central fix.

Why the warning can remain after a fix

  • A service worker or browser cache still serves old HTML or assets.

  • A CDN edge has not purged the previous response.

  • Only one page template or language variant was corrected.

  • A browser extension injects an insecure resource; reproduce in a clean profile.

  • DNS directs some clients to an old server, especially over IPv6.

  • The system clock is wrong, making an otherwise valid certificate appear expired or not yet valid.

Final verification checklist

  • No TLS interstitial on any public hostname.

  • Certificate SAN, validity, chain, and SNI are correct.

  • HTTP consistently redirects to the canonical HTTPS origin.

  • Console and Network show no mixed-content warnings or blocked HTTP requests.

  • Forms and downloads use HTTPS.

  • Cookies and application callbacks reflect the HTTPS deployment.

  • Automated renewal is tested and monitored before expiration.

Authoritative references