1. Register and verify an Auth Site

TrustPlane Control governs which Auth Site may receive signed policy. This chapter creates its site record and proves control of the hostname. It does not install or initialize the Auth adapter.

Previous: What TrustPlane does. Next: Target identity and trust.

Fresh-site prerequisites

You need an authorized organization owner, a workspace and environment, a fleet, a real FQDN under your DNS control, a reconciled subscription/feature grant for new Auth Site bootstrap, and at least one free tenant-wide Auth Site slot. Pending sites may consume allowance. Do not repurpose an existing serving site to make this walkthrough appear to be a first site. Check your live account before creating anything.

Select the scope and check capacity

1. Sign in to Control and select the owner-authorized organization. Record its organization ID. Use Create workspace in the first-run flow if needed, then select the intended environment. Record the workspace/environment readback rather than guessing IDs.
2. Use Create fleet or select the dedicated fleet for that environment. A fleet is a Control grouping; it does not create a Kubernetes cluster or another capacity bucket.
3. Open Billing. Check the account’s new-site eligibility and effective Auth Site allowance. A standard paid account requires an active, provider-reconciled subscription and its feature grant. Existing grandfathered service alone does not establish new-site eligibility; use only a separately authorized grant if Control explicitly reports one.
4. Open Auth Sites → Auth Site capacity. Read the tenant-wide used/maximum, pending-site rule and Sites consuming the allowance. Stop if the panel is unavailable or free capacity is zero. An empty selected fleet can coexist with a full tenant-wide quota.

The first-run UI currently places a subscription step after site creation. This preflight protects your slot before creating a pending site. The Billing reference and Auth Sites reference explain the readbacks.

Create the site and verify DNS

1. In the first-run Create Auth Site step, or New Auth Site on the exact environment and fleet’s Auth Sites screen, enter your real Auth FQDN. Read back the environment, fleet, site and distribution-target IDs. Expect pending verification; this is a Control record, not an Auth process.

2. Control gives an exact DNS TXT challenge name and value. First find which DNS provider is authoritative for the hostname’s zone. A domain registered at Namecheap may delegate a subdomain to a Route 53 hosted zone; in that case, add the TXT record in Route 53, not in the Namecheap DNS editor. For example, if the Auth hostname is under a delegated auth.example.com zone, check its public nameservers:

   dig +short NS auth.example.com

   In that authoritative zone, create the exact TXT name and value shown by Control. Allow the record to propagate, then query public DNS for the exact challenge name:

   dig @1.1.1.1 +short TXT '<EXACT_CHALLENGE_NAME_FROM_CONTROL>'

   Replace the quoted input with Control’s challenge name. Compare the returned TXT value byte-for-byte with Control’s value. If it does not appear, check the zone’s NS delegation, exact record name, and propagation before retrying. Do not change the challenge to make the command appear to pass.

3. Click Verify ownership in Control and require verified for the same site. DNS ownership does not establish TLS, an installed adapter, or a promoted policy.

Open this walkthrough on YouTube

Record only the non-secret IDs, capacity status, DNS answer and verification readback. Keep account sessions, billing details and DNS credentials out of screenshots and recordings. If the subscription, capacity or DNS check fails, stop at that visible state and resolve it through the account owner’s normal flow.

Next: Generate and register the Auth target key, then prepare first-start trust.