SSL certificate errors can make a healthy website appear unsafe, block visitors, or interrupt deployments. This guide explains the most common HTTPS warnings, maps each error to likely causes, and provides a reusable troubleshooting and renewal checklist for domains, cloud hosting, and web servers.
Overview
An SSL certificate enables encrypted HTTPS connections between a visitor’s browser and your website. Although people still commonly say “SSL,” modern connections generally use TLS. The certificate helps the browser verify that the server is presenting a certificate for the requested hostname and that the certificate was issued by a trusted certificate authority.
When one of those checks fails, the browser may display messages such as “Your connection is not private,” “NET::ERR_CERT_DATE_INVALID,” “certificate name mismatch,” or “Not secure.” The exact wording depends on the browser and device, but the underlying problem usually fits one of a few categories:
- Validity problem: The certificate is expired, not yet valid, or the server clock is incorrect.
- Hostname problem: The certificate does not cover the domain or subdomain the visitor requested.
- Trust or chain problem: The server is not sending the intermediate certificates required by some clients.
- Configuration problem: HTTPS is enabled, but redirects, virtual hosts, or proxy settings are incorrect.
- Mixed-content problem: An HTTPS page still loads images, scripts, stylesheets, fonts, or other resources over HTTP.
Before changing records or reinstalling a certificate, record the exact hostname, browser message, affected URL, and time of the failure. This prevents a DNS or hosting change from being mistaken for a certificate issue. If the site recently moved, compare the DNS destination with the server where the certificate was installed. The DNS records and nameservers guide can help separate DNS routing problems from HTTPS problems.
Checklist by scenario
| Browser or deployment symptom | Likely cause | Checks and fixes |
|---|---|---|
| Expired certificate or date warning | The certificate validity period has ended, or the server/device clock is wrong. | Check the certificate’s start and expiry dates, confirm the server time, renew or reissue the certificate, then verify that the web server is using the new file. |
| Certificate hostname mismatch | The certificate does not include the requested domain, such as a www, apex, staging, or API subdomain. | Compare the requested hostname with the certificate’s subject alternative names. Request coverage for every required hostname and install the certificate on the correct virtual host. |
| Untrusted issuer or incomplete chain | The client cannot build a trusted path to the certificate authority, often because an intermediate certificate is missing. | Install the server certificate together with the required intermediate chain in the hosting panel or web-server configuration. Test from more than one client rather than relying only on the server itself. |
| HTTPS works on one hostname but not another | Only one virtual host, load balancer, CDN, or subdomain has been configured. | Test the apex domain, www version, and important subdomains separately. Confirm DNS, certificate coverage, listener configuration, and redirects for each hostname. |
| “Not secure” or blocked resources after HTTPS setup | The page contains mixed content: HTTP resources embedded in an HTTPS document. | Inspect browser developer tools, update absolute HTTP URLs to HTTPS or relative URLs where appropriate, and confirm that third-party resources support HTTPS. |
| Certificate appears renewed, but visitors still see the old error | A proxy, CDN, cache, secondary server, or load-balanced node is still serving the previous certificate. | Check every TLS termination point, reload services where required, clear relevant caches, and test the public hostname from different networks. |
Step-by-step HTTPS troubleshooting workflow
- Reproduce the warning. Test the exact URL and hostname that fails. A certificate for
example.comdoes not automatically prove thatwww.example.comorapi.example.comis covered. - Inspect the presented certificate. Review its validity dates, issuer, hostname coverage, and chain. Use the browser’s certificate viewer or a trusted TLS inspection tool approved by your organization.
- Verify DNS. Confirm that the hostname resolves to the intended hosting environment. After a nameserver or record change, results can differ temporarily while caches update. Use a DNS propagation checker and compare authoritative results with public resolvers.
- Check the hosting configuration. In a hosting panel, confirm that the certificate is assigned to the correct domain and that HTTPS is enabled. On a VPS, check the active virtual host, reverse proxy, load balancer, and service reload status.
- Test redirects and application URLs. Redirect HTTP to HTTPS only after HTTPS works correctly. Review CMS settings, canonical URLs, asset URLs, API endpoints, and webhook addresses.
- Retest from multiple clients. Check a current desktop browser, mobile browser, and at least one external network. This can reveal a stale cache, an alternate server, or a device-specific trust issue.
What to double-check
Certificate renewal checklist
- List every production hostname, including www, subdomains, customer portals, APIs, and administrative endpoints that are intended to be public.
- Identify where TLS terminates: the origin server, hosting panel, reverse proxy, CDN, load balancer, or more than one of these.
- Confirm who receives renewal notifications and where certificate expiry is monitored.
- Check that automated renewal has permission to complete its validation method and that DNS or web-server rules do not block it.
- After renewal, verify the public certificate rather than only the certificate file stored on the server.
- Confirm that the full certificate chain is installed and that the private key matches the renewed certificate.
- Record the renewal date, installation location, rollback procedure, and responsible owner.
Certificate authority requirements, browser behavior, and hosting-panel labels can change. Treat the exact menu names in any provider’s documentation as implementation details, not universal instructions. The durable checks are hostname coverage, validity, chain delivery, DNS routing, and successful renewal verification.
HTTPS is only one part of website trust. Review domain account protections in the registrar account security checklist, and use the website launch infrastructure checklist when introducing a new domain or hosting environment.
Common mistakes
- Renewing the certificate without installing it. A successful renewal process does not always mean the active web server is presenting the new certificate.
- Checking only the root domain. Visitors may use www, a regional hostname, a storefront, or an API subdomain with separate TLS configuration.
- Changing DNS before identifying the failure. This can add propagation delays and make troubleshooting harder. Capture the current state first.
- Assuming a valid certificate fixes mixed content. A valid certificate secures the connection to the page; it does not automatically rewrite insecure resource URLs inside the application.
- Testing only from the server. Local tests can miss an incorrect public DNS record, CDN certificate, proxy setting, or alternate load-balanced node.
- Ignoring non-browser clients. Mobile applications, command-line tools, integrations, and older operating environments may validate chains or hostnames differently. Test the clients that matter to your service.
- Leaving renewal ownership unclear. A certificate can fail because an account, DNS zone, validation token, or deployment job is no longer maintained.
When to revisit
Use this checklist before a planned certificate renewal, domain transfer, hosting migration, nameserver change, CDN or reverse-proxy rollout, major CMS update, or infrastructure redesign. Revisit it after adding a subdomain, changing the public IP address, consolidating servers, or modifying HTTP-to-HTTPS redirects.
Schedule a recurring review before your organization’s busiest seasonal planning cycle. Confirm certificate expiry monitoring, renewal ownership, DNS access, backup contacts, and a tested rollback path. Also review the process whenever your browser, certificate authority, hosting panel, cloud load balancer, or deployment workflow changes.
For the next incident, save a short record containing the failing hostname, certificate details, DNS result, hosting endpoint, error message, and final fix. That record turns future TLS troubleshooting into a repeatable operational task rather than an emergency investigation. If the problem began during a domain or hosting move, consult the guides on domain transfers without downtime and DNS propagation troubleshooting alongside this SSL checklist.
