An SSL warning can come from an expired certificate, the wrong hostname, an incomplete certificate chain, incorrect redirects, or unsecured page resources. This reusable SSL certificate troubleshooting checklist helps you identify the cause safely, verify the fix, and avoid repeat problems during renewals, domain changes, migrations, and redesigns.
Overview
SSL is commonly used to describe the certificates and encryption that protect HTTPS connections. Technically, modern websites use TLS, but hosting dashboards, browsers, and documentation may still use the term SSL. When a certificate is installed correctly, a browser can verify that the connection is encrypted and that the certificate applies to the domain being visited.
A security warning means that one part of this verification has failed or that the page is not consistently using HTTPS. Do not dismiss the warning before checking the cause. A visitor may be unable to establish a trusted connection, and an administrator who bypasses the warning can miss a configuration problem.
Begin by recording the exact message, the URL that produced it, and whether the problem affects every visitor or only one device or network. Test the main hostname and any important variants, such as example.com, www.example.com, and subdomains used for applications or administration. SSL troubleshooting is most reliable when each hostname is checked separately.
If you are still choosing a provider, confirm that your web hosting includes certificate installation, automated renewal where appropriate, DNS management access, backups, and a clear way to review certificate status. The hosting control panel is often the fastest place to identify an expired certificate or a failed renewal attempt.
Checklist by scenario
| Symptom | Likely cause | What to check |
|---|---|---|
| SSL certificate expired | The certificate validity period has ended, or renewal did not complete. | Review the certificate's expiration date, renewal status, domain validation method, and hosting-panel logs. Confirm that the renewed certificate is installed on the server handling HTTPS traffic. |
| Invalid certificate or hostname mismatch | The certificate does not cover the hostname visitors are using. | Compare the requested hostname with the certificate's covered names. Check whether the certificate includes both the root domain and the www hostname, plus any required subdomains. |
| Certificate not trusted or incomplete chain | The server is not sending the required intermediate certificates, or the certificate was installed incorrectly. | Review the server's certificate-chain configuration. Install the provider's recommended full chain rather than uploading only the site certificate. Test from more than one browser or diagnostic tool after restarting or reloading the relevant service. |
| HTTPS redirect loop | Multiple redirect rules, a proxy configuration, or an application setting disagrees about whether the connection is secure. | Inspect redirects from HTTP to HTTPS and between hostname variants. Check reverse-proxy or CDN settings, application URL settings, and forwarded-protocol headers. Keep one clear canonical destination. |
| Mixed content warning | An HTTPS page requests images, scripts, stylesheets, fonts, media, or other resources over HTTP. | Open the browser developer tools and identify every insecure request. Update hard-coded URLs, database content, theme or plugin settings, third-party embeds, and asset references to HTTPS where supported. |
| Certificate works on one hostname but not another | DNS records route the hostnames to different servers or only one server has the certificate. | Review DNS records, load balancer or CDN mappings, virtual-host configuration, and certificate coverage for each hostname. Allow for DNS changes to propagate before concluding that installation failed. |
Step-by-step verification
- Capture the exact error. Note the browser message, hostname, port, time, and whether the failure occurs on desktop, mobile, or a specific network.
- Check the certificate dates. Confirm that the certificate is currently valid and that the server clock is accurate. An incorrect system clock can make a valid certificate appear expired or not yet valid.
- Check hostname coverage. Make sure the certificate covers the precise name in the address bar. A certificate for the root domain does not automatically cover every subdomain.
- Inspect the chain. Use the hosting control panel or a reputable certificate diagnostic tool to confirm that the server presents the expected certificate and intermediate chain.
- Verify DNS and server routing. Confirm that the hostname resolves to the intended web server, proxy, or CDN and that every HTTPS endpoint has the appropriate certificate.
- Review redirects. Test HTTP, HTTPS, the root domain, and
wwwseparately. Look for loops, unexpected destinations, or inconsistent canonical-host rules. - Scan for mixed content. Fix insecure resource URLs, then clear relevant caches and retest the page, forms, checkout flows, and authenticated areas.
- Test after propagation and caching. Recheck from a private browser window and at least one separate network. CDN, browser, application, and DNS caches can preserve old behavior temporarily.
What to double-check
Certificate renewal is not complete merely because a new certificate has been issued. Confirm that the renewal account can still complete domain validation, that required DNS or HTTP validation records have not been removed, and that the certificate was deployed to every server handling traffic. If a site uses a load balancer, reverse proxy, or content delivery network, check the certificate at that layer as well as at the origin server.
Domain changes deserve special attention. Before changing DNS or transferring a domain, list every hostname that needs HTTPS, including mail-related web interfaces, APIs, staging systems, and customer portals. Do not assume that moving a domain registration transfers its certificates or web-server configuration. Keep a record of the certificate provider, renewal method, covered names, installation location, and responsible account.
For WordPress and other content-managed sites, search the database and configuration files for old HTTP URLs. Update site URL settings, theme assets, plugins, uploaded media, canonical links, XML sitemaps, and third-party integrations. Make changes in a staging environment where possible, then verify the production site after deployment. A staging and production workflow can reduce the risk of testing certificate or redirect changes directly on a live site.
Protect the recovery path. Take a current website and database backup before changing web-server rules, plugins, proxy settings, or DNS. Save a copy of the previous configuration and document how to restore it. Backups do not fix certificate errors by themselves, but they limit the impact of a failed redirect or migration.
Common mistakes
- Renewing without deploying. A certificate can be valid in an account dashboard while the live server continues to present the old or expired certificate.
- Installing only the leaf certificate. Some clients need the intermediate chain supplied by the certificate provider. Use the correct full-chain file or hosting-panel option.
- Checking only the homepage. Subdomains, APIs, checkout pages, login forms, and older landing pages may use different servers or contain mixed content.
- Adding more redirect rules. Layering application, server, proxy, and CDN rules can create loops. Map the intended request path first, then remove conflicting rules.
- Forcing HTTPS before validating the certificate. Redirecting all traffic to a broken HTTPS endpoint makes the problem harder to diagnose. Validate the certificate and origin first.
- Ignoring third-party resources. Fonts, analytics, video embeds, payment widgets, and externally hosted scripts can trigger mixed content or fail after a provider changes its URL.
- Assuming a browser cache is the whole problem. Clear local caches, but also investigate DNS, CDN, server, and application caches before declaring the issue resolved.
When to revisit
Use this checklist before each certificate renewal and after any event that changes hostname routing or web-server configuration. Revisit it when you register or transfer a domain, migrate hosting, add a subdomain, install a CDN, replace a reverse proxy, redesign a site, or change WordPress themes and plugins. It is also useful before seasonal planning cycles, when ownership or on-call responsibilities may change.
Set a recurring operational review rather than relying on a browser warning as your first alert. Record certificate expiration dates, renewal contacts, covered hostnames, DNS providers, and the location of backups. Where your hosting platform supports it, enable renewal notifications and confirm that notifications reach a monitored mailbox or ticketing system.
After every change, run a short post-deployment check: open the main HTTPS URLs, inspect the certificate dates and hostname, test redirects, submit a representative form, review developer-console errors, and confirm that monitoring sees the expected response. If an issue remains unclear, preserve the exact error and configuration details before contacting your hosting provider or certificate provider. For broader migration work, pair this process with the domain, DNS, hosting, SSL, and backup migration checklist.
