Did you know? An automated agent can obtain a valid HTTPS certificate and still leave a website serving an expired one. The certification authority may have verified domain control, signed a new certificate and returned a successful order, while an older certificate remains loaded on one reverse proxy. Safe ACME automation therefore needs two separate proofs: the authority issued the expected certificate and every intended serving endpoint actually presents that certificate with a matching private key, complete chain and correct hostname.
To renew safely, the agent must identify the authorised domain and certificate owner, discover the current certificate and expiry, use the issuing authority’s ACME protocol and recommended renewal information when supported, solve an approved HTTP-01 or DNS-01 challenge, retrieve and validate the certificate, deploy it transactionally across the intended serving fleet, check independent TLS handshakes, and retain a recoverable old configuration. A created order, valid DNS TXT record or successful process exit is not by itself a verified production renewal.
This is a practical guide for today’s AI-assisted operations and ordinary certificate-management automation. Artificial superintelligence remains hypothetical. All operational timings, sample hosts and service metrics below are fictional worked examples, not claimed execution on a real production website. The standards and current provider guidance are linked directly so a reader can distinguish protocol requirements from illustrative engineering decisions.
Contents
- The core model: five different kinds of certificate state
- What a certificate proves—and what it does not
- HTTP-01 and DNS-01 are different authority tests
- Understand order, authorisation and challenge status separately
- ARI is preferable to a hard-coded renewal day
- Worked case: thirty-day lead, three edges and a missing deployment
- Secrets and authority must be scoped narrowly
- A robust rollout needs a separate acceptance gate
- Monitor both remaining lifetime and serving-state mismatch
- Failure diagnosis: where a renewal commonly breaks
- Changed-context exercise: a wildcard certificate and delegated DNS
- Limits, governance and what this guide cannot guarantee
- Frequently asked questions
- Reader pathways and primary technical sources
The core model: five different kinds of certificate state
Imagine a browser reaching a service through a load balancer. The certificate shown to the browser may reside on that edge service rather than in the application container. An ACME client running on a completely different host might have renewed a certificate into a local directory, but the edge service could still be serving bytes loaded before the renewal. The first engineering task is to inventory the actors: certificate authority, ACME account, domain-control verifier, certificate storage, deployment controller and TLS-serving endpoints.
ACME is the Automatic Certificate Management Environment defined by RFC 8555. The protocol gives a client a structured way to ask an authority to validate identifiers and issue certificates. It does not define the complete operational process that makes every web server serve the new certificate. The gap between issuance and deployment is precisely where an overly confident agent can report success while users receive handshake errors.
Five states help keep claims honest. The first is domain control: does the applicant answer the requested validation challenge? The second is authorisation and order: did the authority move the requested order through the relevant status transitions? The third is issued material: does the downloaded certificate cover the intended names, period, issuer chain and key? The fourth is installed material: have configuration, file permissions and service reloads accepted it? The fifth is served material: do independent live TLS handshakes to all intended endpoints present the correct result?
Those states are not synonyms, and they may become temporarily inconsistent. An order can be valid while DNS propagation remains incomplete. A certificate can be issued while its deployment is held for manual review. An endpoint can show the right certificate on one address and the wrong one on another address or network path. A system that compresses these observations into a single green check mark is hard to debug and can conceal an outage.
A clear ownership contract names the domain or namespace being managed, the authorised ACME directory, allowed challenge method, certificate/key location, deployment targets and parties allowed to reload production services. An AI agent that can read a website does not automatically receive authority to change DNS zones, request certificates or restart a reverse proxy. Each side effect needs its own credential and policy boundary.
What a certificate proves—and what it does not
An HTTPS certificate binds an asserted public key to identifiers, normally DNS names, through a signature chain that a relying client evaluates under its trust policy. A valid signature does not prove the website’s content is correct or ethical. The private key must remain controlled by the intended service; otherwise someone with that key could impersonate a server even while the certificate itself appears valid.
Distinguish the ACME account key from the certificate’s private key. The account key authenticates the client to the ACME server for protocol operations. The certificate private key corresponds to the public key in the signed certificate and is used by a server in TLS. Rotating an account credential does not necessarily rotate a deployed server key, and renewing a certificate does not necessarily create a new account. A secure inventory records these relationships explicitly.
Certificates cover names through their subject alternative name extension, not by a vague belief that any subdomain of an organisation is included. A certificate for api.example.test is not automatically valid for billing.example.test. A wildcard such as *.example.test is subject to name-matching rules and does not mean every conceivable nested subdomain is covered. Inventory the actual hostnames and routing configuration before deciding which identifiers to request.
Client trust additionally involves validity time, algorithm acceptance, certificate chain construction and hostname verification. A cert with a future NotBefore time can be issued but not yet suitable for some relying clients. A leaf certificate without the required intermediate chain may work in one environment and fail in another. An agent needs a trustworthy clock for validity checks and should not treat local parser success as proof of public TLS acceptance.
The existing HTTPS trust guide owns the general certificate-chain and hostname-verification problem. This specialist focuses instead on safe automated renewal: request lifecycle, challenge scope, provider timing, installation and independent serving-state checks.
HTTP-01 and DNS-01 are different authority tests
With HTTP-01, the authority asks for a token that the client serves under a specified well-known path for the named host. For Let’s Encrypt, the documented path is http://<domain>/.well-known/acme-challenge/<token>, and validation begins through HTTP on port 80. The token and account-key thumbprint are combined into a key authorisation. A valid response demonstrates control under the issuing authority’s validation rules; it is not a general-purpose proof that every application path works.
With DNS-01, the client places a token-derived TXT value under the _acme-challenge name in DNS, allowing the authority to verify domain control through DNS. This approach supports validation for wildcard identifiers in the issuing authority’s documented offering and can work when the service itself is not reachable from the public internet. Its main operational challenge is that changes must be visible to the authority, not merely to the DNS API that accepted the update.
The Let’s Encrypt challenge-types documentation, last updated 12 February 2026, describes the strengths and limitations of HTTP-01, DNS-01 and TLS-ALPN-01. The provider-specific details matter. For example, Let’s Encrypt describes HTTP-01 as bound to port 80 and not suitable for requesting wildcard certificates. Other authorities may implement different allowed challenge sets or policies, so do not generalise one provider’s choices as every ACME server’s behaviour.
DNS-01 requires carefully scoped write authority. A bot authorised to create a TXT value under _acme-challenge.example.test does not need administrative control over all domain records. Prefer DNS delegation or narrowly scoped API tokens where the provider allows it. A broad DNS credential on a public application host increases the consequences of compromise. Never paste such a token into an issue comment or expose it in an agent’s generated diagnostics.
HTTP-01 needs routing discipline. If some of five edge nodes answer the challenge path and others return an unrelated application page, validation may be intermittent depending on which node the authority reaches. A reverse proxy rewrite or forced redirect can also alter the path. The safe workflow checks exactly where the challenge value can be reached before asking the authority to validate, without inventing success based on a single local request.
Understand order, authorisation and challenge status separately
ACME exposes structured resources such as accounts, orders, authorisations and challenges. An agent should retain the identifiers returned by the issuing service and query the same resource when a response is uncertain. It should not create a fresh order after every timeout without first determining whether the original order was already accepted. The client should follow statuses defined in RFC 8555 rather than invent an ambiguous state like ‘probably done’.
On an illustrative order, the client receives two identifiers to validate: api.example.test and dashboard.example.test. The operator may have a valid authorisation for one name and an unresolved challenge for the other. The certificate cannot be treated as fully approved for both solely because one challenge completed. An engineer should record the per-identifier status, any provider error, and the next safe action instead of reducing a multi-identifier order to a single optimistic yes.
When using the JSON-over-HTTPS interface, client messages must follow the ACME request-signing and nonce conventions described by the protocol. Copying a nonce or JWS body from an old example is not a robust automation pattern. Use a maintained client that handles account keys, protocol errors and retries as documented. A model can help reason about a failure, but should not substitute a guessed HTTP request for a verified library contract.
The order lifecycle also contains steps for certificate signing request construction and order finalisation. Check the CSR’s identifier set and public key before submitting it. If a domain was accidentally omitted, the right repair may be a new authorised order rather than silently altering issued material. Once issued, the downloaded chain should be checked independently against the intended order and the private key held by the deployment owner.
An apparently successful issuance call might finish after the network connection drops. Reconcile against the known order URL and returned certificate resource if available. This is similar to agent idempotency and recovery, but ACME adds dedicated resource states and domain-control checks that must remain part of the decision.
ARI is preferable to a hard-coded renewal day
Certificate lifetimes change over time. An agent hard-coded to attempt renewal every sixty days may be adequate under one issuance policy and dangerously late when default certificates become shorter. The IETF published RFC 9773, ACME Renewal Information (ARI), in June 2025 so issuing servers can suggest when specific certificates should be renewed and clients can coordinate those attempts.
ARI offers renewal information for a particular certificate; it is not an instruction to ignore its expiry or to assume all providers use a uniform schedule. A compliant client needs to interpret the issuer’s supported extension and applicable suggested window, with a fallback appropriate to its certificate’s actual lifetime. Network failures, rate policies and maintenance needs still require independent controls.
Let’s Encrypt’s December 2025 announcement about shorter lifetimes stated that its default classic profile would move to 64-day certificates on 10 February 2027 and to 45-day certificates on 16 February 2028. As of 25 October 2026 those dates were announced future changes, not changes already applied to every default certificate. Its July 2026 upcoming-features page confirms the planned stages and recommends clients capable of responding appropriately.
A generic algorithm should therefore read the actual NotAfter timestamp, consult the configured authority’s supported renewal information, and choose a safe authorised window. Do not use ‘always on day sixty’ as a permanent business rule. Do not assume renewal only happens near expiry, because replacement may also be needed for compromised keys, changed identifiers or incident response.
An AI assistant might notice that the issuer’s suggested window is earlier than last month’s cron expression. It can propose changing the schedule and explain the evidence. But modifying an organisation’s certificate job requires permission, compatibility testing and rollback support. The issuer’s new timing signal is input data for policy, not permission for an unreviewed change to production.
Worked case: thirty-day lead, three edges and a missing deployment
Here is a completely fictional small service. Its current certificate expires at 12:00 UTC on 1 December 2026. At 12:00 UTC on 1 November 2026, thirty complete days remain: 30 × 24 = 720 hours. The organisation’s approved renewal plan aims to obtain the replacement within its appropriate authorised window, leaving room for deployment checks. This particular timing is illustrative; it is not a substitute for ARI recommendations or the actual issuer’s policy.
The ACME client submits an authorised order, proves DNS control and receives a replacement certificate. A fictional DNS change takes twelve minutes to become visible from the verifier’s relevant resolver view and the remaining issuance step takes three minutes. In this example the elapsed time is twelve plus three equals fifteen minutes. That describes one hypothetical success path and does not claim the authority always responds in fifteen minutes.
The operator has three TLS termination nodes: edge A, edge B and edge C. A deployment job reports new files copied to all three, but a handshake check finds that edge C is still presenting the old certificate. The verified deployment count is two out of three, which is 2/3 ≈ 66.67%. A policy requiring all intended endpoints to present the replacement must mark deployment incomplete, even though the certificate was issued successfully.
The repair is not automatically another ACME order. It is to inspect whether edge C loaded the new files, whether the key matches, whether its service reload completed and whether the independent probe is reaching the intended endpoint with the correct SNI hostname. After fixing the local configuration and verifying that all three endpoints serve the expected replacement, the checked fraction is 3/3 = 100%. That is a fleet-specific outcome, not a guarantee of global internet reachability.
Now add a fourth routing path through a disaster-recovery site that the initial inventory omitted. The previous ‘3/3 complete’ statement was true only for the three inventoried nodes. The operational definition of all-serving-endpoints has changed to four nodes. If the disaster-recovery edge is stale, completion is 3/4 = 75% across the newly correct denominator. This is why inventory scope matters as much as arithmetic.
A real report should include certificate fingerprint, observed validity times, hostname, endpoint identity, time of observation, chain status and validation method. Never invent fingerprints or present these example values as if measured on live infrastructure. The agent should say what it actually checked and which paths remain unverified.
Secrets and authority must be scoped narrowly
The ACME account credential and DNS API credentials should be handled as secrets, with access appropriate to their role. A certificate private key has a different protection boundary from the public certificate chain. File permissions, secret distribution and logging must respect this distinction. It is not safe to attach a private key to a public bug report simply because the corresponding certificate is public.
A secure design separates request authority, challenge authority and deployment authority. A validation agent might update only a delegated DNS validation zone, while a deployment controller can install an approved certificate but cannot modify unrelated DNS records. This reduces the risk that a prompt-injected repository note or compromised helper script makes the agent change more infrastructure than the owner intended.
DNS challenges also create cleanup work. If many old TXT values accumulate, responses may become unwieldy or obscure the current challenge. Cleanup should target values the authorised workflow owns rather than indiscriminately delete other TXT records under a shared validation name. Concurrent orders for related identifiers might legitimately coexist; deleting someone else’s value can cause confusing intermittent failures.
Do not allow a model to invent a bypass after a failed challenge. For example, changing nameservers, loosening DNS account permissions or disabling HTTPS validation may have consequences far beyond the renewal job. The correct response is to diagnose the failed proof and ask the responsible owner for any broadened authority before attempting a different challenge method.
Because the user-visible certificate chain contains names and public keys, preserve provenance and audit receipts without exposing secret key material. Keep independent records of who approved the order, what key store owns the private key and which deployment targets received a new certificate. This makes incident recovery possible when an agent’s conversational context is lost.
A robust rollout needs a separate acceptance gate
After obtaining an issued certificate, validate the identifier set, key matching and timing. Then stage it for installation according to the serving platform’s mechanisms. Some services need a reload to pick up changed files. Others use dynamic certificate stores or load certificates during a controlled configuration update. Never assume that replacing a PEM file in a directory changes what a running TLS listener serves.
The safe deployment gate checks both the intended configuration and observed handshakes. A local command can report that it restarted a service, but the endpoint might not be listening, may serve another virtual host, or could be reached through a still-stale upstream cache or load balancer. Independent probes should use the intended hostname, address family and network paths appropriate to the service.
For multi-tenant reverse proxies, check SNI selection. A handshake without a hostname may return a default certificate that differs from the configured virtual host; a probe to only one path can also miss mismatched nodes. Capture which identifier and endpoint each probe tested. Use trusted network and TLS tools; a model should not fabricate the handshake results it expects to see.
Rollouts should preserve a recoverable configuration, not blindly overwrite the only valid credential. But rollback must be time-aware. If the old certificate is about to expire or its private key is compromised, restoring it may not be a safe recovery. The fallback can be a previously validated configuration with different certificate material, temporary traffic isolation or escalation to a responsible operator.
Distinguish successful server rollout from browser compatibility. A few probes can establish useful technical evidence but may not exercise every client trust store, cipher policy or geographic route. Report the coverage of the verification. Under high-risk operational requirements, continue with canary traffic, health monitoring and explicit rollback criteria rather than treating one tool’s exit code as complete assurance.
Monitor both remaining lifetime and serving-state mismatch
The most actionable signal is not only ‘certificate file exists’ but whether the certificate currently served by the intended endpoint is valid for the hostname and has sufficient remaining lifetime. Monitor the actual served NotAfter across critical routes and compare it with the inventory’s intended certificate identity. An issuance success alert with an old served certificate should trigger deployment diagnosis, not celebration.
An expiry monitor needs a correct clock. For an endpoint serving a certificate that expires in seventy-two hours, an ordinary daily check may provide some margin, but operational schedules should account for maintenance windows, staffing and provider availability. If an alert fires after the service has already been unreachable for half a day, the warning threshold was not designed around the real response process.
Track failures by stage: challenge proof, ACME order, certificate download, key material validation, rollout, reload, independent TLS probe and external functional check. A single ‘renewal failed’ log line hides the reason. A structured event history lets an engineer identify whether a change to the provider, DNS, storage permissions or service configuration caused the failure.
Use rate limits as an engineering constraint rather than a reason to avoid reporting uncertainty. The February 2026 provider discussion of shorter lifetimes and rate limits explains important treatment of qualifying renewals and new-domain issuance. Its provider-specific statements should be checked at execution time; do not copy a numeric request quota into a permanent universal retry policy.
A well-built agent also observes false positives. Suppose a monitoring service accidentally probes the wrong hostname and reports a default certificate. Before issuing a new cert, verify that the alert’s SNI, DNS target and route match the intended service. Verification should narrow uncertainty; it should not trigger more infrastructure mutation merely because a status turned red.
Failure diagnosis: where a renewal commonly breaks
A challenge failure often indicates that the validating party could not observe the correct proof at the right name, path or time. For HTTP-01, check port routing, reverse-proxy rewrites, multiple serving nodes, redirects and actual external reachability. For DNS-01, check the authoritative zone, record name, token-derived value, delegation and DNS propagation visible to the relevant authority.
An issuance failure after challenge completion may concern the order’s other identifiers, CSR contents, account permissions or provider policies. Read the ACME error object and status carefully. Do not conclude that passing one challenge guarantees issuance. When a service times out, reconcile the existing order rather than submit an unbounded series of new orders.
An installation failure may involve mismatched certificate/key pairs, unexpected file paths, access permissions, malformed concatenation of certificate chains or a failed service reload. Inspect the intended deployment target and test it without exposing key bytes. The independent handshake is the decisive read of currently served TLS identity, not the fact that a file copy command returned zero.
A partial rollout might be caused by missing nodes, asynchronous configuration propagation or different traffic routes. Inventory reconciliation is the correct first repair. Another recurring failure is an automation runner that renews certificates successfully but has no permission to restart the listener, leaving the deployment stage permanently incomplete.
Finally, a ‘works in my browser’ observation may hide expired paths seen only by some clients. Browsers cache network connections, DNS can route clients differently and multiple virtual hosts can share addresses. Use deliberate independent tests that specify the hostname and target path. Report the limitations of each probe instead of claiming a global guarantee.
Changed-context exercise: a wildcard certificate and delegated DNS
Move from a single-host certificate to a wildcard identifier for *.example.test. The engineer previously used HTTP-01 for api.example.test. Can the same challenge prove a wildcard request to Let’s Encrypt? Under the provider’s published guidance, no. DNS-01 is the documented route for wildcard issuance in that service. A safe automation should identify the different requirement before requesting the order, not repeatedly retry a challenge type that cannot accomplish the specified job.
Assume the organisation delegates _acme-challenge.example.test to a validation zone managed by a separate service. The agent can edit records only in that zone and may not change the apex DNS A, MX or NS records. This is a narrower and safer authority boundary. But the delegated zone must actually be configured and discoverable; simply writing to a similarly named zone does not prove the authority’s resolvers will find the value.
Here is a fictional verification example. A validation controller checks four resolver views after a TXT update and observes the required value in three views. The count is 3/4 = 75%. Whether that is sufficient to trigger the authority’s challenge depends on the actual issuer’s method and the chosen preflight policy; a local sampling rule is not an RFC guarantee. The safe engineering decision is to wait for convincing proof under the authorised method and inspect the authority’s actual reported result.
The certificate then passes issuance, but the application has a separate exact-name service that needs its own hostname coverage. A wildcard does not erase the need to check the complete set of certificate identifiers and host-matching rules for each intended TLS listener. A successful certificate order for one wildcard identifier is not automatic approval for a different domain.
The transfer answer is that the five-state model stays the same—control, order, issued material, installed material and served material—but the proof mechanism and authorised DNS boundary change. Reusing a memorised sequence of commands without checking the new assumptions is exactly the sort of operational shortcut an agent should resist.
Limits, governance and what this guide cannot guarantee
ACME is an issuance and management protocol, not a substitute for an organisation’s infrastructure ownership, change policy or security incident handling. The ability to answer a domain-control challenge does not settle the legitimacy of every possible requested change. A responsible system should restrict certificate orders to authorised identifiers and maintain records that humans can inspect.
Certificate revocation, compromised keys and emergency replacement may demand a different process from ordinary scheduled renewal. Rolling back to a compromised private key is not a safe recovery step. Likewise, expiry timing should not be estimated from an arbitrary general rule when the actual certificate and issuing authority provide more precise information.
Provider guidance can change. As of 25 October 2026, Let’s Encrypt had announced further shortening of default certificate lifetimes during 2027–2028. This guide dates those announcements and directs readers to official current sources; it does not claim those future stages have already happened. An agent must recheck the provider when performing an actual renewal.
Not all applications terminate TLS in the same place. A cloud edge, managed ingress, service mesh or application process can own the certificate. The exact deployment and probe mechanisms must be derived from the supported platform, not invented from a generic example. No live system was tested in this article.
Finally, today’s AI agent does not become autonomous policy authority because it can parse an RFC. It can assist with inventory, explanation, bounded checks and status reporting. Production certificate issuance, DNS mutation and service rollout remain governed by real credentials, safe execution tools, human ownership and independent evidence.
Frequently asked questions
What is ACME certificate renewal? It is a protocol-backed process where an authorised client works with a certification authority to obtain replacement certificate material, often after proving control of the relevant domain names. Safe production renewal includes deployment and verification beyond issuance.
Does a valid ACME order mean the website is safe? No. The order can be complete while the server still presents an old or incorrectly deployed certificate. Check the live TLS endpoint for the intended hostname and its certificate chain.
What is the difference between HTTP-01 and DNS-01? HTTP-01 proves control by serving a challenge value over an approved HTTP path. DNS-01 proves control through a TXT record at a specified DNS name. Provider policy determines which identifiers and challenges are supported.
Why do renewal schedules need updating? Certificate lifetimes and issuing-authority recommendations can change. RFC 9773 describes ACME Renewal Information, which enables authorities to suggest renewal windows instead of relying solely on hard-coded day counts.
Can one DNS-01 TXT value renew every future certificate? Standard DNS-01 uses challenge values associated with particular authorisations. Newer mechanisms or proposals may have different properties; do not assume ordinary DNS-01 is permanently reusable.
Should an AI agent hold broad DNS credentials? Prefer narrowly scoped access or delegated validation zones when supported. The agent should not need authority over unrelated DNS records merely to renew a certificate.
Can I trust a zero exit code from a reload command? It is evidence about that command, not proof every intended endpoint serves the new certificate. Validate independent TLS handshakes across the relevant fleet and routing paths.
What happens if the first renewal request times out? Query the existing ACME order by its recorded identifier before creating anything new. The authority may already have accepted the request.
Is a renewed certificate proof a service was deployed? No. The issued certificate and a production deployment are separate states. Report the verified deployment result and any remaining endpoints explicitly.
Reader pathways and primary technical sources
If you are building an agent, begin with exact allowed identifiers, ACME directory identity, challenge permissions and secret boundaries. Then implement status-aware issuance, safe staging and a separate live-serving verification gate. If a stage is uncertain, describe it as uncertain and reconcile against the owning system.
If you are operating a service, verify both the intended certificate store and the actual TLS endpoints. Keep old service configuration recoverable where safe, monitor served expiry and track every node. The HTTPS trust specialist covers the certificate-chain verification your rollout checks should perform.
If you teach computing, ask students to differentiate issuance from installation through the three-edge worked example. Have them recompute the 2/3, 3/3 and 3/4 coverage results and explain why the denominator changes when a disaster-recovery edge enters the inventory. This is a practical lesson in both technical state and honest measurement.
Primary sources: IETF RFC 8555, ACME; IETF RFC 9773, ACME Renewal Information; Let’s Encrypt challenge types, updated February 2026; Let’s Encrypt’s announced shorter certificate lifetimes; upcoming features, July 2026; and Certbot’s official reference for a widely used client. Verify implementation-specific commands against the installed client release.
For related agent engineering, consult How Super Intelligence Works, the protected agent change-control guide and learning that transfers into life. No private key, live certificate, DNS record or production service was touched to prepare these explanations.