SSL Certificate Errors: HTTPS Troubleshooting Guide

Diagnose SSL and HTTPS warnings with a practical checklist for expiration, hostname mismatches, certificate chains, mixed content, and renewal failures.

An SSL certificate error means the browser cannot fully verify the connection between your website and its visitors. This troubleshooting guide helps you identify the cause, choose the right fix, and confirm that HTTPS works consistently after domain changes, hosting migrations, certificate renewals, or configuration updates.

Overview

HTTPS protects data in transit and gives browsers a way to verify that a website is presenting a certificate for the requested domain. Although people often say “SSL certificate,” modern websites generally use certificates with TLS connections. The practical troubleshooting steps are similar: inspect the certificate, verify the domain names and dates, check the certificate chain, and confirm that the server is configured consistently.

An HTTPS warning does not always mean the certificate itself is defective. The problem may be in DNS management, a reverse proxy, a load balancer, a hosting panel, an application setting, or a browser cache. Start by identifying whether the warning affects every visitor or only one device, one URL, or one type of request.

Before changing settings, record the affected URL, the exact browser message, when the problem began, and any recent changes. Domain transfers, hosting migrations, DNS edits, server replacements, and expired payment or renewal settings are useful clues. For background on the records that direct a domain to a server, see this guide to DNS records.

Checklist by scenario

1. The certificate is expired or not yet valid

Browsers check the certificate’s validity dates against the visitor’s current date and time. Open the certificate details in the browser or use the certificate view in your hosting control panel. Confirm the start and expiration dates, then check the server clock if the certificate appears valid but the browser reports a date problem.

Check whether the certificate is expired.
Confirm that the server and local device have the correct date and time.
Review the hosting panel or certificate manager for renewal status.
After renewal, verify that the web server is serving the newly issued certificate rather than an older copy.

If automatic SSL renewal failed, inspect the renewal log for the validation error. Common areas to review include DNS records, HTTP redirects, firewall rules, and whether the validation hostname reaches the expected server. Do not assume that reissuing a certificate will solve a validation problem if the underlying routing has not changed.

2. The hostname does not match

A hostname mismatch occurs when the certificate does not include the domain visitors requested. For example, a certificate issued only for example.com may not cover www.example.com, and a certificate for one subdomain does not automatically cover every other subdomain.

Test the exact address that produces the warning, including the www prefix.
Check the certificate’s listed names, often called the Subject Alternative Names.
Confirm that both the apex domain and required subdomains are included.
Check whether DNS points each hostname to the intended HTTPS service.

Choose one canonical address for the site and redirect other versions to it only after each version can complete a valid HTTPS connection. A redirect cannot repair a certificate mismatch on the initial connection.

3. The certificate chain is incomplete or untrusted

Browsers use the certificate chain to connect the website certificate to a trusted certificate authority. If the server sends only the site certificate and omits an intermediate certificate required by the client, some browsers or devices may show a trust error even though the certificate appears valid in another environment.

Check the certificate chain using the hosting provider’s diagnostic tools or a trusted TLS inspection tool.
Install the certificate bundle or intermediate certificates supplied with the issuance.
Confirm that the web server, proxy, and load balancer use the same certificate configuration.
Retest from more than one browser or network after saving the configuration.

Follow the installation instructions for the specific server or hosting platform. A certificate file and a private key serve different purposes; protect the private key and do not paste it into public troubleshooting tools.

4. The page loads, but shows mixed content

Mixed content appears when an HTTPS page requests some resources over unencrypted HTTP. The browser may block scripts, frames, fonts, images, or other resources, or display a weaker security indicator. This is different from an invalid certificate: the main connection may be valid while individual page resources use the wrong protocol.

Open the browser’s developer tools and inspect the Console and Network panels.
Search the page source, theme, templates, and content for hard-coded http:// URLs.
Update asset URLs, canonical settings, API endpoints, and third-party integrations to HTTPS where supported.
Check redirects and cached versions after making the change.

For a content management system, review the site URL settings and any plugins or extensions that generate absolute URLs. If the issue began after moving hosts, compare the application configuration with the new server and proxy settings. A broader performance review can also help identify requests that still bypass the intended secure path; see the WordPress hosting performance checklist for related checks.

5. HTTPS broke after a DNS or hosting change

When a domain points to a new server, the new destination must have its own correct certificate and HTTPS configuration. A certificate installed on the old host does not automatically follow the domain. Review the A, AAAA, CNAME, and any proxy-related records, then confirm which service is answering each hostname.

Compare DNS resolution with the intended hosting destination.
Check both IPv4 and IPv6 records if the domain publishes both.
Install or issue the certificate on the active server, not only the previous host.
Verify the web server’s virtual host or site binding for every required hostname.

During a migration, test the new environment before changing all traffic. The website hosting migration checklist provides a useful companion process for reducing configuration surprises.

What to double-check

Use this short diagnostic sequence before making repeated certificate changes:

Capture the exact warning. Record the browser, URL, device, and error wording.
Inspect the certificate. Check its dates, listed hostnames, issuer, and chain.
Confirm DNS. Make sure the affected hostname reaches the intended server, proxy, or CDN.
Check the active endpoint. Multiple servers may exist behind DNS, a load balancer, or a content delivery service.
Review renewal validation. Confirm that HTTP or DNS validation can complete and that required records or paths are available.
Test the complete page. Look for mixed content, failed redirects, blocked resources, and application-generated HTTP links.
Retest after caches clear. Compare a private browser window with a normal session, while remembering that external DNS and proxy caches may take time to reflect changes.

Keep a simple inventory of domains, subdomains, certificate providers, renewal methods, DNS owners, and hosting endpoints. This turns SSL renewal from an emergency task into a repeatable operations check. Access to the domain registrar alone may not be enough: DNS management and hosting access can be controlled in separate accounts.

Common mistakes

Checking only the homepage: A certificate may work on the root domain while failing on an application subdomain, checkout page, API endpoint, or mail-related web service.
Renewing without fixing validation: Repeated renewal attempts will not help if DNS, redirects, firewall rules, or port access prevent domain validation.
Installing the wrong certificate: A certificate can be valid but intended for a different hostname or server.
Forgetting IPv6: An AAAA record can send some visitors to a server with different HTTPS settings than the IPv4 destination.
Ignoring proxies: A CDN or reverse proxy may terminate HTTPS before the request reaches the origin. Both sides may need appropriate configuration.
Sharing private keys: Certificate troubleshooting should expose certificate details, not private keys or unrelated account credentials.
Assuming every warning is an SSL issue: Mixed content, redirect loops, DNS failures, and application errors require different fixes.

When to revisit

Revisit this checklist before a planned certificate renewal, domain transfer, hosting migration, DNS change, major application deployment, or seasonal traffic period. Also review it whenever a new subdomain is launched or a proxy, load balancer, CDN, or hosting control panel is introduced.

After fixing an SSL certificate error, schedule a follow-up check rather than treating the first successful page load as the end of the work. Test the apex domain, preferred www version, important subdomains, login and checkout paths, API endpoints, and representative pages. Confirm that redirects lead to the chosen canonical HTTPS URL and that no mixed-content requests remain.

Finally, document what changed, which account controls renewal, and how to verify the next renewal. If the warning returns, begin with the exact error and the active DNS destination instead of replacing certificates blindly. That approach is faster, safer, and more reliable across hosting providers and website platforms.