Skip to content

Renewal lanes

A renewal profile picks a lane: which authority issues the certificate, and which side — Hub or Scout — drives the exchange. Four distinct lanes exist, all live (the profile editor offers five names — see the note below). What they share: the private key is generated (or reused) on the endpoint, the request leaves as a CSR, and the certificate comes back to be installed and verified. What differs is who talks to the CA and how the domain is proven.

Lane Issuer Domain proof Driven by
Internal CA the Hub's built-in CA none needed — your CA, your rules Hub signs directly
HTTP-01 Let's Encrypt CA fetches a token from port 80 of the endpoint Scout, end to end
DNS-01 — manual any ACME provider you publish a DNS TXT record by hand Hub, with an operator step
DNS-01 — automatic any ACME provider Hub publishes the TXT via your DNS provider's API, waits for it, and removes it afterwards Hub, no operator

delegated is a legacy name for the automatic lane

Profiles saved before this was cleaned up may show DNS-01 (Automatic via API — legacy "delegated"). It is a survivor of the removed Master/Satellite delegation split: there is no delegation service any more, and the verb runs the same code against the same Hub-held DNS provider as the automatic lane. Nothing needs doing — the profile behaves exactly as DNS-01 (Automatic via API), and needs a DNS provider configured the same way. The option is offered only to profiles that already carry it; a new profile cannot choose it.

Which lane for which CA

  • Internal CA — for services that only your own machines trust: internal tools, service-to-service TLS, anything where a public CA buys you nothing. No ACME, no rate limits, no external dependency.
  • HTTP-01 — the zero-DNS-work public lane, and in this phase it is Let's Encrypt only. The Scout runs the whole ACME flow locally, answering the challenge on port 80 itself. Needs port 80 reachable from the internet; cannot issue wildcards.
  • DNS-01 — the lane for every other provider (ZeroSSL, Google Trust Services, SSL.com, DigiCert, any custom RFC 8555 CA) and for every wildcard, on any provider. The Hub drives the order — which is also where provider EAB credentials attach — and the Scout's role is the key, the CSR, and the install. Pick the variant by how the TXT record gets published:
    • manual if you'll paste the record into your DNS console when asked — or if the CA has prevalidated your domains and no record will be needed at all (see below);
    • automatic if the Hub holds API credentials for your DNS provider. Set those up once: AWS Route 53, Cloudflare, or Google Cloud DNS. One entry per zone, as many as you need, and each renewal profile selects the entry that serves its domains.

⚠️ The automatic lane does not degrade to manual. The choice is committed when the renewal is dispatched. If no DNS provider is configured at that moment, the renewal fails — "acme_dns01_direct selected but no DNS provider is configured on this Hub" — rather than quietly asking you for a TXT record, because an operator who chose automation should not have automation silently withdrawn. Pre-flight does warn first, as an Informational manual_dns01 finding, but that finding's wording is written for the manual lane.

The full provider story — built-in providers, EAB credentials, custom provider registration, CAA — is Hub → Certificate providers.

How a manual DNS-01 renewal actually feels

Because it is the one lane with an operator in the loop, it's worth knowing its rhythm:

  1. Renew Now starts the order. The CA answers with the challenge(s).
  2. The renewal parks, and the drawer shows the exact TXT record(s) to publish. You have 5 minutes: a watchdog re-checks every 30 seconds, and if the records aren't verified in time the renewal fails with the order left unfinalized — nothing bought on a paid CA — and you simply renew again when the records are ready.
  3. Records verified → the Hub finalizes, the certificate is delivered, the Scout installs and re-probes.

Prevalidated domains short-circuit this. A CA that already holds valid authorizations for every name (common on paid OV setups) returns an order with nothing to prove. The drawer says no DNS records are required, and the watchdog completes the order automatically within about 30 seconds of the click.

On a per-certificate-billed CA, Renew Now is the paid action

With every domain prevalidated there is no TXT step and no second confirmation between clicking Renew Now and a finalized (billed) certificate. Treat the click as the purchase.

How an automatic DNS-01 renewal actually feels

It doesn't. That is the point: there is no drawer to watch and no record to paste. The Hub publishes, waits, validates, cleans up, and the Scout installs — in seconds. The one proven run, confluence.seecrypt.net against Let's Encrypt production on 2026-08-22, went from dispatch to a closed renewal in 5.3 seconds.

Two properties of the lane are worth knowing anyway, because they bound what can go wrong:

It waits before it lets the CA look, and the budget is 35 seconds. DNS propagation is not instant, and asking the CA to validate a record that is not visible yet burns the order for nothing. The wait is bounded by the Scout's 60-second CSR request/reply window, inside which the whole Hub-side order — submission, validation poll, finalize, download — has to fit. A bigger DNS budget would only trade a DNS timeout for a Scout timeout.

It checks propagation at your zone's own authoritative nameservers, not through a resolver. Challenge records carry a 120-second TTL, so a recursive resolver can keep serving the previous challenge value for longer than any affordable budget — while the CA, resolving from the root, sees the new one immediately. Checking against a cache made the pre-check stricter than the validation it protects and blocked an order that would have passed.

If the wait times out, nothing was submitted to the CA and no order was burned — retrying once the record is visible is free. If the CA does refuse, the Hub reads each authorization's own error and reports the CA's actual complaint rather than the generic orderNotReady that finalizing a dead order produces.

The per-provider setup, and the traps specific to each, are in the how-to guides: Route 53 (the proven one), Cloudflare and Google Cloud DNS (implemented, not yet exercised against a live order).

Verification closes every lane

Whatever the lane, a renewal is not "done" when the certificate is issued or even installed — it closes when a probe observes the endpoint serving the new certificate. Until then it is in flight, and a delivery whose reload didn't take parks as action needed rather than pretending success. Fixing the environment (reload the server, repair the hook) lets the next routine observation close the renewal on its own — no re-issue, no duplicate order.