Let’s Encrypt HTTPS Troubleshooting Checklist: Certificate Errors, Redirects, and Renewal Failures

Overview

HTTPS problems usually come from a mismatch between four layers: the domain’s DNS records, the server that answers on the public internet, the certificate installed on that server, and the application or proxy handling redirects. Begin by identifying exactly what is failing. A certificate can be valid while the website still shows mixed content. A renewal can fail even though the current certificate has not expired. A redirect can loop because a reverse proxy and the origin server disagree about whether the request is secure.

Record the affected hostname, the time the problem began, the browser or command-line error, and whether the issue affects every visitor or only one network. Test both the root domain and relevant subdomains separately. For example, example.com, www.example.com, and app.example.com may use different DNS records, virtual hosts, certificates, or hosting platforms.

Use a controlled sequence: check DNS, check reachability, inspect the certificate, verify the web-server configuration, then test renewal. Keep a backup of configuration files before making changes. For installation and renewal details, see the Let’s Encrypt certificate guide for Nginx and Apache.

Checklist by scenario

The browser reports an expired or invalid certificate

• Confirm the hostname in the browser matches a name covered by the certificate. A certificate for www.example.com does not automatically cover every other subdomain.
• Inspect the certificate’s validity period and issuer. Check the server currently answering the request, not just a certificate file stored on disk.
• Check the server clock. An incorrect system time can make a certificate appear not yet valid or expired.
• Verify that the web server is presenting the complete certificate chain expected by clients. A missing intermediate certificate can produce trust errors in some environments.
• Confirm that DNS is sending traffic to the intended server. Old hosting, a proxy, or an overlooked IPv6 record can expose a different certificate.

To inspect a live endpoint from a terminal, you can use an OpenSSL client and specify the server name:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Review the names, dates, and chain returned by the server. If the result differs from the certificate you expected, investigate DNS, the reverse proxy, and the active virtual-host configuration.

HTTPS is not reachable

• Confirm the hostname resolves to the expected address with dig or another DNS lookup tool.
• Check both A and AAAA records. If IPv6 is published but the server is not configured for it, some clients may reach the wrong endpoint or fail to connect.
• Confirm that TCP port 443 is open in the host firewall, cloud security group, and any upstream network firewall.
• Make sure the web server is listening on the public interface, not only on localhost.
• Check whether a CDN, load balancer, or hosting control panel terminates TLS before the request reaches your origin.

Do not assume that a successful HTTP test proves HTTPS is configured. Port 80 and port 443 can be handled by different services or configuration blocks.

The ACME challenge fails during issuance or renewal

First identify the challenge type. HTTP-01 normally requires the certificate authority to retrieve a token from a predictable HTTP path on the requested hostname. DNS-01 requires a particular TXT record under the domain. A challenge fails when the public validation request cannot reach the expected token or record.

• For HTTP-01, verify that the hostname resolves to the machine running the ACME client and that port 80 is reachable.
• Check whether an HTTP-to-HTTPS redirect, authentication rule, application route, or security plugin blocks the challenge path.
• For DNS-01, confirm the TXT record is created at the correct name and with the exact value supplied by the ACME client.
• Remove stale challenge records only after confirming they are no longer needed; multiple TXT values may be required during overlapping validations.
• Review ACME client logs for the failing domain, challenge type, and authorization response rather than relying on a shortened dashboard message.

Wildcard certificates generally use DNS-01. The DNS-01 and wildcard certificate guide covers the record and automation considerations in more detail.

Renewal fails even though the current certificate still works

• Run the renewal process in a safe test mode supported by your ACME client, such as Certbot’s renewal dry run.
• Check that the scheduled job, timer, or hosting-panel task still exists and runs under the account with access to the required files and ports.
• Confirm that DNS, firewall rules, web-server paths, and API credentials have not changed since the original issuance.
• Verify that the renewal hook reloads the web server after a successful certificate update.
• Inspect disk space, file permissions, and service logs if the client can obtain a certificate but cannot install or reload it.

A successful renewal test is not complete until the newly selected certificate is served by the live endpoint. Use the automatic Certbot renewal guide to review the complete workflow.

The site redirects repeatedly or never reaches the secure page

• Map the redirect chain with browser developer tools or a command such as curl -I http://example.com.
• Check whether both the proxy and the origin force HTTPS independently.
• Ensure the application trusts the proxy’s forwarded-protocol header when TLS terminates upstream.
• Look for conflicting rules in Nginx, Apache, a CMS, a plugin, and the hosting platform.
• Test the canonical hostname separately from alternate hostnames, such as the bare domain and www.

Redirects should normally converge on one canonical HTTPS URL. For implementation examples, review the guide to forcing HTTPS safely.

The browser reports mixed content

Mixed content means the page itself loaded over HTTPS but requested one or more assets over HTTP. Open the browser console to identify the exact URL, then update the source in the template, CMS settings, database, stylesheet, JavaScript, image, iframe, or third-party integration that generated it. Search for hard-coded http:// references and verify that external services support HTTPS. Do not treat a redirect as a complete fix for every asset: update the stored URL where possible. See the mixed-content troubleshooting guide for a focused checklist.

What to double-check

Before changing configuration, verify the scope of the certificate. A single-domain certificate, a certificate containing multiple subject alternative names, and a wildcard certificate solve different hostname requirements. Compare the certificate names with the URLs visitors actually use. The subdomain certificate strategy guide can help when a site has several hostnames.

Check CAA records if issuance is refused even though DNS and the server appear correct. A CAA policy can restrict which certificate authorities may issue for a domain, so confirm that its value matches your intended certificate workflow. Review the CAA records guide before editing this security control.

Also compare the live configuration with the files you edited. Nginx and Apache may load an enabled site from a different path, while a control panel or container may regenerate configuration during deployment. After a change, validate syntax, reload the service, and test the public endpoint.

Common mistakes

• Testing only one network: cached DNS, split DNS, proxies, and IPv6 can make results differ between locations.
• Renewing manually without fixing automation: a manual certificate replacement hides the scheduled-job, permission, or challenge problem that will return later.
• Changing several layers at once: editing DNS, firewall rules, redirects, and certificates together makes the successful change difficult to identify and the next failure harder to diagnose.
• Ignoring the proxy: TLS may terminate at a CDN or load balancer, so the origin certificate may not be the certificate visitors see.
• Assuming propagation is instant: DNS changes can be observed differently while caches expire. Check authoritative answers and allow time for the intended record to become visible.
• Forgetting non-production hosts: staging, preview, API, mail, and administrative subdomains may have separate certificates and renewal jobs.

When to revisit

Keep this checklist with your deployment documentation and use it before planned hosting migrations, DNS changes, proxy changes, firewall updates, or certificate configuration changes. Revisit it after adding a subdomain, changing the ACME client, moving from HTTP-01 to DNS-01, introducing a CDN or load balancer, or changing the web server.

At regular maintenance intervals, confirm that automated renewal is still scheduled, run a safe renewal test, inspect recent logs, and verify that the live certificate and redirect chain are correct. After every change, record the hostname, DNS target, TLS termination point, certificate method, renewal command, and rollback procedure. If the issue remains unclear, preserve the error output and configuration state before escalating; reproducible evidence is more useful than repeated manual retries.

For a broader migration review, use the website migration checklist. For error terminology and ACME responses, consult the Let’s Encrypt error codes guide.