AutoSSL DNS-01 retry behavior and propagation handling for wildcard certificates
0 reputation · 12 Aug 2020, 09:29 UTC
0 reputation · 12 Aug 2020, 09:29 UTC
cPanel's AutoSSL feature issues wildcard certificates only through the DNS-01 challenge type, which requires the configured DNS provider to expose API hooks for TXT record creation. When the DNS provider module lacks these hooks, or when propagation delays across clustered nameservers cause temporary validation failures, AutoSSL does not automatically retry the validation. Administrators must manually trigger a new check via WHM or the UAPI SSL::start_autossl_check call, or wait for the next scheduled run.
autossl_check scheduler differentiate between retryable DNS propagation errors and non-retryable provider misconfigurations when deciding whether to re-queue a domain?35775 reputation · 12 Aug 2020, 17:44 UTC
uapi --user=username SSL::start_autossl_check to force a new check, or wait for the next scheduled AutoSSL run.What cPanel version is installed? The recommendation differs between pre-v100 and v100+ servers because ACME error categorization changed, affecting whether propagation errors can be distinguished from provider misconfigurations.
whmapi1 autossl_check_logs user=username domain=example.com
Look for DNS-related ACME error codes in the log output. Replace username and example.com with actual values.
Review required: confirm retry behavior on your specific cPanel version before relying on undocumented retry limits.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 12 Aug 2020, 19:56 UTC
AutoSSL issues a single DNS-01 validation request per autossl_check execution—there is no intra-run retry loop for propagation delays. The only built-in wait comes from the DNS provider module itself (e.g., Cpanel::DNS::Cloudflare sleeps 5–30 seconds after TXT record creation), and this value is hard-coded in the Perl module, not configurable via WHM or /var/cpanel/autossl.json. Consequently, a domain that fails due to slow nameserver sync is treated identically to one that fails from missing API hooks or a CAA rejection: it is simply re-queued for the next scheduled run (default 00:00–06:00 local) or a manual UAPI SSL::start_autossl_check call. Administrators needing longer propagation windows must either implement a custom provider wrapper with extended sleep or trigger re-checks externally.