ACME Renewal Incident Runbook for Agencies Managing Client Websites

An ACME renewal incident runbook helps agencies move from symptom to evidence: current certificate, expiry window, challenge method, ACME client or hosting automation, DNS/HTTP validation path, CAA authorization, and next escalation. The goal is not to retry randomly. The goal is to identify the failure path and the responsible owner before a client-visible certificate outage occurs.

Use 47-Day Pre-Flight to review public ACME, CAA, DNS, and renewal-readiness signals before renewal day. Use the free 10-domain agency audit for broader SSL, DNS, and domain-expiry review. Use the CertPilot methodology when documenting that public checks do not replace hosting logs, ACME client logs, DNS-provider access, or CA dashboards.

Quick answer: ACME renewal incident runbook

The runbook is:

1. Confirm the affected hostname.
2. Check the current certificate and expiry.
3. Identify the ACME challenge method.
4. Review HTTP-01 conditions if the renewal uses web validation.
5. Review DNS-01 conditions if the renewal uses DNS validation.
6. Review CAA authorization.
7. Check hosting automation and ACME client logs where available.
8. Document owner and next action.
9. Communicate risk without panic.

This turns a vague "SSL renewal failed" ticket into an operational workflow.

Step 1: confirm the affected hostname

Start with the exact hostname:

• example.com
• www.example.com
• app.example.com
• *.example.com
• a staging or preview hostname

Do not assume root and www behave the same. They can point to different platforms, use different certificates, or have different DNS ownership.

Step 2: check the current certificate and expiry

Confirm:

• Is the certificate currently valid?
• How many days remain?
• Which issuer is visible?
• Does the certificate cover the hostname?
• Is this a renewal warning or a live browser error?

The track SSL expiry guide explains why agencies need this data across many client websites.

Step 3: identify the ACME challenge method

The challenge method determines the troubleshooting path.

| Runbook step | Evidence to collect | Common finding | Next action | |---|---|---|---| | Hostname confirmation | Exact affected name | Root and www differ | Test each hostname separately | | Certificate state | Expiry, issuer, SANs | Cert is valid but close to expiry | Prioritize renewal owner follow-up | | Challenge method | HTTP-01 or DNS-01 | Team does not know method | Check host or ACME config | | HTTP-01 review | Port 80 and challenge path | Redirect or WAF blocks path | Route to host/platform owner | | DNS-01 review | _acme-challenge TXT | Record missing or stale | Route to DNS owner | | CAA review | issue, issuewild, validation methods | CA not authorized | Update DNS only with approval | | Logs review | ACME or host error | Private failure details found | Escalate with exact error |

If the certificate is wildcard, HTTP-01 is not the right validation method. Wildcards require DNS-01.

Step 4: review HTTP-01 conditions

HTTP-01 validates by placing a challenge file under:

/.well-known/acme-challenge/

Check:

• Does the hostname resolve to the expected platform?
• Is port 80 reachable?
• Does HTTP redirect behavior preserve challenge access?
• Does the CDN or WAF block /.well-known/acme-challenge/?
• Can the hosting platform write the challenge token?
• Is the requested hostname served by the same origin the ACME client controls?

Use the port 80 ACME renewal guide when HTTP validation is suspected.

Step 5: review DNS-01 conditions

DNS-01 validates with TXT records under _acme-challenge. It can support wildcard certificates, but it depends on DNS ownership and automation.

Check:

• Which DNS provider is authoritative?
• Is the TXT record visible publicly?
• Is the ACME client writing to the correct DNS zone?
• Are API credentials valid?
• Did nameservers recently change?
• Is the record cached or propagation delayed?
• Is the client required to approve DNS changes manually?

The DNS propagation false positives guide is useful when public lookups disagree.

Step 6: review CAA authorization

CAA can allow or block certificate authorities. For ACME incidents, check:

• Does the domain publish CAA records?
• Does issue authorize the current CA?
• Does issuewild affect wildcard requests?
• Does validationmethods restrict the ACME method?
• Is parent-domain CAA policy relevant?

If Let's Encrypt is the intended CA, letsencrypt.org must not be excluded by restrictive CAA. The Let's Encrypt CAA troubleshooting guide focuses on this workflow.

Step 7: check hosting automation and ACME client logs

Public checks can show certificate, DNS, and CAA signals. They cannot show private ACME logs unless the agency has access to the host or ACME client.

Collect:

• Exact error message.
• Timestamp.
• Hostname.
• Validation method.
• ACME account or managed SSL status.
• Whether automatic renewal is enabled.
• Whether there were recent DNS or platform changes.

Avoid summarizing the issue as "ACME failed" when the actual error is specific.

Step 8: document owner and next action

Every incident needs an owner:

• Agency controls hosting.
• Client controls DNS.
• Host controls managed SSL.
• Registrar controls nameserver change.
• Developer controls ACME client.
• MSP controls mail/DNS stack.

Document:

• Current status.
• Next owner.
• Required access.
• Client approval needed.
• Next update time.

Step 9: communicate risk without panic

Say what is true:

• "The certificate is valid for 8 more days."
• "Renewal has not completed yet."
• "We are checking DNS/CAA and hosting validation."
• "Users are not currently seeing an SSL warning."
• "The next update will be at 15:00."

Do not promise prevention forever. Do not blame a provider until logs prove it. The SSL renewal failure client communication template provides copy-pasteable wording.

How to prevent repeat incidents

After resolution, document:

• Renewal owner.
• Challenge method.
• DNS owner.
• CAA policy.
• Host support path.
• Renewal reminder window.
• Fallback path if managed SSL fails.

The SSL certificate authority fallback plan helps agencies turn one incident into a better operating process.

ACME renewal incident checklist

• [ ] Exact affected hostname confirmed.
• [ ] Current certificate and expiry checked.
• [ ] Issuer and hostname coverage checked.
• [ ] Challenge method identified.
• [ ] HTTP-01 path checked where relevant.
• [ ] DNS-01 TXT and authoritative DNS checked where relevant.
• [ ] CAA records reviewed.
• [ ] Host or ACME logs collected where available.
• [ ] Owner and next action documented.
• [ ] Client update sent with clear impact and timeline.
• [ ] Prevention notes added after resolution.

How Pre-Flight, Watchtower, and Audit fit

Pre-Flight helps check public renewal-readiness signals: CAA, DNS, port 80, HTTPS behavior, and certificate runway. Watchtower helps track SSL expiry, issuer, Certificate Transparency, and calendar workflow. Audit gives a broader multi-domain view across SSL, DNS, domain expiry, and other public signals.

None of these tools guarantees ACME readiness or renewal success. They help agencies find visible risks and create proof/report workflows.

Related Resources

• ACME readiness check for agencies
• HTTP-01 vs DNS-01 for client websites
• Why ACME renewal fails on client sites
• CAA record client SSL renewals
• SSL certificate authority fallback plan

Frequently Asked Questions

What is an ACME renewal incident runbook?

An ACME renewal incident runbook is a step-by-step process for investigating failed automated certificate renewal. It tells the agency what evidence to collect: hostname, certificate state, challenge method, DNS, CAA, host automation, private logs where available, owner, and client update path.

Can Pre-Flight guarantee ACME readiness?

No. Pre-Flight can review public ACME, CAA, DNS, and renewal-readiness signals, but it cannot guarantee renewal success. It cannot see every private host setting, ACME account state, API credential, or platform log. Treat it as a risk-review tool, not a renewal guarantee.

What is the difference between HTTP-01 and DNS-01?

HTTP-01 validates domain control through a challenge file under /.well-known/acme-challenge/ over HTTP. DNS-01 validates through TXT records under _acme-challenge. DNS-01 can support wildcard certificates. HTTP-01 cannot be used for wildcard certificates. Each method has different failure points and owners.

Can CertPilot read private ACME logs?

No. CertPilot checks public certificate and DNS signals. It does not read private ACME client logs, hosting-panel logs, or CA account dashboards. Agencies need hosting access, ACME client access, or provider support to inspect private renewal errors.

What should I tell a client during an ACME renewal incident?

Tell the client the current visible impact, expiry window, what is being checked, who owns the next action, and when the next update will arrive. Avoid blame without evidence. If users are not currently affected, say that clearly. If users are affected, state the impact plainly and give the active mitigation path.

How do agencies reduce repeat ACME renewal incidents?

Document the renewal path after every incident. Record the host, ACME method, DNS owner, CAA policy, renewal owner, support path, and fallback option. Then add earlier expiry monitoring and a pre-renewal readiness check to the client care-plan workflow.