An SSL or HTTPS error usually has a specific cause: an expired certificate, an incorrect hostname, missing certificate-chain files, an incomplete redirect, or insecure content loaded by an otherwise secure page. This reusable SSL certificate troubleshooting checklist helps you identify the failure, apply the right fix, and verify that HTTPS continues to work after renewals, DNS changes, migrations, and site updates.
Overview
HTTPS depends on several connected parts. Your domain must resolve to the intended server, the server must present a valid TLS certificate, and that certificate must cover the hostname visitors are using. The server may also need to provide the intermediate certificates that let browsers build a trusted chain back to a certificate authority.
After the certificate is accepted, the page itself must load its resources securely. Images, stylesheets, scripts, fonts, API requests, and embedded content that still use http:// can create a mixed content error. Finally, redirects should send visitors from HTTP to HTTPS without creating loops or pointing some hostnames to the wrong destination.
Start by recording the exact browser message and the affected URL. Test both the bare domain and the www hostname if both are supported. Also test the site from a separate network or device, because cached certificates, DNS records, and redirects can make a local problem look like a server problem.
Checklist by scenario
“Your connection is not private” or an expired certificate warning
- Check the certificate’s expiration date and the server’s system time. An incorrect server clock can make a valid certificate appear invalid.
- Confirm that the certificate is installed on the server handling HTTPS traffic, not only in a hosting control panel or certificate store.
- Check whether automatic renewal completed. A renewal may have issued a new certificate without replacing the one actively served by the web server.
- Reload the site after restarting or reloading the relevant web server when your hosting workflow requires it. Follow the provider’s documented procedure rather than changing production configuration blindly.
If a certificate has expired, avoid treating the browser warning as a cosmetic issue. Visitors may be blocked or warned, and automated clients may reject the connection entirely. For a broader launch review, use the website launch checklist to verify domain, hosting, SSL, and redirect settings together.
Hostname mismatch errors
A hostname mismatch means the certificate does not cover the exact name being visited. Compare the address in the browser with the names listed in the certificate. Check variations such as:
example.comversuswww.example.com- A staging or temporary hosting hostname versus the public domain
- A subdomain such as
shop.example.comthat was not included during certificate issuance - An old domain still referenced by DNS, redirects, or a reverse proxy
Correct the DNS or hosting target if the hostname is pointing to the wrong service. If the destination is correct, request or install a certificate that explicitly covers every hostname the site is meant to serve. Do not assume that one certificate configuration automatically covers every subdomain.
Certificate chain or trust errors
If a browser reports an incomplete chain, unknown issuer, or similar trust problem, the server may be sending only the site certificate and omitting an intermediate certificate. Obtain the correct chain bundle from the certificate issuer or hosting provider, install it in the format required by your server, and test again.
Be careful not to combine certificates from different issuers or upload a private key where a certificate-chain file is expected. If the site sits behind a CDN, load balancer, or reverse proxy, inspect the TLS configuration at that public edge as well as at the origin server. The browser evaluates what the public endpoint sends.
HTTP redirects, loops, or partially secure pages
Confirm that the HTTPS version loads directly before creating an HTTP-to-HTTPS redirect. Then check the redirect path for both the root domain and important pages. A redirect loop can occur when a proxy terminates TLS but the origin application believes the request is still HTTP. Review proxy or forwarded-protocol settings with your hosting provider or platform documentation.
For a mixed content error, inspect the browser’s developer tools and identify each insecure request. Update hard-coded asset URLs, theme or plugin settings, database content, canonical references, JavaScript configuration, and third-party integrations. Replace supported resources with HTTPS URLs and remove or replace resources that cannot be loaded securely.
HTTPS broke after a migration or DNS change
Verify the DNS records first, then confirm which server answers on ports 443 and 80. Make sure the new server has the correct certificate, private key, chain, virtual-host configuration, and redirect rules. Keep the old environment available until the new endpoint has been tested across all required hostnames. The website migration checklist provides a useful companion sequence for reducing avoidable cutover errors.
What to double-check
- DNS scope: Check A, AAAA, CNAME, and relevant proxy records. An unexpected IPv6 record can send some visitors to a server with different TLS settings.
- Every public hostname: Test the apex domain,
www, required subdomains, and any redirect-only hostnames. - Renewal automation: Confirm that the renewal account, DNS validation record, HTTP validation path, and deployment hook are still available.
- Server configuration: Confirm that the certificate, private key, and intermediate chain belong together and are attached to the correct virtual host.
- Application URLs: Search configuration files and stored content for absolute HTTP links. Content management systems may retain old URLs after a migration.
- Caches: Clear relevant application, CDN, browser, and redirect caches only after confirming the underlying configuration is correct.
- Monitoring: Add certificate-expiry and availability checks to your normal website uptime monitoring workflow.
Common mistakes
One frequent mistake is renewing a certificate but failing to deploy it to the server that actually receives traffic. Another is testing only one hostname while visitors use another. It is also easy to fix the homepage while leaving images, scripts, API endpoints, or canonical URLs on HTTP.
Do not disable certificate verification in browsers, applications, or deployment tools as a permanent workaround. Do not copy a certificate configuration from staging without checking its domain names and private key. Avoid changing DNS, proxy, redirect, and application settings simultaneously; make one controlled change at a time so the cause remains identifiable.
When troubleshooting WordPress, back up before making database-wide URL replacements and test the result on a staging copy where possible. The WordPress backup and restore checklist can help establish a recovery point before site-wide changes.
When to revisit
Revisit this checklist before a certificate’s renewal window, a domain transfer, a DNS provider change, a hosting migration, a CDN or load-balancer change, or a major WordPress, theme, or application deployment. It is also worth reviewing after adding a new subdomain or integrating a third-party payment, analytics, support, or API service.
After each change, use this short verification routine:
- Open each required hostname directly over HTTPS.
- Check the certificate name, issuer, validity dates, and chain.
- Confirm that HTTP redirects once to the intended HTTPS URL.
- Inspect the page for mixed content and failed secure requests.
- Test a representative form, login, checkout, API call, or other critical workflow.
- Confirm that monitoring and renewal notifications still reach the responsible team.
Keep a brief record of the certificate location, renewal method, DNS owner, proxy or CDN settings, and last successful verification. That documentation turns the next HTTPS error from an emergency investigation into a repeatable maintenance task.
