Skip to content

Certificates

DNS-Editor issues certificates via ACME and proves domain ownership using DNS-01: the required validation record is set at the zone’s provider. The advantage over HTTP-01 is that the requesting server does not need to be reachable from the internet — internal services get publicly trusted certificates this way.

  1. An ACME account address at the instance level: DNSE_ACME_EMAIL. Without it, the feature is off.
  2. An ACME account e-mail in the project (Project Settings).
  3. The affected zone must be managed and its account working — the validation record is set through the provider.

Who issues is a project setting: Management → Project Settings → Certificate authority. The choices are:

AuthorityAccount neededValidityNotes
Let’s Encrypt (default)no90 daysACME profiles, requested notAfter, chain choice
ZeroSSLyes, with EABfixed 90 dayswildcards, chain choice; no profiles, no Must-Staple
Let’s Encrypt (test environment)no90 daysfor trying things out — browsers do not trust these certificates
Own ACME directorydepends on the CAdepends on the CAany RFC 8555 CA, e.g. a company CA, Buypass, Google Trust Services

The choice is the default for new certificates; the request dialog can pick a different authority for a single certificate. Options the chosen authority does not support are hidden in the dialog — and the backend rejects them anyway instead of passing them on and letting issuance fail later in the background job.

ZeroSSL requires External Account Binding (EAB): the ACME account is tied to your ZeroSSL account. That needs two values, a key ID (KID) and an HMAC key.

  1. Create a free account at https://app.zerossl.com/signup.
  2. Pick ZeroSSL as the certificate authority in the project settings.
  3. Either enter KID and HMAC key from the ZeroSSL dashboard (Developer section) — or click “Fetch credentials from ZeroSSL”; DNS-Editor then generates them through the ZeroSSL API. With a stored API key they belong to that account, without one the account e-mail above is used.
  4. Save. From now on ZeroSSL issues.

Limits of ZeroSSL that show up in practice:

  • Fixed validity of 90 days. The ACME endpoint is called DV90 for a reason; it does not accept a requested notAfter.
  • No ACME profiles. Profiles are a Let’s Encrypt extension.
  • At most six subdomain labels below the public suffix.
  • No OCSP Must-Staple — at least it is not documented, so we do not offer it there.

For a company CA or another provider: pick Own ACME directory and enter the directory URL (must start with https://). If the CA requires EAB, KID and HMAC key go into the same fields as for ZeroSSL. We guess nothing about capabilities here — every option stays available, and an error from the CA is passed through verbatim.

Project → Certificates → Request. You specify the names the certificate should cover (SAN scope) and, optionally, an authority other than the project’s default. The rest runs automatically: set the validation record, wait for approval, fetch the certificate, remove the validation record.

In split-DNS environments, the pre-check of the authoritative nameservers sometimes fails. In that case a fixed wait time instead of the check helps:

Terminal window
DNSE_ACME_PROPAGATION=90s

Certificates renew themselves before they expire. If one nevertheless approaches its end, a reminder goes out 14 days beforehand to the tenant’s administrators and to the project’s ACME address — because at that point the renewal is evidently failing repeatedly, and that is exactly what someone needs to know.

Issued certificates can be retrieved as a file. The private key is not kept permanently: storage is short-lived, and whoever needs the material again issues anew. For applications that should obtain certificates automatically, an SDK and a deployment agent are planned but not yet built.

With DNSE_DEMO=on, self-signed certificates are generated. This lets you walk through the flow without contacting a real ACME directory.