Skip to content

Delegated DNS-01 (dashboard)

For native Agent setup and challenge ownership, see Agent workflow usage.

Let CertIntel answer the ACME dns-01 challenge for a hostname you control, without giving your ACME client write access to your real DNS zone. You create a record, add one CNAME, and point your ACME client's update credential at it - CertIntel's authoritative DNS service answers the challenge from then on.

This page covers creating and managing a delegation record from the dashboard. For using it in a native CertIntel Agent workflow, see Delegated DNS-01 in the Agent. Other ACME clients can use the CertIntel plugins for simple-acme, win-acme, Posh-ACME, Certbot and acme.sh, the native API (PUT /api/v1/dns-delegations/{id}/txt), or the built-in acme-dns-compatible shim; the DNS setup below is the same. The Agent does not expose its provider as a general-purpose validation script hook.

Creating a record

On Delegated DNS-01 → New delegation record, enter the domain name you want validated (e.g. shop.example.com) and pick a child organization (the one selected in the top bar is pre-selected). CertIntel generates a random 32-character subdomain under its own zone and a one-time update secret, then shows you the exact DNS record to add:

_acme-challenge.shop.example.com.  CNAME  <random-subdomain>.dns01.certin.tel.

Copy buttons are provided for both the record name and the value, so you can paste them straight into your DNS provider without retyping. Use the generated label verbatim: CertIntel's DNS answers only for labels of exactly that shape, so a shortened or altered target never resolves.

One record covers both the base domain and its wildcard - shop.example.com and *.shop.example.com both resolve the ACME challenge from the same _acme-challenge.shop.example.com name, so you never need a second CNAME for the wildcard.

Cloudflare users

Set this record to DNS only (grey cloud), not proxied. A proxied (orange cloud) record answers Cloudflare's own IP, not the CNAME target, and the ACME challenge will never resolve.

Pointing your ACME client at it

For simple-acme, win-acme, Posh-ACME, Certbot or acme.sh, follow the corresponding plugin installation guide. Each plugin uses the delegation UUID, full CNAME target and update secret. The native DLL and Posh-ACME plugins save credentials through the client; Certbot uses a private JSON mapping file; acme.sh saves the CERTINTEL_* settings in its account configuration.

CertIntel speaks the acme-dns update protocol, so most ACME clients with an acme-dns plugin (cert-manager, lego, acme.sh, certbot-dns-acmedns, and others) work directly. Only POST /acme-dns/update is implemented; /acme-dns/register answers 403 on purpose, because registration is what you did on the dashboard when you created the record. Fill the client's acme-dns account from the record's detail page:

Setting Value
server / base URL the DNS update base URL shown on the record (for the hosted service, https://api.certin.tel)
username (X-Api-User) the delegation record's id
password (X-Api-Key) the update secret (shown once at creation)
subdomain the generated subdomain (an update naming a different subdomain is rejected)
fulldomain the full CNAME target shown above

Or use the native API directly:

curl -X PUT https://<update-base>/api/v1/dns-delegations/<id>/txt \
  -H "X-Api-Key: <secret>" \
  -H "Content-Type: application/json" \
  -d '{"values": ["<acme-challenge-value>"]}'

Up to two TXT values are kept live at once on the same name, so an apex + wildcard pair validating in the same run doesn't clobber either value; a request with more than two values is rejected. Updates are accepted only from the update secret; an Agent's own API key does not authenticate them (see Delegated DNS-01 in the Agent).

A tenant administrator can switch TXT updates off for the whole workspace on Settings → Security under What your agents may submit (DNS-01 challenge updates, covering both /acme-dns/update and the native txt route); the records and their CNAMEs stay in place, only updates are refused until it is turned back on.

Managing a record

  • Rotate secret issues a new update secret; the old one stops working immediately. The record's id, subdomain, and CNAME target don't change, so you don't need to touch DNS again.
  • Revoke stops the record answering (and stops accepting new TXT updates) without deleting it; Reactivate brings it back.
  • Delete removes the record permanently.

Native Agent workflows store the delegation's scoped update secret in the local protected secret store. Use Edit workflow… → DNS delegations (Windows) or the terminal interface's Settings screen (Linux) to test or replace it after a dashboard rotation.

Rotating or revoking the update secret never affects the CNAME your DNS zone already publishes - only the credential used to update the TXT value changes.