A CAA record added for security hardening silently blocks AutoSSL renewal.
cPanel logs the failure in /var/cpanel/logs/autossl.log. WHM still shows "AutoSSL: Enabled" in green.
cPanel/WHM agencies running AutoSSL on shared hosting deal with CAA records blocking Let's Encrypt issuance where AutoSSL silently skips renewal (the failure is logged to /var/cpanel/logs/autossl.log but doesn't surface in WHM unless someone opens the log explicitly), ConfigServer Security & Firewall rules blocking Let's Encrypt validator IPs from reaching the HTTP-01 challenge path (CSF marks the validator requests as suspicious and drops them), and addon domain / subdomain document_root mismatches where AutoSSL provisions per-document-root and the challenge is served from the wrong directory. Merlonix monitors the served cert directly at every cPanel-hosted subdomain so silent AutoSSL failures surface before the existing cert expires.
No credit card for the trial. Cancel any time.
- Check cadence (Agency)
- 5 min
- SSL pre-expiry alert
- 30 days
- Independent DNS resolvers
- 3
- Vendors watched
- 11
Where cPanel agencies get caught out
Three failure modes specific to cPanel/WHM AutoSSL deployments: CAA records blocking Let's Encrypt issuance silently, CSF / LFD firewall rules dropping Let's Encrypt validator connections, and addon domain / subdomain document_root mismatches between AutoSSL metadata and Apache virtual host configuration.
cPanel agencies deal with CAA records added for security hardening that block Let's Encrypt issuance (AutoSSL logs the failure to /var/cpanel/logs/autossl.log but WHM's main dashboard still shows "AutoSSL: Enabled" in green — per-domain failures are aggregated in a sub-panel nobody opens), CSF firewall rules dropping the Let's Encrypt validator's connection attempts as suspicious activity (the validator hits LFD's pattern matching and every retry times out), and addon domain / subdomain document_root mismatches between AutoSSL's metadata layer and Apache's virtual host configuration (typically after a host migration where the document_roots were re-imported but AutoSSL metadata wasn't regenerated) where the HTTP-01 challenge token is written to a directory Apache doesn't serve from for that hostname.
CAA (Certification Authority Authorization) records were added to DNS as a security hardening practice — they tell CAs which authorities are permitted to issue certs for a domain. Agencies adding CAA records to a client's domain (best practice for high-value sites) often forget to include letsencrypt.org in the allowed-issuer list. AutoSSL's Let's Encrypt integration queries the CAA record before requesting a cert; if Let's Encrypt is not on the allowed list, the issuance is rejected. AutoSSL logs the failure to /var/cpanel/logs/autossl.log and skips that domain's renewal silently. WHM still shows "AutoSSL Status: Enabled" in green. The existing cert continues serving until expiry
A cPanel agency manages 40+ client sites on a single shared-hosting reseller account. The agency adds CAA records to the high-value client domains as part of a security audit recommendation — CAA records specify which CA can issue certs for the domain, blocking accidental issuance by other CAs (a defense against insider threats and compromised CA infrastructure). The agency engineer adds CAA records pointing at Sectigo (the agency's primary CA) but forgets to add letsencrypt.org as a permitted issuer. AutoSSL's next renewal cycle (90 days before expiry) queries the CAA record, finds Let's Encrypt is not permitted, logs the failure to /var/cpanel/logs/autossl.log, and skips the domain. WHM's AutoSSL dashboard shows the account as "AutoSSL: Enabled" — the resource state is enabled, the failure is just at the per-domain level. The existing cert continues serving until expiry. Discovery happens 90 days later when the cert expires
A cPanel agency operates a portfolio of 40+ high-value client websites on a shared-hosting reseller account (HostGator's reseller plan with WHM access). The agency's security lead recommends CAA records for all high-value client domains as part of a post-audit hardening project — CAA records pin which Certification Authorities can issue certs for the domain, blocking accidental or malicious issuance by other CAs. The agency's preferred CA for EV/OV certs (which several enterprise clients use) is Sectigo. The security lead adds CAA records: `0 issue "sectigo.com"` for the apex of each high-value client domain. The lead doesn't add `0 issue "letsencrypt.org"` because the assumption is that AutoSSL is using Sectigo too (a common misunderstanding — AutoSSL is Let's Encrypt-based by default on cPanel, even though Sectigo offers an AutoSSL-compatible integration). AutoSSL's next renewal cycle for these domains queries the CAA record, gets `0 issue "sectigo.com"`, and concludes Let's Encrypt is not permitted. AutoSSL logs "Skipping domain example.com: CAA record disallows issuance by Let's Encrypt" to /var/cpanel/logs/autossl.log and moves on. The autossl.log entry is one of thousands per day on a busy WHM (the log records every domain decision, not just failures); nobody scrolls through it. WHM's main AutoSSL dashboard shows "AutoSSL: Enabled" with the green check — the resource state is enabled; the per-domain decision failures are aggregated as a count buried in a sub-panel. The existing cert continues serving for 90 more days. Then the cert expires. Browsers start throwing warnings. The agency engineer runs `whmapi1 fetch_ssl_certificates_info domain=example.com` and sees the cert has expired; runs `whmapi1 start_autossl_check_for_one_user` and watches the AutoSSL run — sees the CAA failure in the live log; realizes the CAA records are blocking it; adds `0 issue "letsencrypt.org"` to the DNS record; AutoSSL succeeds on the next cycle. Total downtime: 4 hours of broken HTTPS for the client's site.
ConfigServer Security & Firewall (CSF) is bundled with most managed cPanel installs as the security baseline. CSF's LFD (Login Failure Daemon) watches connection patterns and drops connections from IPs flagged as suspicious — including request rates from automated scanners, port-probing patterns, and unusual user agents. Let's Encrypt's validator requests the HTTP-01 challenge token from /.well-known/acme-challenge/<token> using a known IP range and a distinctive user agent. CSF's default LFD settings may flag this pattern as suspicious and drop subsequent connections. AutoSSL retries every 6 hours; every retry fails. The cPanel admin doesn't connect CSF's drop log to AutoSSL's renewal failures because the two systems live in different parts of WHM
A cPanel agency hardens a client's shared-hosting account by enabling CSF (ConfigServer Security & Firewall) and tuning LFD (Login Failure Daemon) thresholds aggressively to stop brute-force attacks on cPanel login. Subsequent AutoSSL renewal cycles for the client's domains start failing — LFD is silently dropping the Let's Encrypt validator's connection attempts as "suspicious activity" because the request pattern doesn't look like a normal browser. CSF logs the drops to /var/log/lfd.log; AutoSSL logs the renewal failures to /var/cpanel/logs/autossl.log. Two different logs, two different parts of WHM, no automatic correlation
A cPanel agency manages a client portfolio that includes high-traffic e-commerce sites. The agency completes a security audit and enables CSF on every reseller account in the portfolio. CSF default settings are reasonable but the agency's security engineer tunes the LFD (Login Failure Daemon) more aggressively — lower thresholds for connection-drop triggers, longer block durations, stricter user-agent filtering. The audit is complete; the security engineer moves to the next project. Three months later (when the existing certs approach renewal), AutoSSL starts attempting renewals. Let's Encrypt's validator sends an HTTP request to /.well-known/acme-challenge/<token> on the client's domains. The request originates from one of Let's Encrypt's documented validator IP ranges (e.g., 23.178.112.*, 23.178.113.*) with the user agent "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)". CSF's LFD sees the request pattern: one-off connection to a specific path, no follow-up requests, an unusual user agent that doesn't match common browsers. LFD flags the IP as potentially malicious and drops subsequent connections from that IP range for 24 hours. AutoSSL doesn't receive an explicit error from Let's Encrypt — it just sees a timeout. AutoSSL logs "ACME challenge timed out for example.com" to /var/cpanel/logs/autossl.log and retries 6 hours later. The retry fails the same way (LFD has blocked the IP range for 24 hours; the retry uses a different Let's Encrypt validator IP from the same range, hits LFD's block, gets dropped). The pattern repeats. The existing cert continues serving for 30 more days. Then the cert expires. The agency engineer runs the standard AutoSSL diagnostic, sees timeout errors, checks Let's Encrypt's status (no incident), wonders why every retry is timing out. Discovery requires checking /var/log/lfd.log, which the agency engineer didn't think to do because LFD and AutoSSL are different concerns. The fix is to whitelist Let's Encrypt's validator IP ranges in CSF (csf.allow), but the diagnosis takes hours.
cPanel addon domains, subdomains, and parked domains have their own document_root settings — the directory under public_html where each domain's content lives. AutoSSL provisions certs by writing the HTTP-01 challenge token to /<document_root>/.well-known/acme-challenge/<token>. If a subdomain's document_root is misconfigured (a common mistake during cPanel migrations or when copy-pasting addon domain configurations), AutoSSL writes the challenge to the wrong directory. The Let's Encrypt validator's HTTP request hits the subdomain's actual content directory, gets a 404, fails validation. AutoSSL retries; every retry fails because the document_root mismatch is persistent
A cPanel agency adds api.example.com as a subdomain in cPanel for a client's API service. The agency engineer uses cPanel's subdomain creation flow; the default document_root path interpolation auto-fills public_html/api as the directory. The engineer is migrating an existing app from a different folder structure and types over the auto-filled path with public_html/example.com/api. The subdomain creation succeeds. The application content is served correctly from the new document_root. AutoSSL's next renewal cycle attempts the HTTP-01 challenge; it writes the challenge token to the cPanel-configured document_root (public_html/api) but the Let's Encrypt validator hits the document_root the agency engineer actually uses (public_html/example.com/api), gets a 404 for the .well-known path, fails the challenge. AutoSSL logs the failure; the existing cert serves until expiry
A cPanel agency migrates a client app from one cPanel host to another. The new host has cPanel 110+ with a slightly different subdomain creation flow than the previous host. The agency engineer creates api.example.com as a subdomain in cPanel. cPanel's default document_root for a subdomain is /home/<user>/public_html/api (the subdomain name auto-fills as the directory name). The engineer is moving an application that was previously organized as /home/<user>/public_html/example.com/api on the old host; to keep the migration consistent, the engineer overrides the auto-filled document_root with /home/<user>/public_html/example.com/api. cPanel accepts the override; the subdomain is created with the custom document_root. The application content is served correctly — when a user requests https://api.example.com, Apache (or LiteSpeed) routes the request to the configured document_root, serves the content. The site works. AutoSSL has its own metadata layer that tracks per-document-root for cert provisioning. When AutoSSL attempts the HTTP-01 challenge 80 days later, it consults its metadata, finds that api.example.com's document_root is /home/<user>/public_html/example.com/api (the override), writes the challenge token to /home/<user>/public_html/example.com/api/.well-known/acme-challenge/<token>. Let's Encrypt's validator queries http://api.example.com/.well-known/acme-challenge/<token>; Apache routes the request to the same document_root, finds the token, returns it. So far so good. But on SOME cPanel installs (depending on cPanel version and the order of subdomain/addon-domain creation), AutoSSL's metadata can drift from Apache's actual virtual host configuration — particularly after a migration from another host where the document_root values were re-imported but the AutoSSL metadata wasn't regenerated. AutoSSL writes to the OLD document_root (cached from the import); Apache serves from the NEW document_root. The challenge token is written to a directory that Apache doesn't serve from for this hostname; the validator gets a 404. AutoSSL retries; every retry fails because the metadata drift is persistent until someone manually runs whmapi1 rebuild_apache_conf. Discovery requires understanding the difference between cPanel's AutoSSL metadata and Apache's actual virtual host configuration.
How it works
SSL and DNS monitoring for cPanel agencies across AutoSSL CAA-block silent skips, CSF firewall dropping Let's Encrypt validators, and document_root mismatches between AutoSSL metadata and Apache configuration.
Merlonix monitors SSL expiry and DNS integrity across every cPanel-hosted subdomain — app.* and api.* (AutoSSL-managed), plus addon domains and parked domains on the same account — and catches AutoSSL CAA-block failures (the existing cert serves until expiry while WHM's dashboard shows AutoSSL enabled in green), CSF firewall drops of Let's Encrypt validators (every renewal retry times out the same way), and document_root mismatches after host migrations (AutoSSL writes the challenge to a directory Apache doesn't serve from for that hostname) — before clients see browser warnings.
01
Add cPanel-hosted domains — apex, www.*, app.*, api.* — with DNS TXT verification that catches AutoSSL CAA-block failures, CSF firewall drops of Let's Encrypt validators, and document_root mismatches between AutoSSL metadata and Apache configuration
Verify ownership with a DNS TXT record on the apex domain. All subdomains under that apex — app.* (AutoSSL-managed), api.* (AutoSSL-managed), plus any addon domains or parked domains on the same cPanel account — are added without additional verification. Monitoring every cPanel-hosted subdomain catches the AutoSSL CAA-block failures (the served cert is the old cert approaching expiry while AutoSSL's log records the per-domain skip), the CSF firewall drops (the validator times out and AutoSSL retries every 6 hours with no progress), and the document_root mismatches after migrations (the challenge is written to the wrong directory and validation fails on every retry). Under two minutes per client.
02
CAA record monitoring across cPanel client domains — surfacing the CAA misconfiguration that blocks AutoSSL renewal silently
Three independent DNS resolvers check every CAA record on every monitoring interval. When a client's domain has a CAA record that excludes letsencrypt.org (typical after security hardening that pins to a specific commercial CA), the configuration is surfaced immediately as a renewal-risk alert — well before AutoSSL's next renewal cycle silently skips that domain. The alert specifies which authority is permitted in the CAA record and notes that AutoSSL's default integration uses Let's Encrypt, so the cert won't auto-renew under the current configuration.
03
SSL monitoring 30 days before expiry across every cPanel-attached subdomain — including independent checks per-subdomain so document_root mismatches and CSF firewall drops surface at the served-cert layer, not at the AutoSSL metadata layer
Full SSL chain validation on every cPanel-hosted subdomain — apex, app.*, api.* — across whichever document_root and virtual host configuration Apache (or LiteSpeed) is actually using. Each subdomain gets the same 30-day pre-expiry alert. When AutoSSL is silently failing renewal cycles (CAA-block, CSF-drop, or document_root mismatch), the existing cert continues serving until expiry — Merlonix surfaces the renewal-failure state 30 days before expiry rather than waiting for the expiry event when the customer reports a browser warning.
04
Vendor status for major cPanel hosting providers (HostGator, Bluehost, SiteGround, A2 Hosting), Let's Encrypt, plus DNS providers used at the registrar to distinguish hosting-provider incidents from per-tenant AutoSSL configuration failures
Merlonix monitors major cPanel hosting providers' status pages alongside client SSL and DNS. When a hosting provider's incident affects AutoSSL operation across multiple client tenants simultaneously, you see the vendor event — not a cluster of individual SSL alerts that each require separate investigation to determine whether the root cause is a hosting-provider incident, an AutoSSL CAA-block from a recent security hardening project, a CSF firewall change blocking Let's Encrypt validators, or a document_root mismatch from a recent migration.
What the numbers mean for cPanel agencies
Monitoring built for cPanel agencies where one client portfolio means AutoSSL managing certs across 40+ shared-hosting accounts with addon domains, subdomains, and parked domains each on their own document_root, CSF firewall rules tuned aggressively for security, and CAA records added for compliance — each with independent silent-failure modes.
cPanel agencies managing AutoSSL-driven portfolios across HostGator, Bluehost, SiteGround, A2 Hosting reseller plans, with CSF firewalls hardened for brute-force protection, CAA records pinned to specific CAs for security, and addon domains / parked domains with their own document_root configurations, need monitoring that watches the served cert directly at every cPanel-hosted subdomain — because AutoSSL CAA-block failures are silent (logged to autossl.log but not WHM's main dashboard), CSF firewall drops of Let's Encrypt validators are silent (timeout errors look like every other transient issue), and document_root mismatches after migrations are silent (Apache serves content correctly; AutoSSL writes the challenge to the wrong directory).
< 10 min
Time from DNS change to alert — catches CAA record additions that exclude letsencrypt.org (blocking AutoSSL renewal silently), registrar nameserver changes that strip AutoSSL validation, and addon domain creation with misconfigured document_root paths
30 days
SSL expiry warning lead time — enough time to identify an AutoSSL CAA-block (the CAA record needs letsencrypt.org added or AutoSSL needs to be reconfigured to use the permitted CA), a CSF firewall block of Let's Encrypt validators (csf.allow needs the Let's Encrypt IP ranges whitelisted), or a document_root mismatch (whmapi1 rebuild_apache_conf needs to be run after the migration) — and correct it before clients see browser warnings
11 vendors
Upstream services monitored — major cPanel hosting providers (HostGator, Bluehost, SiteGround, A2 Hosting), Let's Encrypt status, plus DNS providers used at the registrar included to distinguish hosting-provider incidents from per-tenant AutoSSL configuration failures
200 assets
Maximum monitored domains on the Agency plan — covers app.* and api.* across cPanel reseller accounts, addon domains, parked domains, and subdomains, across a full cPanel client portfolio
Pricing
Flat monthly fee. Every cPanel account, every addon domain, every subdomain document_root included.
No per-account charges. No per-domain fees. Pick the tier that fits your cPanel portfolio and per-subdomain check count and monitor every AutoSSL-managed cert without billing surprises.
Starter
For individual cPanel developers managing a small client portfolio on a single shared-hosting reseller account.
$29/ month
- 10 monitored assets
- 1 seat
- 15-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Team
For cPanel agencies managing AutoSSL across multiple reseller accounts with addon domains, subdomains, and CSF firewall hardening where Let's Encrypt validator drops are a real risk.
$79/ month
- 50 monitored assets
- 5 seats
- 10-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Agency
For agencies with a full cPanel client roster including CAA records pinned to specific CAs for compliance, CSF firewall rules tuned per-account, and addon domains across multiple shared-hosting providers (HostGator, Bluehost, SiteGround, A2).
$199/ month
- 200 monitored assets
- 15 seats
- 5-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Know when AutoSSL has been silently skipping renewal for 60 days — before the existing cert expires.
Add your first cPanel client domain in under two minutes. AutoSSL-managed certs across reseller accounts, addon domains, and subdomains are monitored from the same dashboard. 14-day trial, no card required.