An SSL certificate error usually has a specific cause: an expired certificate, a hostname that is not covered, an incomplete certificate chain, incorrect DNS, or a mismatch between your hosting and CDN settings. This reusable checklist walks through a safe troubleshooting order, explains what to check during SSL certificate renewal, and shows how to verify HTTPS after a domain, hosting, or DNS change.
Overview
HTTPS depends on several systems working together. Your website must have a valid SSL certificate for the hostname visitors use, DNS must direct that hostname to the intended service, and the web server or CDN must present the correct certificate and certificate chain. After the browser establishes the encrypted connection, the website itself must also load scripts, images, stylesheets, and other resources over HTTPS.
That means an SSL certificate for a website can be valid while the site still shows an HTTPS error. For example, a certificate may cover www.example.com but not example.com, or DNS may still point one hostname to an old server. Use the checks below in order, beginning with the visitor-facing error and then moving toward DNS and hosting configuration.
If you are moving a site, the website migration checklist can help you coordinate DNS, email, hosting, and SSL changes. For a new deployment, see the guide to connecting a domain to cloud hosting.
Checklist by scenario
1. The certificate is expired or has not renewed
- Record the affected hostname and the exact browser error.
- Inspect the certificate’s validity dates. Check both the start date and expiration date.
- Confirm which system issued the certificate: your hosting control panel, a load balancer, a CDN, or another certificate manager.
- Check the renewal task or log in that system. A renewal may fail if the domain no longer points to the expected server or if HTTP validation cannot reach the required path.
- After renewal, reload the certificate on the service that terminates HTTPS. Renewing a certificate file alone may not update a web server, proxy, or CDN.
- Test both the root domain and the
wwwhostname if both are supported.
Do not assume automatic renewal is working because it worked previously. Domain changes, DNS edits, disabled validation paths, and expired authorization can interrupt the process. Keep a record of where the certificate is managed and how the renewal is verified.
2. The certificate does not cover the hostname
Errors such as “name mismatch” or “certificate is not valid for this site” usually indicate that the certificate’s names do not match the address in the browser. Check the certificate’s subject alternative names and compare them with every hostname you serve.
- Check the apex domain, such as
example.com. - Check the
wwwhostname if it is used. - Check important subdomains such as
app.example.com,shop.example.com, or an API hostname. - Check whether a wildcard certificate covers the required level of subdomain.
Issue or install a certificate that covers the actual public hostnames, then configure redirects only after each destination is valid over HTTPS.
3. DNS or hosting points to the wrong service
When a domain is transferred, a website is migrated, or a CDN is introduced, DNS can direct visitors to different infrastructure than expected. Review the relevant A, AAAA, CNAME, and any provider-specific validation records. Compare the result from more than one network or use a DNS propagation checker, while remembering that cached DNS responses can differ temporarily.
Then confirm that the destination service has the domain added to its configuration. A server may respond to an IP address but return the wrong certificate when the requested hostname has not been configured. Check the virtual host, site binding, load balancer listener, or CDN custom-domain setting.
4. The certificate chain is incomplete
If some browsers or devices report a trust error while others work, the server may be sending the leaf certificate without the required intermediate certificates. Install the provider’s recommended full chain or bundle, not an arbitrary collection of certificate files. The exact file names and installation steps vary by hosting platform, so use the platform’s current documentation.
5. HTTPS loads, but the page reports mixed content
Mixed content occurs when an HTTPS page requests a resource over plain HTTP. Inspect the browser developer console to identify the blocked URL, then update the source to use HTTPS or a relative path. Check hard-coded image URLs, scripts, stylesheets, fonts, video embeds, analytics settings, API endpoints, and content stored in a CMS database.
Do not simply hide the warning. An insecure resource can remain a functional or security problem even when the main page has a valid certificate.
6. A CDN, reverse proxy, or hosting panel shows conflicting settings
Identify where HTTPS is terminated. It may be the web server, a reverse proxy, a cloud load balancer, or a CDN. The certificate must be valid at the visitor-facing endpoint, and the connection from that endpoint to the origin should use an appropriate secure configuration where required.
Check that the CDN has the correct custom domain, certificate, and origin hostname. On the origin server, verify that requests arriving through the proxy are handled correctly and that redirect rules do not create an HTTP-to-HTTPS loop. Change one setting at a time and test after each change.
What to double-check
Use this compact error-to-fix reference after the initial review:
| Observed problem | Likely area | First check |
|---|---|---|
| Certificate expired | Renewal or certificate management | Validity dates, renewal logs, and deployment status |
| Hostname mismatch | Certificate coverage | Names on the certificate versus the URL visitors use |
| Untrusted issuer or chain | Server certificate bundle | Intermediate certificates and the installed full chain |
| Wrong certificate appears | DNS, virtual host, CDN, or load balancer | Where the hostname resolves and which endpoint terminates HTTPS |
| Too many redirects | Proxy or redirect configuration | HTTPS mode at the CDN and origin, plus redirect rules |
| Mixed content warning | Application content | HTTP resource URLs in templates, code, plugins, or stored content |
Also verify that the server clock is accurate, the domain is not being tested through an old cache, and both IPv4 and IPv6 records lead to correctly configured endpoints. A valid IPv4 setup does not fix an incorrectly configured AAAA record if some visitors use IPv6.
When changing DNS or hosting, preserve business email records. Website troubleshooting should not lead to accidental removal of MX, SPF, DKIM, or DMARC records. The guide to SPF, DKIM, and DMARC setup covers those records separately.
Common mistakes
- Checking only one hostname: Test every public hostname, including redirects and subdomains.
- Renewing but not deploying: A new certificate must be attached to the service that receives visitor traffic.
- Changing DNS without recording the previous state: Export or document existing records before a migration.
- Testing only from an administrator’s browser: Use a private window and more than one network when practical.
- Ignoring the origin behind a CDN: A CDN certificate can be valid while the origin is misconfigured or expired.
- Using permanent redirects too early: Verify the HTTPS destination before enforcing HTTPS site-wide.
- Replacing files without checking permissions: The web service must be able to read the certificate and key securely.
Never share a private key in a support ticket or public repository. If you suspect that a private key was exposed, replace the certificate and key according to your certificate provider’s process.
When to revisit
Run this checklist before every planned certificate renewal, domain transfer, hosting migration, CDN change, or major DNS update. Recheck it after changing the site’s primary domain, adding a subdomain, replacing a load balancer, or moving a WordPress or application deployment.
For routine maintenance, schedule a periodic review of certificate expiry, renewal alerts, DNS records, HTTPS redirects, mixed content, and uptime monitoring. Review the process before seasonal planning cycles and whenever your hosting provider, certificate authority, browser behavior, or control-panel workflow changes.
Finish with a documented verification: open the root domain and key subdomains over HTTPS, confirm the expected certificate and expiration date, test redirects, inspect the browser console for mixed content, and check a representative page or transaction. If the error persists, preserve the exact hostname, timestamp, DNS result, endpoint, and browser message before contacting the hosting or CDN provider. Those details make the next troubleshooting step faster and safer.
For broader maintenance, combine this SSL review with the website security and uptime checklist, and record the result alongside your domain and hosting documentation.
