SSL Certificate Troubleshooting Guide

Diagnose SSL errors with a practical checklist for expired certificates, DNS validation, hostname mismatches, mixed content, redirects, and renewal.

When a browser says a website is not secure, the cause may be an expired certificate, incorrect DNS validation, a hostname mismatch, mixed content, a redirect loop, or a missing certificate-chain file. This SSL certificate troubleshooting guide gives you a reusable diagnostic checklist for finding the cause, applying the right fix, and confirming that HTTPS works across the versions of your domain that visitors actually use.

Overview

An SSL certificate enables encrypted HTTPS connections between a visitor’s browser and a website. In current technical usage, SSL is commonly used as shorthand for TLS, the protocol used by modern secure connections. A certificate also helps a browser verify that the server is presenting credentials for the requested hostname.

When HTTPS is not working, start by identifying the exact failure rather than replacing files at random. Test the full URL, note the browser or command-line error, and check whether the problem affects every hostname or only one. For example, example.com, www.example.com, a staging subdomain, and an alternate domain can each have different DNS, hosting, and certificate configuration.

A useful investigation order is:

Confirm the requested hostname and URL.
Check the certificate’s validity dates and names.
Verify that DNS points to the intended hosting destination.
Confirm that the certificate is installed on the server handling HTTPS traffic.
Check the certificate chain, redirects, and page resources.
Retest in a private browser window and with a second tool or network.

DNS changes can take time to appear consistently because resolvers may cache previous answers. That means a correct configuration can still produce different results temporarily, especially after a website migration, domain transfer, nameserver change, or hosting move. For background on the records involved, see DNS Records Explained: How to Configure A, CNAME, MX, TXT, and AAAA Records.

Checklist by scenario

The certificate is expired or not yet valid

Open the certificate details in the browser and check the start and expiration dates. An expired certificate requires renewal and installation of the replacement certificate. A certificate that is not yet valid can indicate an incorrect server clock, an incomplete deployment, or a certificate that was issued for a later start time.

Confirm the server’s date and time are reasonable.
Check whether automatic renewal is enabled and whether its last attempt succeeded.
Verify that the renewed certificate was installed on the active HTTPS endpoint.
Check every hostname that should be covered, including the www version and relevant subdomains.
Remove or replace an older certificate if the server is presenting the wrong one.

Do not assume that renewing a certificate automatically deploys it. Some hosting panels handle issuance and installation together; others require a separate installation or reload step. Follow the current instructions for your certificate authority and hosting environment.

Certificate renewal fails during domain validation

Certificate authorities commonly validate control of a domain through a DNS record, an HTTP file, or another approved method. If DNS validation fails, inspect the exact record requested by the certificate authority. A TXT record can be placed at the wrong name, copied with an extra character, or published in a DNS zone that is not authoritative for the domain.

Confirm which nameservers are authoritative for the domain.
Publish the validation record in the active DNS management system.
Check the record name, value, and record type character by character.
Remove conflicting or stale validation records only when you know they are no longer needed.
Allow for DNS caching before requesting validation again.

HTTP validation can fail when port 80 is blocked, the validation path is redirected incorrectly, or a proxy or application rewrites the requested file. Check that the validation URL is publicly reachable and is not protected by authentication, an application firewall rule, or a maintenance page.

The browser reports a hostname mismatch

A hostname mismatch means the requested domain is not covered by the certificate being presented. Compare the address in the browser with the names listed in the certificate. A certificate for www.example.com does not necessarily cover example.com, and a certificate for a parent domain does not automatically cover every subdomain.

Correct the issue by requesting a certificate that includes all required names, or by configuring each hostname to use the endpoint where its matching certificate is installed. Also check whether DNS sends one hostname to a different server, load balancer, CDN, or hosting account than the others.

HTTPS works, but the page shows a mixed content error

Mixed content occurs when an HTTPS page loads a resource over plain HTTP. Images, stylesheets, scripts, fonts, embedded media, and API calls can all cause the warning. The certificate may be valid even though the page is not fully secure.

Inspect the browser’s developer tools for the exact HTTP resource.
Change hard-coded resource URLs from http:// to https:// where the resource supports HTTPS.
Update content management system settings, theme files, plugins, templates, and database-stored URLs.
Check third-party scripts and embedded services that may not support secure loading.
Clear application, plugin, CDN, and browser caches after making the change.

For a WordPress site, review the site URL, home URL, active theme, plugins, and any cached page output. The WordPress Website Launch Checklist provides a broader review of hosting, SSL, DNS, backups, and performance.

HTTPS creates a redirect loop

A redirect loop often appears when multiple layers try to enforce HTTPS or when a reverse proxy terminates HTTPS before forwarding a request to an application over HTTP. Check redirects at the hosting server, application, CDN, control panel, and web framework. Keep one clear enforcement path where possible.

Test both the HTTP and HTTPS versions of the root domain and the www version. Record each response status and destination. Also confirm that the application correctly recognizes the original secure connection when a proxy is involved; otherwise, it may redirect an already secure request back to HTTP or repeatedly redirect to HTTPS.

The error mentions an incomplete certificate chain

Some clients may reject a server that sends only the site certificate without the intermediate certificates needed to connect it to a trusted root. Install the certificate bundle or intermediate chain supplied for your certificate, using the format required by the server or hosting panel. Then reload the service and test again.

Do not manually add random root certificates to the server. Use the chain instructions provided with the issued certificate, and verify that the server sends the intended chain in the correct order.

What to double-check

Before declaring the SSL certificate problem fixed, review the configuration as a complete system:

Every required hostname: Test the root domain, www hostname, subdomains, and any alternate domain that redirects to the main site.
DNS destination: Compare A, AAAA, and CNAME records with the hosting endpoint. An unexpected AAAA record can send some visitors to a different server than IPv4 visitors.
Nameservers: Make sure you edited the authoritative DNS zone, not an inactive zone at a registrar or former provider.
Certificate coverage: Confirm the certificate includes the exact hostnames visitors request.
Server selection: On shared hosting or a multi-site server, verify that the correct certificate is associated with the correct virtual host.
Redirect behavior: Check HTTP, HTTPS, www, and non-www paths for unexpected chains or loops. See How to Set Up Redirects for www, non-www, HTTP, and HTTPS Correctly.
Application resources: Search generated HTML, stylesheets, scripts, and API configuration for HTTP URLs.
Renewal notifications: Confirm that the responsible administrator can receive renewal and validation messages.

Keep a short record of the working state: certificate provider, covered names, renewal method, DNS validation record location, hosting endpoint, and redirect rules. This makes the next renewal or migration easier to diagnose.

Common mistakes

Checking only the homepage: A certificate can work on one hostname while failing on a subdomain, admin area, image host, or API endpoint.
Editing the wrong DNS zone: The registrar, hosting account, and managed DNS provider may all show DNS controls, but only the authoritative nameservers publish the active zone.
Assuming propagation is the only problem: Waiting will not fix a misspelled TXT record, an incorrect certificate name, or a server that presents an old certificate.
Installing a certificate without its chain: The site may appear to work in one browser while other clients report trust errors.
Forcing HTTPS in several places: Duplicate redirect rules can create loops and make future troubleshooting harder.
Ignoring IPv6: An AAAA record can direct users to a server whose HTTPS configuration was not updated during migration.
Fixing mixed content with a blind search-and-replace: Some external resources do not support HTTPS, and changing URLs without testing can break page functionality.
Replacing certificates before collecting evidence: Save the exact error, hostname, certificate details, and DNS response first. That information often identifies the failing layer.

When to revisit

Revisit this checklist before a certificate’s renewal window, after changing DNS or nameservers, and whenever a website moves between hosting providers, cloud platforms, CDNs, or load balancers. It is also useful after a domain transfer, redesign, WordPress migration, subdomain launch, or change to automated deployment.

Schedule a basic HTTPS review as part of regular site maintenance. Confirm that renewal automation still has access to the DNS or web validation method, that contact details are current, and that alerts reach someone responsible for the site. For related email and DNS changes, review the guide to setting up a custom email domain with MX, SPF, DKIM, and DMARC; email records and website certificate records serve different purposes and should not be substituted for one another.

When troubleshooting, change one layer at a time: DNS, certificate issuance, server installation, redirects, or page resources. Retest after each change, document the result, and remove temporary records or rules when they are no longer required. This method turns “why is my website SSL certificate not working?” into a bounded investigation rather than a trial-and-error exercise.