SSL Certificate Errors Explained: Fix HTTPS, Mixed Content, and Renewal Problems

Overview

HTTPS depends on several systems working together: your domain’s DNS records, the web server, the TLS certificate, the certificate’s covered hostnames, and the content loaded by each page. An error in any one of these areas can produce an HTTPS not secure warning or prevent a page from loading.

Start by recording the exact error and the affected URL. Test the root domain, the www hostname, and any important subdomains separately. Also test in a private browser window or a second browser. This helps distinguish a server-side problem from stale browser data, an extension, or a local network issue.

Do not begin by repeatedly reinstalling the certificate. First identify which category fits the symptom:

• Expired or not yet valid: the certificate’s validity dates do not include the current time.
• Hostname mismatch: the certificate does not cover the exact domain being visited.
• Trust or chain problem: the server is not presenting the certificate chain correctly, or the client cannot establish trust.
• DNS or validation failure: the domain points to the wrong service, or a certificate authority cannot complete its ownership check.
• Mixed content: the page uses HTTPS but requests images, scripts, stylesheets, fonts, or other resources over HTTP.
• Redirect loop: the browser is sent repeatedly between HTTP and HTTPS, or between application and proxy settings.

For background on the records that control where a domain resolves, see DNS Records Explained: A, CNAME, MX, TXT, and More for Your Website. If you are launching a new site, the broader Website Launch Checklist can help you check SSL alongside backups, email, and security settings.

Checklist by scenario

1. The certificate is expired or renewal failed

1. Open the certificate details in a browser or hosting control panel and check the expiration date.
2. Confirm that the server is presenting the newly issued certificate rather than an older one cached in a different virtual host.
3. Check whether automatic renewal is enabled and whether the renewal log reports a validation, permission, DNS, or rate-related failure.
4. Verify that the domain still resolves to the server responsible for answering the validation request.
5. After correcting the cause, run renewal again and test from outside the hosting server.

If the site was recently moved, renewal may still be targeting the old host. Confirm which platform controls DNS, which platform serves the website, and which platform manages the certificate. These responsibilities can be split across a registrar, DNS provider, CDN, and hosting provider.

2. The browser reports a hostname mismatch

Compare the URL in the address bar with the names listed in the certificate. A certificate for example.com does not automatically prove coverage for every possible subdomain, and a certificate for www.example.com may not cover the apex domain unless both names are included.

• Check both the root domain and www version.
• Check whether a staging, shop, app, or API subdomain needs its own certificate coverage.
• Review the web server’s site or virtual-host mapping to ensure the hostname reaches the intended site.
• Make sure a proxy or CDN is not presenting a certificate for a different account or origin.

Do not solve a mismatch by redirecting blindly. A redirect cannot happen safely if the browser rejects the first HTTPS connection before the server can return the redirect.

3. The certificate cannot be issued or renewed

Most automated issuance workflows need to confirm control of the domain. The exact method depends on the certificate provider and hosting platform, but common checks use a temporary HTTP file, a DNS record, or an email-based process. Review the failed validation message rather than deleting records at random.

1. Confirm that the requested hostname is spelled correctly.
2. Check that authoritative DNS contains the expected A, AAAA, or CNAME record.
3. Look for conflicting records, especially an unexpected AAAA record pointing to an unavailable server.
4. Ensure validation files or DNS challenge records are not blocked by redirects, access rules, a firewall, or a content delivery layer.
5. Allow time for DNS changes to become visible, then use a DNS propagation checker from more than one location.

For a deeper domain-to-server workflow, use How to Connect a Domain to Web Hosting: DNS Records, SSL, and Propagation Checklist.

4. The page loads, but shows mixed content

Mixed content occurs when an HTTPS page requests a resource using an http:// URL. Start with the browser’s developer console or security panel to identify the blocked resource. Search the site configuration, templates, database content, and scripts for the insecure URL.

• Change internal image, stylesheet, script, font, and API URLs to HTTPS.
• Update a site’s configured URL and canonical settings after moving it to HTTPS.
• Check third-party resources, embedded media, payment components, and analytics code.
• Regenerate cached pages and clear application, CDN, and browser caches after changes.

Do not assume that adding a redirect fixes mixed content. The browser may block an insecure request before the redirect is followed, and third-party content may not support HTTPS at all.

5. HTTPS redirects loop or the site is inaccessible

Inspect every layer that can redirect traffic: the application, web server, hosting panel, reverse proxy, and CDN. A common cause is that the proxy receives HTTPS from the visitor but forwards HTTP to the origin, while the application believes the visitor is using HTTP and redirects again.

1. Temporarily identify which layer generates each redirect.
2. Confirm that the application trusts the proxy’s forwarded protocol information only when the proxy is trusted.
3. Use one canonical HTTPS destination and remove competing HTTP-to-HTTPS rules.
4. Check that the origin certificate and proxy encryption mode agree with the intended setup.
5. Test with command-line headers or a redirect inspection tool, not only a browser.

Quick SSL troubleshooting table

What to double-check

Before changing production settings, make a short inventory of the HTTPS setup:

• DNS ownership: identify the authoritative nameservers and confirm where A, AAAA, CNAME, and validation records are managed.
• Domain coverage: list every hostname that must work, including the root domain, www, subdomains, and any aliases.
• Certificate deployment: verify that the certificate and its intermediate chain are installed on the server, proxy, or load balancer actually serving traffic.
• Renewal access: confirm that the renewal account, DNS API credentials, validation directory, and required permissions still work.
• TLS configuration: use the hosting provider’s maintained secure defaults where possible. Avoid copying old cipher or protocol settings from an outdated tutorial.
• Application URLs: update absolute HTTP links, canonical URLs, API endpoints, and environment variables.
• Monitoring: record the certificate owner, renewal method, covered hostnames, and an alert destination before an expiration becomes urgent.

Keep a backup of DNS records and application configuration before a migration. If you are changing providers, plan the DNS and certificate sequence in advance; the guide to transferring a domain without downtime covers related migration planning.

Common mistakes

• Checking only one hostname: the root domain and www hostname may use different DNS targets or certificates.
• Changing DNS without recording the current setup: this can interrupt email, verification records, or other services.
• Installing a certificate on the wrong layer: a certificate on the origin does not correct a certificate served by a CDN or reverse proxy.
• Forcing HTTPS before fixing application URLs: this can expose mixed content and broken API requests.
• Ignoring IPv6: an incorrect AAAA record can send some visitors to a different or unavailable server even when the A record is correct.
• Deleting validation records too soon: some automated renewal workflows need their DNS or file-based validation path to remain available.
• Testing only from a cached browser: use a private window, another network, and an external certificate or DNS inspection tool.
• Disabling certificate verification: this hides the symptom without securing the connection and should not be used as a production fix.

When to revisit

Revisit this checklist before a certificate’s renewal window, a domain or DNS change, a hosting migration, a CDN rollout, a major application release, or a security review. It is also worth reviewing after changing nameservers, enabling IPv6, replacing a reverse proxy, or moving email and website services to separate providers.

At each review, confirm the exact browser wording, the hosting-panel path for certificate management, the certificate provider’s validation requirements, and the provider’s recommended TLS settings. Interfaces and requirements can change, so current platform documentation should take priority over screenshots or commands from older guides.

For a practical maintenance routine, schedule these actions:

1. List every public hostname and test HTTPS on each one.
2. Check certificate dates, coverage, chain delivery, and renewal status.
3. Inspect DNS records and confirm that they point to the intended service.
4. Scan important pages for mixed content and redirect loops.
5. Verify that alerts reach someone who can renew or correct the configuration.
6. Document the final setup so the next domain, hosting, or security change starts with accurate information.

If the error remains after these checks, preserve the exact hostname, timestamp, browser message, DNS results, certificate details, and recent configuration changes before contacting hosting or certificate support. That evidence usually makes the problem easier to isolate without introducing more changes.