TLS certs

dnswiz can issue Let’s Encrypt certificates for any name in your zones. The DNS-01 challenge solves itself, dnswiz writes the _acme-challenge TXT, waits for propagation, then strips it. You get a cert without ever touching your registrar or running certbot.

From the console (recommended)

1. Open the zone, pick a record (any A/AAAA/CNAME/ANAME).
2. Click Get TLS cert.
3. The drawer generates a private key in your browser (it never leaves your device) and submits the CSR.
4. ~30 seconds later: cert + chain + key download as a .zip.

The private key is never stored server-side. dnswiz keeps a record of the issuance (name, expiry, fingerprint) for renewal tracking but doesn’t see the key.

CAA pre-flight

Before issuance, dnswiz checks the zone’s CAA records to see if Let’s Encrypt is allowed to issue for the name. If CAA exists but omits letsencrypt.org, the drawer prompts you to add it with one click before continuing, most “issuance failed” surprises come from inherited CAA from a parent zone you forgot about.

From the CLI

# Mint an API key in Settings → API keys, then:
export DNSWIZ_API_KEY=dnswiz_xxxx

# One-shot: issue + write cert.pem / chain.pem / key.pem
dnswiz cert issue --name www.example.com --out ./certs/

# Renew everything within 30 days of expiry. Idempotent.
dnswiz cert renew --all --out ./certs/

Get the dnswiz CLI from the downloads page.

Auto-renewal

dnswiz watches every issued cert and fires notifications at 30 days, 14 days, 7 days, and on expiry through any notification channel configured in Settings. Each threshold fires at most once per cert, so you get a heads-up, not a flood.

Re-running dnswiz cert renew --all from cron is the standard auto-renew loop. The renewal threshold is 30 days by default (configurable in admin settings).

Coverage gap detector

The dashboard’s Names without certs tile lists every A/AAAA/CNAME/ ANAME in your workspace that resolves to a public IP but has no covering TLS cert. Click one to open the issue drawer pre-filled.

It works because dnswiz knows both what your DNS points at and which names already have a cert, so it can tell you exactly what’s exposed without one.

Rate limits

Let’s Encrypt’s account-wide rate limits apply, most notably 50 certs per registered domain per week and 5 duplicate certs per week. The console + CLI surface LE’s response verbatim when limits hit; the dashboard cert tile shows a count of issuances this week so you can pace yourself.

Operator can tighten LE limits further in Admin Settings → Cert issuance (e.g., cap to 10 issuances/day across the tenant) to prevent runaway loops.

Choosing a CA

dnswiz speaks plain RFC 8555 ACME, so any compliant CA works. The admin Settings page ships these presets:

“Custom…” lets the operator paste any other ACME directory URL.

Why switch CAs? The single best reason is a fallback for LE’s weekly per-domain cap during an incident. If your main customer domain hits the 50/week limit at 3 a.m. and a renewal is failing, flipping to ZeroSSL or Google Trust Services lets the next issuance go through immediately, with no other config change.

Workspace-level override (per-tenant)

The CA above is the platform default. Each workspace can also pick its own CA at Settings → TLS certificate provider:

• Same preset list, same EAB rules.
• Use your own ZeroSSL or Google Trust Services account: paste your EAB credentials, dnswiz registers your account at the CA on the first issuance.
• Customizing automatically generates a per-workspace ACME account key that lives only in this workspace. Revert to platform default and that key is discarded.
• Workspace email overrides the platform contact for CA notifications about your certs.

Workspaces that haven’t customized inherit the platform default, so nothing changes for them when the operator switches CAs.

EAB (External Account Binding)

ZeroSSL and Google Trust Services require EAB: a kid (key identifier) and an HMAC key, both issued by the CA’s account portal. Paste them into the EAB fields in admin Settings and dnswiz uses them on first issuance against that directory. The HMAC is stored encrypted under the master key and never echoed back.

LE and Buypass don’t need EAB; the EAB fields stay hidden when an EAB-free CA is selected.

One key, many CAs

dnswiz keeps one ACME account key across all directories. When you switch CAs, the same key re-registers with the new CA on the first issuance, no re-keygen required. The CA stores its own account record keyed off the public-key thumbprint, so each CA sees its own account; we just don’t need to manage multiple private keys.

What’s stored, and what isn’t

• Your private key never reaches us. The browser generates it for the in-app flow; dnswiz cert generates it locally for the CLI flow. We only ever see the certificate signing request.
• We keep an issuance record: name, expiry, fingerprint, and the audit trail, so renewal tracking and the coverage gap detector work. That’s metadata, not key material.

When issuance fails

Every failure response carries an X-Request-ID; include it when you contact support. See the full error catalog.