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:
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.