Quick start with the wizard

certeasy init is the recommended way to get a working configuration in a few minutes. It walks you through a handful of questions — what to listen on, which database, which authority, which DNS zones you'll be issuing certificates for, how the server's own TLS cert should be obtained — and writes a valid config.yml you can serve immediately.

It's not a black box: every prompt shows you a sensible default in brackets and explains what the field does. With an ADCS authority it runs a quick, read-only check against your CA (is it reachable, is the template published, what key does it require); in --script mode it stays fully offline.

Run it

After installing the binary, from the work directory:

certeasy init

That's it. By default it writes to ./config.yml. Use -o <path> to put it elsewhere, or --force to overwrite an existing file.

What it asks

The flow is roughly:

Section	What you decide
Network	Listen address, public URL(s) as seen by your ACME clients
Database	sqlite (default, all plans) / postgres / sqlserver (Pro and Enterprise plans). Connection details are turned into the right DSN — leave the password blank to get a ${...} placeholder.
Workdir	Where the runtime files live
Authority	adcs (Microsoft ADCS — the default) or fake (built-in lab PKI — generates its own root). For ADCS it asks for the CA name and template, lists the CA's published templates so you pick the exact one (no typos), and reads the template's key requirement to set the server certificate key for you.
DNS zones	One zone at a time: zone name, maximum subdomain depth (with worked examples), wildcard policy. Add as many zones as you need.
clientAuth EKU	Opt-in relaxation needed only if you plan to use acme.sh (which emits CSRs with an extra clientAuth EKU). Off by default.
Server's own TLS	Issue from the authority above (pki), Let's Encrypt automatically, or supply your own files. With an ADCS authority the key type (RSA size / ECDSA curve) is set to match what the template requires.
Plan sizing	Three quick questions (how many authorities, how many client servers, which DB) — the wizard suggests the cold-start plan that fits and offers to open the window for you on the spot

What it generates

A YAML file equivalent to config-minimal.yml plus the choices you made:

• server.listen + server.url
• database.driver (+ path or dsn depending on the driver)
• workdir
• tls-certificate-manager.bundles[0] (auto-filled hosts list from the public URL)
• dns-validation-profiles[0] with each zone you declared
• authorities[0] (fully configured, fake or adcs)
• issuance-policies[0] with the depth/wildcard rules you chose, plus an explicit =<public_host> allow so the server can always issue its own cert
• policy-bindings written explicitly so the relationship is obvious

What's next

After the configuration step the wizard asks how you want to start the server:

1. Open a cold-start window — for evaluation / first run. It calls cold-start init with the suggested plan.
2. Install a .lic file — if you already have one. Equivalent to license install.
3. Register a CRT-... key online — equivalent to license register. You'll be asked for the deployment environment (prod, dev, staging, uat).
4. Skip — prints the commands you can run later.

Whichever branch you pick, the wizard prints the final commands you need (typically certeasy serve) and exits.

Replay a session

certeasy init --save-script /tmp/answers.txt

writes every answer you typed to a small text file. To regenerate the same configuration on another machine — or to keep a reproducible setup recipe in your git repo — feed it back to the wizard via stdin:

certeasy init --script -o config.yml < /tmp/answers.txt

It's the same answers, same defaults, same output — no interactive prompts. Useful when you want a teammate to apply the exact same setup, or to keep a record of what was chosen on a server you no longer own.

When to use the wizard vs. write YAML by hand

The wizard covers the common cases: one authority, a few DNS zones, a straightforward TLS bundle, sqlite or a basic postgres/SQL Server.

If your deployment is more exotic — multiple authorities with bindings, several DNS validation profiles, fine-tuned rate limits, a custom audit log location — start from the wizard's output and edit by hand from there. The Minimal configuration and reference pages cover every field.