How to Test if a Host Is Truly ACME-Ready

Jordan’s inherited-domain list has a dangerous kind of green status. The sites load over HTTPS today, the client says the host “auto-renews,” and nobody has touched the certificate setup in months. That sounds fine until the renewal window gets shorter and the first certificate fails because validation depends on a blocked path, stale DNS access, or a CAA rule nobody remembered.

An ACME readiness check helps teams review whether a hostname is likely to renew cleanly when automated certificate renewal is expected. It is not a promise that renewal will succeed. It is a practical review of public signals and ownership assumptions that often decide whether renewal fails at the worst time.

For agencies, MSPs, and lean IT teams, the question is not only “does this site have SSL today?” The better question is: “will this site keep renewing when certificates need to rotate more often, and who owns the action if they do not?”

CertPilot’s 47-Day Renewal Pre-Flight is a free tool for checking practical readiness signals: live SSL expiry, DNS basics, CAA records, port 80 reachability, and HTTP-to-HTTPS behavior.

Tool CTA: Preparing client sites for shorter SSL lifetimes? Run a free 47-Day Renewal Pre-Flight check. Need the broader SSL, DNS, and domain-expiry view? Audit 10 domains.

ACME readiness check: what you are testing

An ACME readiness check is not a guarantee that renewal will succeed. It is a practical review of the public signals that commonly affect automated certificate renewal.

For agency websites, the core signals are:

Use this structured view:

• Signal: Live SSL expiry; Why it matters: Shows how much runway remains.
• Signal: A or AAAA records; Why it matters: Confirms the domain resolves to a web destination.
• Signal: NS records; Why it matters: Confirms DNS authority exists.
• Signal: CAA records; Why it matters: Can restrict which certificate authorities may issue.
• Signal: Port 80 reachability; Why it matters: Required by many HTTP-01 renewal flows.
• Signal: HTTP-to-HTTPS redirect; Why it matters: Indicates public HTTP behavior.

The check is especially useful for inherited client websites where the agency did not set up the original certificate automation.

Why ACME readiness matters before 47-day certificates

Shorter certificate lifetimes increase the frequency of renewal events. More renewal events mean more chances for a broken validation path to cause a visible failure.

Under the CA/Browser Forum timeline, certificate lifetimes move from 398 days to 200 days, then 100, then 47. See the 200-day SSL certificate timeline for the phase schedule.

At 398 days, a broken renewal path may stay hidden for months. At 47 days, that same broken path becomes urgent much more often. Agencies need to find weak renewal assumptions before the final phase.

HTTP-01 validation

HTTP-01 validation proves domain control by placing a token at a public HTTP URL under the domain. The certificate authority checks that URL over port 80.

For this flow to work:

• The domain must resolve publicly.
• Port 80 must be reachable.
• The validation path must not be blocked.
• Redirect behavior must not break the challenge.
• The host or ACME client must be able to place the token.

Port 80 being closed does not always mean the site is broken. Some platforms use DNS-01 or platform-managed validation instead. But if the renewal path depends on HTTP-01, blocked port 80 can become a renewal problem.

DNS-01 validation

DNS-01 validation proves domain control by publishing a DNS TXT record. This can be more resilient for some agency workflows because it does not depend on the web server being reachable.

For DNS-01 to work:

• The DNS provider must be accessible.
• API credentials or delegated access must be valid.
• The domain's nameservers must be correct.
• TXT records must propagate, and migration-window differences should be checked against DNS propagation false positives before they become noisy escalations.
• CAA records must allow the chosen certificate authority.

DNS-01 is powerful, but it creates a different ownership question: who controls DNS? If the client controls DNS and the agency controls hosting, renewal responsibility can become unclear.

For DNS operations, read how to monitor DNS changes across client websites.

CAA records and ACME readiness

CAA records tell certificate authorities which CAs are allowed to issue certificates for a domain. A missing CAA record is not automatically a problem. A restrictive CAA record can be a problem if it excludes the CA used by the host or ACME client.

Example:

Use this structured view:

• CAA state: No CAA record; Readiness interpretation: Usually acceptable, but less explicit.
• CAA state: CAA allows current issuer; Readiness interpretation: Good signal.
• CAA state: CAA allows a different issuer only; Readiness interpretation: Review before renewal.
• CAA state: CAA changed recently; Readiness interpretation: Confirm during migration.

For a deeper agency explanation, see the CAA record gotcha that can break client SSL renewals.

Pre-Flight checklist for agencies

Before relying on automated renewal, run this checklist:

Use this structured view:

• Check: SSL expiry; Pass condition: More than 30 days remaining; Action if not passing: Confirm renewal path.
• Check: DNS address records; Pass condition: A or AAAA exists; Action if not passing: Review DNS setup.
• Check: Nameservers; Pass condition: NS records exist; Action if not passing: Confirm DNS authority.
• Check: CAA; Pass condition: Allows intended issuer or intentionally absent; Action if not passing: Review CA policy.
• Check: Port 80; Pass condition: Reachable if HTTP-01 is used; Action if not passing: Confirm validation method.
• Check: HTTPS redirect; Pass condition: HTTP redirects cleanly to HTTPS; Action if not passing: Fix redirect if needed.
• Check: Ownership; Pass condition: Renewal owner is known; Action if not passing: Document client, host, or agency owner.

The most important part is ownership. A domain can pass technical checks and still fail operationally if nobody knows who is responsible for renewal.

Decision framework: ready, review, action needed

Use a simple status model:

Use this structured view:

• Status: Ready; Meaning: Core signals look clean; Example: SSL healthy, DNS present, CAA acceptable.
• Status: Review; Meaning: Not broken, but should be checked; Example: No CAA, port 80 uncertain, SSL inside 30 days.
• Status: Action needed; Meaning: Likely needs fixing; Example: No A/AAAA, SSL near expiry, HTTP does not redirect.
• Status: Limited data; Meaning: Public checks incomplete; Example: Network timeout or blocked public check.

Avoid treating every unknown as critical. Some hosts intentionally block certain checks or use validation methods you cannot infer from public data. The right response is to review, not overstate.

Hosting platforms and automation risk

Managed hosts often renew certificates automatically. That is helpful, but it can hide the renewal mechanism. The agency may not know whether renewal depends on HTTP-01, DNS-01, a CDN integration, or a proprietary platform process.

When onboarding a client, ask:

• Which platform manages SSL?
• Does the client or agency control the hosting account?
• Does renewal depend on DNS provider access?
• Is the domain behind a CDN?
• Does the host require port 80?
• Are CAA records configured?

These questions become more important as renewal frequency increases.

What to document after the check

An ACME readiness check is most valuable when the result becomes part of the client record. Do not leave the findings in a browser tab.

For each client domain, document:

• Renewal method if known.
• Hosting or CDN platform.
• DNS provider.
• Whether CAA is configured.
• Whether port 80 is expected to be reachable.
• Who can approve DNS changes.
• Who should be contacted if renewal fails.

This documentation helps the next person who receives an expiry warning. It also reduces repeated investigation during future renewals.

Why manual renewals become painful

Manual certificate renewal can work for one or two domains. It does not scale across an agency portfolio.

Consider:

Use this structured view:

• Domains: 25; Approx renewals at 398 days: 25 per year; Approx renewals at 47 days: 200 per year.
• Domains: 50; Approx renewals at 398 days: 50 per year; Approx renewals at 47 days: 400 per year.
• Domains: 100; Approx renewals at 398 days: 100 per year; Approx renewals at 47 days: 800 per year.
• Domains: 250; Approx renewals at 398 days: 250 per year; Approx renewals at 47 days: 2,000 per year.

Manual renewals create recurring coordination risk: validation, approval, deployment, client contact, and documentation. Automation is necessary, but monitoring is still the safety net.

What Pre-Flight does and does not do

The 47-Day Renewal Pre-Flight tool checks public signals that influence renewal readiness. It does not log into hosting providers, inspect private dashboards, modify DNS, or renew certificates.

It also does not replace uptime monitoring, page speed testing, or vulnerability scanning. It is a readiness check for agency domain operations.

Use it when:

• You inherited client sites.
• You are preparing for shorter SSL lifetimes.
• A migration changed DNS or hosting.
• A client moved domains between providers.
• You want a quick portfolio-level readiness review.

Use Watchtower when you need calendar reminders for SSL expiry dates.

How often to run a readiness check

For most agencies, ACME readiness does not need to be checked every day. Run it at operational trigger points: onboarding, before launch, after a migration, after DNS changes, and before certificates enter a short warning window.

If a client site has been stable for months and renewal automation is documented, daily live SSL monitoring is more useful than repeating the full readiness review. Use readiness checks to confirm assumptions, then use monitoring to catch drift and expiry risk.

How to act on results

If Pre-Flight shows "ready," document the renewal owner and keep monitoring.

If it shows "review," assign someone to confirm the validation path. Missing CAA may be acceptable. Uncertain port 80 may be acceptable. The point is to know why.

If it shows "action needed," open a task before the certificate enters a short renewal window.

If it shows "limited data," re-run later and verify manually if the domain is important.

How CertPilot fits

CertPilot helps teams review domain operations evidence. The free Pre-Flight tool helps inspect renewal-readiness signals. The app keeps public-signal checks, domain context, governance notes, SSL readiness notes, and on-demand evidence reporting closer together.

Next step: Run 47-Day Renewal Pre-Flight for up to 25 domains. For a broader SSL, DNS, and domain expiry snapshot, run a free 10-domain agency audit.

Build the ACME readiness evidence packet

A pre-flight check should not end as a screenshot in a chat thread. Turn it into a short evidence packet that can survive handover and renewal cycles.

Capture:

• Hostname: the exact hostname reviewed.
• Current SSL expiry: current certificate deadline and days remaining.
• Issuer: the certificate authority shown publicly.
• Validation method, if known: HTTP-01, DNS-01, platform-managed, manual, or unknown.
• Port 80 expectation: whether HTTP-01 is expected to require it.
• DNS authority: current nameservers and provider owner if known.
• CAA posture: absent, allows current issuer, restrictive, or needs review.
• Renewal owner: agency, MSP, internal IT, host, CDN, client, or unknown.
• Risk level: ready, review, action needed, or limited data.
• Next action: confirm ownership, fix public signal, open vendor ticket, or monitor.

This keeps the review grounded. It also makes future warnings easier to resolve because the team can see what was assumed last time.

Pre-flight is not certificate automation

It is tempting to treat a clean readiness check as proof that the certificate will renew forever. That is wrong. ACME readiness is a review of signals and assumptions. The actual renewal path may depend on private provider settings, valid account access, API tokens, DNS permissions, CDN behavior, and platform-specific automation.

Client-safe language is:

• “Public readiness signals look clean, and the renewal owner is documented.”
• “CAA should be reviewed because it may restrict the issuer used by the host.”
• “Port 80 is blocked; confirm whether this domain uses HTTP-01 or another validation method.”
• “The validation method is unknown. Assign an owner before the certificate enters a short warning window.”

Do not say “ACME is guaranteed,” “renewal is automated,” or “the certificate will not expire” unless the responsible provider and configuration have been verified outside the public check.

ACME readiness after migrations

Run a readiness check after any change that touches the renewal path:

• Moving DNS providers.
• Changing nameservers.
• Moving hosting.
• Adding or removing a CDN.
• Changing CAA records.
• Moving from one certificate issuer to another.
• Changing validation from HTTP-01 to DNS-01 or the reverse.
• Taking over a client from another agency or administrator.

Those changes can leave the current certificate healthy while breaking the next renewal. The readiness check catches assumptions before the renewal date becomes an emergency. Pair it with DNS change evidence so nameserver, TXT, and CAA changes have a before/after record instead of living in a launch checklist.

Prioritize readiness findings

Not every warning deserves the same reaction. Missing CAA may be acceptable. Closed port 80 may be acceptable if the domain uses DNS-01 or platform-managed validation. A nearly expired certificate with unknown renewal ownership is different.

A practical triage model:

• Ready: public signals are clean and owner is known.
• Review: one signal needs confirmation, but there is no immediate expiry risk.
• Action needed: the certificate is near expiry, the host cannot validate, or CAA appears to block the expected issuer.
• Limited data: the public check cannot infer enough; manual provider review is required.

This avoids both panic and complacency.

How CertPilot helps

CertPilot’s Pre-Flight tool checks public renewal-readiness signals. The broader app can help teams keep SSL, DNS, domain-expiry, governance, and review notes close to the same monitored domain record.

CertPilot does not issue certificates, renew certificates, configure ACME clients, manage DNS credentials, log into hosting providers, or guarantee successful renewal. It helps operators see public evidence, record ownership, and escalate review before certificates become incidents.

For calendar visibility, use Watchtower. For workload planning, use the SSL renewal workload calculator. For management reporting, use Domain Health evidence and evidence reports.

Related resources

• 47-day SSL readiness hub — see how ACME readiness fits into the wider preparation cluster.
• 47-Day Renewal Pre-Flight
• CAA record check for client SSL renewals
• SSL certificate renewal workload calculator
• How CertPilot checks domains

Frequently Asked Questions

What is an ACME readiness check?

An ACME readiness check reviews public signals that can affect automated SSL renewal. It looks at practical items such as live SSL expiry, DNS records, CAA records, port 80 reachability, and HTTP redirect behavior.

For agencies, the goal is to identify renewal blockers before shorter SSL lifetimes turn them into urgent client issues.

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

HTTP-01 validation proves control by placing a token on the public website over HTTP. It depends on the domain resolving correctly, port 80 being reachable, and the web server or host serving the challenge path.

DNS-01 validation proves control through a DNS TXT record. It is often useful during migrations or for wildcard certificates, but it depends on reliable DNS access and clear ownership.

Does Pre-Flight renew certificates automatically?

No. Pre-Flight checks readiness signals only. It does not log into hosting providers, change DNS, access private client websites, or renew certificates.

Use the result to decide whether a client domain is ready, needs review, or needs action before the next SSL renewal window.

How often should agencies run a renewal pre-flight check?

Run it during onboarding, before launch, after hosting or DNS changes, after CDN changes, and before a certificate enters a short warning window.

For stable client domains, daily SSL monitoring and monthly domain health reports are usually more useful than repeating the full readiness check every day.