SSL certificate errors can make a working website appear unsafe, unavailable, or broken. This guide explains the most common HTTPS warnings, shows how to match each warning to the right fix, and provides a repeatable checklist for checking certificates after renewals, DNS changes, migrations, and hosting updates.
Overview
HTTPS protects the connection between a visitor’s browser and your website. An SSL certificate, more accurately part of a modern TLS setup, helps the browser confirm that it is connecting to the intended domain and that the connection can be encrypted.
When that certificate cannot be trusted or does not match the way a site is being accessed, the browser may display a warning such as “Your connection is not private,” “Certificate expired,” or “This site is not secure.” The exact wording varies by browser and device, but the underlying causes are usually familiar.
SSL certificate troubleshooting is safer when you identify the failure before changing settings. First determine whether the problem affects every visitor or only one device. Then check the certificate presented for the exact hostname, the certificate’s validity dates, the certificate chain, DNS routing, and the page’s internal resources.
A certificate warning is not the same as a general website outage. A site may load over HTTP while HTTPS fails, or the homepage may work while a subdomain, checkout page, image, or API endpoint produces an error. Test each important hostname separately, including the version with www and the version without it.
Checklist by scenario
Use the reference below to narrow the problem before contacting your hosting provider, certificate issuer, or development team.
| What you see | Likely cause | What to check or fix |
|---|---|---|
| Certificate expired | The certificate’s end date has passed. | Renew or replace the certificate, then confirm that the web server is using the newly issued certificate. Check that automatic renewal is enabled if your setup supports it. |
| Hostname mismatch | The certificate does not cover the hostname being visited. | Check whether the certificate includes the exact domain, subdomain, or appropriate wildcard. Confirm that DNS sends each hostname to the intended server. |
| Untrusted issuer or certificate | The browser cannot establish trust in the certificate or its issuer. | Verify that the certificate was issued by a recognized provider and that the server is presenting the required intermediate certificates. Avoid asking visitors to bypass the warning. |
| Incomplete certificate chain | The server sends the site certificate but omits one or more intermediate certificates. | Install the provider’s full chain or bundle, not just the site certificate. Follow the format required by your hosting control panel or web server. |
| Mixed content warning | An HTTPS page requests images, scripts, stylesheets, fonts, or other resources over HTTP. | Update resource URLs to HTTPS, use relative or secure canonical URLs where appropriate, and check plugins, themes, embedded media, and hard-coded database links. |
| Certificate appears not yet valid | The certificate start date is in the future, or the visitor’s device has an incorrect clock. | Check the server and device date, time, and time zone. If the clock is correct, review the certificate’s validity dates and issuance details. |
| HTTPS works on one hostname but not another | Different DNS records, servers, virtual hosts, or certificate configurations are involved. | Test each hostname independently. Confirm its DNS record, hosting configuration, redirect rule, and certificate coverage. |
If the issue began after a domain transfer or website migration, review both DNS and server configuration. The domain may now point to a new host while the certificate remains installed only on the old server. The guide How to Connect a Domain to Web Hosting covers the relationship between nameservers, DNS records, and hosting destinations.
What to double-check
- Test the exact URL. Check the main domain,
wwwhostname, important subdomains, and any separate customer or application areas. A certificate valid for one hostname may not cover another. - Inspect the certificate details. Confirm the subject or covered names, issuer, validity period, and chain. Browser certificate viewers and your hosting panel can reveal which certificate the server is presenting.
- Check DNS before reinstalling anything. An
A,AAAA, or CNAME record can route visitors to a different server from the one you are editing. Pay particular attention to stale records after a migration. - Confirm the server binding. On many hosting setups, a certificate must be assigned to a particular domain or virtual host. Installing a certificate without assigning it to the correct site may not change what visitors receive.
- Review redirects. A redirect from HTTP to HTTPS should lead to the intended hostname and should not create a loop. Check both the destination and any rules added by a content management system, plugin, reverse proxy, or CDN.
- Find mixed content at the source. Inspect page source, browser developer tools, theme settings, plugins, scripts, and stored content. A single HTTP resource may trigger warnings or prevent a security-sensitive feature from working correctly.
- Test from more than one network. Clear local caches and try another browser or connection. This helps separate a server-side problem from a stale local DNS or browser state.
After making a change, retest in a private browser window and use a certificate inspection tool that reports the complete chain and covered hostnames. If you use WordPress, include SSL checks in the broader maintenance routine described in the WordPress Website Maintenance Checklist.
Common mistakes
- Renewing the wrong certificate. Several domains or environments may exist in one hosting account. Match the certificate to the affected hostname before renewing or replacing it.
- Installing only the leaf certificate. The site certificate alone may not give browsers enough information to build a trusted chain. Use the complete certificate bundle when the provider supplies one.
- Assuming DNS changes are immediate everywhere. Different resolvers can retain DNS data for different periods. Check the intended destination and allow for normal propagation before repeatedly changing records.
- Fixing the homepage but not subdomains. Mail, staging, downloads, APIs, and account areas may have separate DNS and certificate settings. List every public hostname that matters to visitors.
- Using a blanket redirect without checking resources. Redirecting the page to HTTPS does not automatically rewrite HTTP links embedded in content, scripts, stylesheets, or third-party integrations.
- Ignoring the server clock. An incorrect date can make a valid certificate appear expired or not yet active, especially on a newly configured server or device.
- Bypassing the warning. Proceeding through a certificate warning may expose visitors to an untrusted connection and can hide the real configuration problem. Treat the warning as a signal to investigate.
Keep a short record of the certificate provider, covered hostnames, renewal method, DNS destination, and hosting location. This makes future troubleshooting faster and reduces the risk of changing a working part of the setup.
When to revisit
HTTPS checks should be part of routine website reliability work, not only an emergency response. Revisit this checklist:
- Before and after a certificate renewal or change in renewal method.
- After a domain transfer, nameserver update, DNS edit, or website migration.
- When moving between hosting plans, servers, control panels, reverse proxies, or content delivery services.
- After adding a subdomain, staging environment, API, checkout area, or third-party integration.
- Before a seasonal campaign or other period when an HTTPS failure would disrupt important traffic.
- Whenever visitors report a security warning, redirect loop, broken images, blocked scripts, or an unavailable page.
For a practical final check, open every important HTTPS URL, inspect the certificate dates and hostnames, confirm the chain is complete, test redirects, look for mixed content, and verify that DNS still points to the intended server. Record the results and the next renewal or review date. If the warning remains after these checks, give your hosting provider the exact hostname, error message, time observed, recent DNS or migration changes, and any certificate details you found. That information helps isolate the issue without replacing settings at random.
