AdminsForum
Guide CloudPanel SSL Renewal Failed: Diagnose and Fix HTTPS - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: CloudPanel (https://adminsforum.com/Forum-cloudpanel)
+---- Forum: CloudPanel Guides & Tutorials (https://adminsforum.com/Forum-cloudpanel-guides-tutorials)
+----- Forum: CloudPanel Domains, DNS & SSL Guides (https://adminsforum.com/Forum-cloudpanel-domains-dns-ssl-guides)
+----- Thread: Guide CloudPanel SSL Renewal Failed: Diagnose and Fix HTTPS (/Thread-guide-cloudpanel-ssl-renewal-failed-diagnose-and-fix-https)



CloudPanel SSL Renewal Failed: Diagnose and Fix HTTPS - DEV - 10-16-2026

If a CloudPanel SSL certificate has expired or renewal failed, identify the affected hostname and the first renewal error before requesting another certificate. DNS, validation access, scheduling and certificate deployment are separate failure points.

This CloudPanel v2 diagnostic guide is checked against official CloudPanel and Let's Encrypt documentation. It is not a claim of a newly reproduced lab outage. The branded image is a workflow illustration. Replace example.com with your own hostname in the read-only commands below.

[Image: attachment.php?aid=350]
AdminsForum SSL workflow: identify the certificate, check validation, read the failure and verify the certificate actually served.

1. Which certificate is failing?
Record the exact URL and hostname, error message and time. Separate the website certificate from the CloudPanel login certificate and any CDN certificate. A certificate for example.com does not automatically cover www.example.com or cp.example.com.

Open the affected site in CloudPanel and inspect its SSL/TLS area. Note certificate names and validity dates. Check the browser's certificate information from a normal connection; do not bypass warnings or submit login details through a failing connection.

If Cloudflare or another CDN is in front, visitors usually see its edge certificate. The CloudPanel origin certificate is a different layer. A valid edge certificate does not prove the origin certificate is valid. Avoid changing several TLS settings at once merely to hide the error.

2. Confirm DNS for every certificate name
On a machine with dig installed:
Code:
dig +short example.com A dig +short example.com AAAA dig +short www.example.com A dig +short www.example.com AAAA
Compare answers with the intended public service. With a CDN, public records may intentionally return CDN addresses; check the configured origin in the provider account too. Check every name requested on a multi-name certificate, not only the homepage domain.

A stale AAAA record can send validation to a different server. Let's Encrypt generally prefers IPv6 initially when both address families exist, and a server returning the wrong challenge content is different from a connection timeout. Correct a broken IPv6 setup rather than assuming working IPv4 makes it irrelevant. Confirm authoritative DNS and propagation before retrying issuance.

3. Check the HTTP validation path
For HTTP-01, the validation URL uses port 80 and the path /.well-known/acme-challenge/. A custom panel port cannot replace that validation port. Confirm that the provider firewall, server firewall and web-server routing allow the required request to reach the correct website.

A basic external check is:
Code:
curl -I --max-time 15 http://example.com/ curl -I --max-time 15 http://example.com/.well-known/acme-challenge/adminsforum-check
These use HEAD and are only routing clues; validation uses the actual challenge request. A 404 for this invented filename can be normal. It does not prove a real token will be served correctly. Check the genuine challenge request and returned content during an authorized issuance attempt.

Investigate login protection, redirects, rewrite rules, proxy routing or a CDN challenge page if they intercept the validation URL. Keep changes limited to the needed validation route; do not disable protection across the whole server. A wildcard certificate requires a supported DNS-based validation workflow rather than HTTP-01.

4. Read the actual renewal failure
Use the installed version's error output and logs to find the first relevant message. Correlate it with the attempt time and affected hostname. Our CloudPanel logs guide explains how to match requests and logs.
  • Unauthorized or incorrect challenge response: inspect the returned content, DNS target and routing.
  • Connection timeout or refused: inspect reachability and the web-server listener.
  • Rate limited: stop retrying and follow the reported retry timing.
  • CAA-related failure: inspect the domain's certificate-authority authorization with your DNS administrator.
  • No recent renewal attempt: investigate the scheduling mechanism rather than repeatedly reissuing.
  • Certificate issued but visitors see the old one: investigate deployment, routing and the certificate served at each endpoint.
Keep ACME account information, private keys, DNS API tokens and unredacted debug logs out of public support posts.

5. If no renewal attempt ran, inspect scheduling
Read-only SSH checks can help establish time and installed services:
Code:
date -Is timedatectl systemctl list-units --type=service --all | grep -Ei 'clp|cron' systemctl list-timers --all
Match the scheduler to your actual CloudPanel package version. Not all scheduled jobs appear as systemd timers. Inspect the status and journal of the service you actually find; do not invent a new renewal cron job while an existing one may already manage the certificates.

An older CloudPanel renewal discussion contains community workarounds. Treat them as historical reports, not universal instructions for a current installation. Check supported commands and current release notes before using an old internal command or third-party script. Running a second certificate manager against the same site can create conflicting ownership and renewal paths.

6. Retry only after correcting the cause
Preserve the working configuration and identify the exact domain list before requesting a certificate. CloudPanel documents the site SSL/TLS Actions menu and New Let's Encrypt Certificate flow. Our CloudPanel certificate installation guide covers that interface.

Make one controlled attempt after the DNS or validation issue is corrected. Save the result. A successful reissue restores a certificate but does not, by itself, prove automatic renewal is fixed. If the CA reports a rate limit, use its indicated retry time rather than repeated attempts or changing domain lists to evade the limit.

For externally imported certificates, confirm which tool or provider is responsible for renewal and installation. Do not assume CloudPanel's Let's Encrypt workflow renews every imported certificate.

7. Verify the live certificate and HTTPS
From an external machine, test without disabling certificate verification:
Code:
curl -I --max-time 15 https://example.com/
A certificate-validation error is not a successful check. A valid connection followed by an application redirect or access response is different from a TLS failure. Also inspect the leaf certificate presented for the hostname:
Code:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
This command displays certificate details; it is not a complete chain-trust or application-health test. Check that the hostname is covered and the new validity dates are correct. Repeat for www and other names that visitors use. If a CDN is present, this checks the public edge; verify origin TLS separately through the supported provider/origin configuration.

Avoid the curl -k option as a success test because it skips certificate verification. Also confirm that the application still works and redirects do not loop after the certificate change.

8. Prevent the next expiry
Monitor the certificate actually served by the public site and the origin where applicable. Set an expiry alert early enough to investigate, rather than assuming a fixed certificate lifetime. Record who owns renewal, where failures are logged and the last successful automated attempt.

After a manual recovery, continue checking the normal renewal mechanism. Keep the validation route and correct DNS working. Test configuration changes that affect redirects, DNS, proxies and access controls before they silently break renewal.

Need help?
Post your CloudPanel version, certificate hostname, redacted first error, last successful renewal and whether a CDN is used in CloudPanel Support & Troubleshooting. Explain what you checked and avoid posting private keys or API credentials.

References
CloudPanel SSL/TLS certificates
Let's Encrypt challenge types
Let's Encrypt IPv6 validation behavior
Let's Encrypt rate limits