HTTPS Errors Explained: A Practical Troubleshooting Guide for SSL and Mixed Content Problems

Overview

HTTPS protects the connection between a visitor’s browser and your website. It relies on TLS, the security protocol that uses an SSL certificate to prove that a domain is connected to the expected server and to encrypt traffic in transit. When that process fails, a browser may display a “not secure” warning, refuse to load the page, or show a more specific certificate error.

HTTPS troubleshooting is easier when you separate the problem into four layers:

• Certificate: Is it valid, unexpired, issued for the correct hostname, and trusted by browsers?
• DNS and hosting: Does the domain resolve to the server that has the certificate and website configuration?
• Redirects and proxy services: Are HTTP, HTTPS, a CDN, or a reverse proxy forwarding requests consistently?
• Page content: Does the HTTPS page still request images, scripts, stylesheets, fonts, or forms over HTTP?

Check one layer at a time. Changing DNS, redirect rules, and certificate settings simultaneously can make the cause harder to identify. Before editing configuration, record the affected hostname, the exact browser message, when the issue began, and any recent changes to domain registration, DNS management, hosting, a CDN, or a website migration.

Common HTTPS messages and likely causes

Checklist by scenario

1. The certificate is expired

1. Confirm the exact hostname that produces the warning. A certificate for example.com may not cover every subdomain.
2. Check the certificate’s start and expiry dates in the browser certificate viewer or hosting control panel.
3. Check whether automatic renewal is enabled and whether the renewal validation method still works.
4. Verify that DNS records or nameservers still point to the service responsible for renewal. A recent DNS change can prevent domain validation.
5. Install or activate the renewed certificate, then test in a private browser window and on a second network.

Do not assume that renewing a certificate automatically installs it on every server, CDN, load balancer, or staging environment. If traffic passes through more than one TLS endpoint, each endpoint may need its own configuration.

2. The certificate does not match the domain

A name mismatch commonly occurs after a site launch, domain transfer, or change between www and non-www addresses. Visit the exact address shown in the browser and inspect the certificate names. Confirm that it covers the required hostname, then check which server answers for that hostname through DNS.

Also review subdomains. A certificate for the main domain is not automatically proof that shop.example.com, www.example.com, or another subdomain is covered. Correct the certificate, the DNS target, or the redirect destination—whichever does not match the intended setup.

3. The certificate chain is incomplete

Browsers need more than the site certificate in some server configurations. They may also need the intermediate certificates that connect it to a trusted root. If the server sends an incomplete chain, some browsers or operating systems may report an issuer or trust error while others appear to work.

Review the certificate provider’s installation instructions for your web server or hosting control panel. Install the full chain supplied for that certificate, rather than combining files from unrelated certificates. Afterward, test from more than one browser or environment, especially if the error affects particular devices.

4. HTTP redirects to HTTPS incorrectly

A standard setup usually redirects visitors from http:// to https:// and serves the final page over HTTPS. Problems occur when two systems enforce different rules—for example, a web server redirects to HTTPS while a proxy believes the original request is already secure, or a content management system is configured with the wrong site URL.

1. Check the full redirect chain for both www and non-www versions.
2. Identify whether redirects are controlled by the web server, hosting panel, application, CDN, or proxy.
3. Keep one clear canonical destination and remove competing redirect rules.
4. Confirm that the application recognizes the original HTTPS connection when a proxy is in front of it.

Clear only the relevant cache after changing redirect settings. A cached redirect can make a fixed configuration appear broken, while an aggressive cache purge can create unnecessary disruption.

5. The page has a mixed content error

Mixed content occurs when an HTTPS page loads a resource over HTTP. Typical examples include an image, JavaScript file, stylesheet, web font, embedded frame, API request, or form action. Browsers may block active content or show a warning for resources that are less sensitive but still insecure.

1. Load the HTTPS page and open the browser developer tools.
2. Review the Console and Network panels for HTTP URLs.
3. Update hard-coded links, theme settings, plugins, templates, database values, or environment variables to use HTTPS.
4. Check third-party resources and embedded services; confirm they support HTTPS before changing their URLs.
5. Clear application and CDN caches, then test the page again.

A redirect from an HTTP asset to HTTPS may not remove every warning and can add avoidable requests. Where possible, reference the secure URL directly.

6. The domain, hosting, or proxy recently changed

When a domain is connected to new web hosting, DNS records determine where requests go, while the certificate must be installed on the server that receives those requests. Verify the A, AAAA, and CNAME records relevant to the affected hostname, and confirm that old records are not sending some visitors to a previous server.

If a CDN or reverse proxy is involved, check both connections: visitor to proxy and proxy to origin server. The proxy may need a valid certificate for the public domain, while the origin may require a separate certificate or a compatible TLS mode. Follow the provider’s documented options rather than enabling settings at random.

7. The warning appears only in one browser or device

Test the URL in a private window, a second browser, and—where practical—a different network. Compare the certificate details and the exact error. If the issue disappears in a private window, inspect cached certificates, cached redirects, extensions, or local security software. If it appears only on an older device, the device may have outdated trust information or TLS support; confirm the server’s supported configuration before making compatibility changes.

What to double-check

• Every hostname: Test the preferred domain, www or non-www alternative, important subdomains, and any domains used for redirects.
• Certificate dates and names: Confirm validity dates and hostname coverage, not just the presence of a certificate.
• DNS ownership: Make sure the DNS provider, hosting account, and certificate renewal process still use the intended records.
• Full chain installation: Verify that intermediate certificates are installed where the server expects them.
• Application URLs: Check the site URL, asset URLs, canonical links, API endpoints, and form actions.
• Proxy awareness: Ensure the web server and application correctly recognize secure requests forwarded by a CDN or reverse proxy.
• Testing after changes: Use a clean session and inspect the final response, certificate, redirects, and page resources rather than relying on one browser reload.

Common mistakes

Renewing the wrong certificate: Several environments may exist, including production, staging, and a CDN. Identify which endpoint serves the public domain before installing a replacement.

Changing nameservers to solve a certificate problem: Nameserver changes affect all DNS records, including email. Use the smallest change that addresses the issue and check MX, TXT, and other required records before modifying DNS.

Fixing only the homepage: A certificate or mixed content problem may affect one subdomain, template, landing page, or asset path. Test representative pages and important user journeys.

Adding multiple redirect rules: Redirects in the server, application, CDN, and plugins can conflict. Document which layer owns the canonical redirect.

Disabling security checks: Bypassing a browser warning can hide a real configuration or interception problem. Use an exception only for controlled testing, not as a production fix.

Ignoring renewal ownership: Record who controls the certificate, DNS validation, hosting account, and renewal notifications. Review access before a team member leaves or a domain is transferred.

When to revisit

Use this checklist whenever a certificate renews, a domain or DNS provider changes, a site moves to new hosting, a CDN or proxy is introduced, a staging site goes live, or a browser reports a new HTTPS warning. It is also useful before a seasonal campaign or major website release, when a short outage or warning can affect visitors and transactions.

After every infrastructure change, schedule a small verification pass:

1. Test HTTP and HTTPS versions of the main domain.
2. Test www and non-www versions if both are publicly reachable.
3. Inspect certificate names, dates, issuer, and chain.
4. Review redirects and confirm one intended canonical URL.
5. Check browser console messages for mixed content.
6. Confirm forms, logins, APIs, images, scripts, and email-related DNS records still work.
7. Record the result, the certificate renewal date, and the owner responsible for the next review.

Keep this record with your website maintenance and backup documentation. HTTPS problems are usually easier to prevent than to diagnose during an outage, particularly when domain registration, DNS management, hosting, and certificate renewal are handled in different accounts.