Domains & DNS validation

Every domain is verified once before it can be attached to a certificate. After that, connecting a DNS provider is optional - it is what unlocks DNS-01 validation, and with it wildcards and hosts that are not publicly reachable.

Verifying a domain

Add the domain under Manage > Domains. aethercert gives you a _aethercert-challenge TXT record to publish at your registrar or DNS host. Once it resolves, press Verify.

This is a one-time step per domain, and it is separate from the ACME challenge that happens at issuance. It proves to aethercert that the domain is yours, so one organization cannot request certificates for another's names.

Verification is a single check with no waiting period beyond normal DNS propagation. If it fails, the record has almost always not propagated yet - see Troubleshooting.

Internal domains

A domain that is not publicly resolvable can be marked internal. That skips TXT verification entirely, because there is no public DNS to publish the record in - and in exchange, an internal domain can only be used with an Internal CA (REST). ACME challenges are not available for names the outside world cannot resolve.

Choosing a validation method

Certificates from a public authority are validated one of three ways. Which one you can use depends on whether a DNS provider is connected and whether the challenge port is reachable from the internet.

Internal REST authorities use none of these. They sign the CSR directly, so no challenge is involved at all.

Creating or editing a certificate with HTTP-01 or TLS-ALPN-01 checks upfront whether the certificate's own hostname is actually reachable on the challenge port from the public internet, and blocks the job with the exact reason if it isn't - instead of letting it fail silently once dispatched to the agent. See Network requirements for the full list of what needs to be reachable, from where, and on which port.

Connecting a DNS provider

Connect a provider on the domain's own page, under Manage > Domains. aethercert supports 217 DNS providers - the full set from the lego ACME library, matched one-for-one by the agent.

The provider list is searchable, and each entry states exactly which credential it needs and where in that provider's console to create it. Credentials are tested against the real API before they are saved, so a token with the wrong scope fails at the point you paste it rather than at 3 a.m. during a renewal.

Providers with a step-by-step guide

Four of the most common have their own walkthrough, including the exact permission scopes:

Everything else

The other 213 follow the same pattern: pick the provider, read its hint, paste the credential, save. A representative selection of what is in the list:

If your provider is not in the list, the last row is the answer: ACME-DNS delegates _acme-challenge to a purpose-built server, the generic webhook posts the record to an endpoint you control, and the custom script runs a script that is already on the agent host. Between them, anything with an API can be automated.

How credentials are handled

Scope the credential to the single zone aethercert needs wherever the provider supports it. An account-wide token is a larger blast radius for no benefit.

Practical notes

• One domain, many certificates. Verify example.com once and every certificate for it and its subdomains can use it. You do not add a domain per hostname.
• Subdomain delegation works. If internal.example.com is delegated to a different DNS zone, add it as its own domain with its own provider credentials.
• Changing DNS provider is a matter of replacing the credentials on the domain. Existing certificates are unaffected; the new credentials are used from the next challenge onwards.
• Removing a provider leaves the domain verified but drops it back to HTTP-01, which will break renewals for any wildcard certificate on it.