An SSL certificate error can come from the certificate itself, your DNS records, the web server, the browser, or the device viewing the site. This troubleshooting checklist helps you identify the symptom, test the likely cause, and restore HTTPS safely without making unrelated configuration changes.
Overview
HTTPS depends on several systems working together. A certificate must be valid for the hostname in the browser’s address bar, the server must deliver the correct certificate and its required chain, DNS must direct visitors to the intended server, and the visitor’s device must have an accurate clock. After those checks pass, the page itself can still contain insecure resources that trigger a mixed-content warning.
Start by recording the exact browser message and the complete URL that produces it. “Certificate expired,” “connection is not private,” “name mismatch,” and “not secure” can point to different causes. Test the root domain and the www version separately, and check both HTTP and HTTPS if redirects are involved. Avoid repeatedly renewing or reinstalling a certificate before confirming which hostname and server the request is reaching.
If you manage DNS separately from your hosting account, treat the two services as separate parts of the investigation. A valid certificate installed on one server will not help if the domain’s DNS sends visitors to another. For background on the records involved, see DNS Records Explained.
Checklist by scenario
Use the symptom-to-cause table as a starting point. The wording varies by browser and operating system, but the underlying checks are broadly similar.
| Observed symptom | Likely cause | What to check or fix |
|---|---|---|
| Certificate expired | The certificate’s validity period has ended, or an old certificate is still being served. | Confirm the certificate dates, renew it through the certificate or hosting provider, and verify that the renewed certificate is installed on every relevant HTTPS endpoint. |
| Certificate mismatch or hostname error | The certificate does not include the hostname being visited, such as www.example.com versus example.com. | Check the certificate’s names, DNS targets, redirects, and hosting configuration. Request or install a certificate covering each hostname the site uses. |
| Incomplete certificate chain | The server is not sending an intermediate certificate required for browsers to build a trusted chain. | Review the hosting panel’s certificate installation instructions and install the provider’s recommended full chain or bundle. Do not substitute files from an unrelated certificate. |
| The wrong certificate appears after a DNS or hosting change | DNS still points to the previous host, an old record remains, or different endpoints have inconsistent configurations. | Use a DNS propagation checker and compare the domain’s A, AAAA, and CNAME results with the intended host. Check each returned server for the certificate it presents. |
| “Not secure” appears on an otherwise working HTTPS page | The page includes mixed content, such as images, scripts, stylesheets, fonts, or frames loaded over HTTP. | Open the browser developer tools, identify insecure requests, and update application settings, templates, or asset URLs to use HTTPS. |
| Certificate appears invalid only on one device | The device clock is wrong, the browser is outdated, or local security software is intercepting HTTPS. | Correct the date, time, and time zone; test another browser or network; then review local proxy or inspection settings if appropriate. |
Step 1: Confirm the hostname and endpoint
Copy the hostname from the address bar, including whether it uses www or another subdomain. Then inspect the certificate presented for that exact hostname. If the certificate is correct for one version but not another, the problem is usually a missing certificate name, a separate virtual-host configuration, or an inconsistent redirect.
Step 2: Check certificate dates and names
Review the certificate’s start and expiry dates, the subject or subject alternative names, and the issuing chain shown by the browser. If renewal was recently completed, confirm that the server is serving the new certificate rather than a cached or previously installed one. Where a hosting panel manages SSL automatically, check its status messages and domain validation settings before changing files manually.
Step 3: Verify DNS before changing hosting settings
Compare the domain’s current A, AAAA, and CNAME records with the address supplied by the intended host. An unexpected AAAA record can direct some visitors to a different server even when the A record looks correct. Allow for DNS caching after a change, but do not assume propagation is the cause if authoritative DNS results already show an incorrect destination. The DNS propagation troubleshooting guide provides a broader workflow.
Step 4: Check the certificate chain
A server may have the leaf certificate installed but omit the intermediate certificates needed by clients. Use the certificate details in a browser or a trusted diagnostic tool to see whether the chain is complete. Follow the exact bundle format required by the hosting platform. If you are unsure, preserve a backup of the current configuration and ask the host for the correct certificate and chain files.
Step 5: Test the page for mixed content
Once the certificate warning is resolved, load the page and inspect the browser console for blocked or insecure requests. Search the site’s configuration and content for absolute http:// URLs. Update canonical settings, media URLs, theme or template files, scripts, APIs, and third-party integrations as needed. Do not simply force every URL to HTTPS without checking that the destination actually supports it.
What to double-check
- Every public hostname: Test the root domain,
www, subdomains, staging addresses, and any separate checkout or application host. - Redirect behavior: Confirm that HTTP redirects to the intended HTTPS hostname and do not create a loop between hosting, proxy, and application settings.
- IPv4 and IPv6: Compare A and AAAA records. Both paths should lead to servers configured for the same hostname and certificate.
- Renewal ownership: Identify whether the certificate is managed by the host, a DNS provider, a reverse proxy, or your deployment system. Two systems attempting to manage renewal can create confusing results.
- CAA records: If certificate issuance or renewal fails, review CAA records and confirm that they do not unintentionally restrict the certificate authority used by your workflow.
- Application URLs: Check the site URL, content management settings, API endpoints, webhooks, and embedded resources after moving from HTTP to HTTPS.
- Monitoring: Record the certificate expiry date, renewal owner, covered hostnames, and a contact or escalation path. A simple inventory reduces surprises during a domain change or migration.
When SSL errors appear during a move to new web hosting, keep the old service available until DNS, redirects, content, email dependencies, and HTTPS have been tested. The website hosting migration checklist covers these dependencies together.
Common mistakes
Renewing the wrong certificate. A renewal does not correct a hostname mismatch if the certificate does not include the hostname visitors use. Confirm names first.
Changing DNS and SSL at the same time without a record of the old setup. Make one controlled change at a time where possible, and save the previous DNS and hosting configuration so you can compare results.
Installing only the leaf certificate. Many server platforms require a full chain. Follow the platform’s documented certificate fields rather than guessing which files belong in each field.
Testing only from a familiar browser. A local cache, device clock, corporate proxy, or DNS resolver can hide the actual cause. Compare another network or device, while treating differences as evidence to investigate rather than proof that the site is fixed.
Ignoring non-browser clients. APIs, mobile applications, monitoring checks, email links, and deployment tools may use different hostnames or certificate validation behavior. Include them in testing when the site supports these integrations.
Disabling verification as a permanent fix. Bypassing certificate warnings or turning off validation may conceal the problem and weaken security. Use such controls only in a controlled test environment and remove them afterward.
When to revisit
Keep this checklist with your operational documentation and revisit it before certificate renewal windows, seasonal planning cycles, domain registration changes, hosting migrations, DNS provider changes, and major website releases. It is also useful after adding a subdomain, introducing a CDN or reverse proxy, changing IPv6 settings, or replacing a deployment pipeline.
After any change, run a short acceptance test:
- Load each public hostname over HTTPS.
- Confirm the certificate name, validity dates, and chain.
- Verify that DNS points to the intended endpoint on both IPv4 and IPv6 where applicable.
- Test HTTP-to-HTTPS redirects and key pages such as login, checkout, forms, and APIs.
- Check the browser console for mixed content or blocked requests.
- Confirm that monitoring and renewal ownership still match the documented process.
If the warning persists after these checks, capture the exact error, hostname, DNS results, certificate details, timestamp, and affected network. That evidence gives your hosting or DNS provider a useful starting point and helps prevent repeated trial-and-error changes.
