v0.9.5

The first Hortval release. One idea runs through it: the server no longer
guesses where anything is. Every path it uses is one you wrote, ambiguity is
refused instead of resolved silently, and each refusal names what it wanted and
prints the exact line to paste.

If you are coming from Certeasy v0.9.4 and you pass -f with absolute paths,
your configuration needs nothing — jump to
Upgrading
for the case-by-case.

What this release gives you

• Hortval, under its own name. The command, the binary and the release
  artefacts are hortval / hortval-<version>-<os>-<arch>. Every invocation
  changes with it: the ExecStart of a systemd unit, the binPath= of a Windows
  service, your runbooks and your monitoring.

  Nothing inside the ACME protocol carries the name, so ACME clients are
  unaffected — no account, order or certificate needs anything done to it, and
  no client configuration changes. The configuration file keeps its name and every
  one of its keys.

• Nothing is guessed any more. Seven lookups and settings that used to resolve
  silently now refuse, and say what to write instead. This is the release, not a
  side effect of it — see Breaking changes for the list and
  Upgrading
  for what to do.

• The Windows binary is signed with Authenticode, timestamped so the
  signature outlives the signing certificate. Verify with
  Get-AuthenticodeSignature; the signer is SAFE PIC TECHNOLOGIES. Note that
  SmartScreen still appears — what changes is that it now names the publisher
  instead of saying "Unknown publisher". Linux and macOS binaries remain covered
  by SHA256SUMS for integrity only. See
  Verifying release binaries.

• SQL Server integrated authentication. Add authenticator=winsspi to your
  database.dsn and drop the credentials: Hortval connects as the Windows account
  it runs under, and no SQL password sits in config.yml. Windows only, and it
  needs a domain account. Hortval reports which method it obtained at startup
  and warns when the connection falls back to NTLM — which happens silently, and
  succeeds, when no Service Principal Name is registered on the SQL Server
  service account. See Database.

• hortval validate now checks the filesystem, and --no-disk skips it. It
  looks at what it can — does a working directory's parent exist, is an
  installation already sitting where a path resolves — because the machine you
  validate on is usually the machine that will serve. Two things it deliberately
  does not do: it never writes anything, and it never checks writability. A
  filesystem failure it cannot attribute is reported as a warning, not a
  verdict, because validate runs as the account that typed it while the server
  runs as its service account — guessing another identity's permissions produces
  confident wrong answers.

• New %CONFIGDIR% token, valid in workdir, expanding to the directory
  holding the configuration file. It exists because workdir is the one path that
  could not use %WORKDIR% — it is the working directory. hortval init now
  proposes %CONFIGDIR%/workdir instead of ./workdir, so a generated
  configuration means the same directory wherever it is later started from.

• A letsencrypt bundle now always serves an ECDSA P-256 certificate.
  Previously the key type was decided by whichever client connected first, and
  then served to everyone: autocert indexes its cache by key type and holds
  both, but the certificate manager keeps one certificate per bundle, so the first
  handshake settled it for the life of the process. If a client of yours needs
  RSA, use mode: pki or mode: files, where key.type is yours to set.

Not yet: running as a Windows service — this ships in v0.9.6

v0.9.5 cannot be started by the Windows Service Control Manager. The SCM
handshake is not implemented: sc.exe start fails with error 1053, and the
process is killed after about thirty seconds with its shutdown drain unfinished,
leaving db.sqlite-wal / db.sqlite-shm behind.

Run it in a console, or under a wrapper that performs the handshake on its behalf
(a scheduled task, or NSSM — neither is validated against Hortval yet). Native
service support, the Windows event log, and a hortval diag subcommand to prove
where the messages went are the headline of v0.9.6. See
Installation → Windows service.

This is stated here rather than left to be discovered: on the platform Hortval
targets, "runs as a service" is what deployment means.

Breaking changes

All of them are the same rule — a value that was guessed is now demanded —
and each refusal prints what to write. Only the last row is a rename rather than
a refusal.

What	v0.9.4 did	v0.9.5 does
workdir absent	picked a location for you	refuses. Why, and the conventional value per platform: workdir
a path setting holding a relative path	resolved it against the current directory	refuses unless absolute or anchored with %WORKDIR% / %CONFIGDIR%
config.yml in the current directory	loaded it, ahead of everything else	not searched at all — the current directory of a service created by sc.exe is C:\Windows\System32, and any directory a lesser account can write to selected the database, the working directory, the audit destination and the outbound proxy
two candidate configuration files	loaded one, ignored the other	refuses, naming both
a configuration file that exists but cannot be read	selected it, then failed to open it	skipped and reported; a readable one is used with a warning
%WORKDIR% in audit.path, logs.file, letsencrypt.cache-dir, local-cert-file, local-key-file	taken literally — it created a directory actually named %WORKDIR%	resolved
an unrecognised name in logs.services	silently ignored, so the level you asked for never applied	refuses. Certeasy-acme-server → acme-server, cert-easy-main → main

Two lookups also changed order without changing any outcome, since ambiguity is
now refused either way: configuration is looked for under hortval before
certeasy (the certeasy directories are still read, with a warning naming
both; they go away in v2), and machine-wide directories are searched before
per-user ones on every platform.

The licensing backend moved to api.hortval.com. If your egress is filtered
by hostname, allow it before upgrading — otherwise online licence checks fail and
the deployment slides into its degraded states. Offline installations are
unaffected.

Upgrading from v0.9.4 — what changes for an existing configuration

Nothing to do if you pass -f and every path in your configuration is absolute.
Otherwise, find your case:

Your v0.9.4 setup	v0.9.4 did	v0.9.5 does	What to do
-f <path> on the command line	loads it	same	nothing
No -f, config.yml in the current directory	loaded it	refuses, and lists where it looked	pass -f, or move the file
No -f, config.yml next to the binary	loaded it	same	nothing
No -f, config.yml in /etc/certeasy or %PROGRAMDATA%\certeasy	loaded it	loads it and warns	rename the directory to hortval before v2
Two candidate files in two directories	loaded the first, ignored the other	refuses, names both	pass -f, or delete one
config.yml and config.yaml side by side	.yml won	refuses, names both	pass -f, or delete one
A config file that exists but cannot be read	was selected, then failed to open	skipped, and reported; another readable file is used with a warning	fix the permissions
workdir: ./workdir (or any relative path)	resolved against the working directory	refuses; if a live installation sits where it resolves, prints the exact line to write	use that line, or an absolute path, or %CONFIGDIR%/…
workdir not set, old directory holds data	%ProgramData%\certeasy / /var/lib/certeasy	refuses, and names the three ways out	move it, or name it with workdir:, or delete it if it is a leftover
workdir not set, nothing in the old directory	%ProgramData%\certeasy / /var/lib/certeasy	%ProgramData%\hortval / /var/lib/hortval	nothing
workdir set to an absolute path	resolved	same, and the rename check is skipped	nothing
database.path: %WORKDIR%/db.sqlite	resolved	same	nothing
audit.path, logs.file, letsencrypt.cache-dir, local-cert-file, local-key-file with %WORKDIR%	taken literally — created a directory actually named %WORKDIR% under the working directory	resolved	delete any stray %WORKDIR% directory once the real files are in place
certreq-path / certutil-path	resolved from the Windows system directory, relative refused	unchanged	nothing
logs.services naming a service	applied it	refuses an unrecognised name (they were silently ignored); Certeasy-acme-server → acme-server, cert-easy-main → main	rename the keys

The wizard is affected too: certeasy init used to write workdir: ./workdir,
which v0.9.5 refuses. A configuration generated by v0.9.4's wizard therefore
needs its workdir line changed — the startup message tells you what to write.

See Minimal configuration for the full
search order, and [Configuration overview](../configuration/...

v0.9.4

We re-review the Certeasy codebase internally whenever materially more capable
code-analysis tooling becomes available. This release is the outcome of such a
review, run in July 2026 with the then-current generation of Claude and triaged
by hand. Every finding was assessed, and the ones that could affect a running
deployment are fixed here. Two breaking changes had to be introduced in the
product's configuration along the way; both are described below.

The review also recorded what was attacked and held. That part never appears in
a changelog, which is a shame, because it is what a security review is actually
for:

• No finding permits private key compromise, customer data exfiltration, or
  remote code execution.
• CSR validation verifies the signature rather than assuming proof of
  possession, and parses the request twice — once with the standard library,
  once with a strict hand-written ASN.1 pass — then compares the resulting SAN
  sets byte for byte, as a defence against parser differentials. Subject
  Alternative Names are restricted to dNSName: otherName/UPN, rfc822Name,
  URI and IP addresses are refused outright. This makes the ESC1/ESC6
  escalation vector structurally impossible rather than filtered — a
  distinction that matters on an ADCS deployment.
• JWS algorithm confusion has no landing point. The verifier is selected on
  key type, each verifier re-reads the protected header and requires an exact
  algorithm with a matching curve, and there is no HMAC verifier and no none
  verifier anywhere in the code — so the classic "sign with HS256 using the
  public key as the secret" attack has nothing to reach.
• No IDOR. Every endpoint that takes an object identifier — account, order,
  finalize, authorization, challenge, certificate — compares the object's owning
  account against the authenticated one before returning anything. No handler
  fetches by identifier without that check. The single unscoped lookup in the
  codebase is reachable only on the certificate-key revocation path — which
  RFC 8555 §7.6 requires — and only after the embedded key has been matched byte
  for byte against the certificate's public key.
• No SQL injection. Every query is a compile-time constant with
  placeholders; there is no LIKE query anywhere in the repository and every
  ORDER BY is a literal.

A dedicated security page covering the threat model and host hardening is in
preparation.

Security

This release resolves findings from an internal security review. Details of the
underlying mechanisms are deliberately omitted while deployments upgrade.

• A specially crafted request could cause a denial of service (remote,
  unauthenticated). Fixed. No data exposure and no authentication bypass.
• Order identifiers are now canonicalised when the order is created, and
  non-DNS identifier types are rejected explicitly. Previously an identifier was
  stored as submitted, so what was validated could differ from what was stored.
  This is a conformance fix (RFC 8555 §8.4) rather than an exploitable one:
  reaching the divergent case required write access to the DNS zone, which
  already allows obtaining the same certificate through the normal dns-01
  path. It is corrected because a stored value that diverges from the validated
  one is a hazard for future changes, not because it granted anything.
• Valid requests could be rejected under normal operation. A defect in the
  replay-protection bookkeeping refused nonces that were still valid. Any
  deployment with two or more concurrent ACME clients was affected
  continuously, without anyone attacking it — clients recovered by retrying as
  the protocol requires, so the symptom was extra round-trips and latency rather
  than visible failures. Single-client deployments were never affected.
• Log and audit files are now owner-only (0600, directories 0700),
  matching the rest of the product. This matters as soon as audit.path points
  outside the working directory: the audit trail records account identifiers,
  source IPs, user agents and decisions. On Windows this has no effect:
  access there is governed by the NTFS permissions inherited from the containing
  folder — set that folder's ACL at install time. The mode bits apply on Linux
  and macOS.
• Audit log rotation could destroy history. A failed rotation — an antivirus
  holding the file, a full disk, a permissions problem — could discard a
  generation of history without archiving anything, and without reporting it.
  Rotation was rewritten: it now fails without touching existing files, reports
  the reason on stderr, and retries later. See Breaking changes for the
  consequence on file naming.
• Updated golang.org/x/text and golang.org/x/crypto.

Rate limiting

Two changes here, and the second is new behaviour rather than a new setting.

• The per-IP request ceiling now applies to every endpoint, and is checked
  before any cryptographic work. Previously only four endpoints consulted it;
  the rest — including the polling a client does while waiting for validation —
  were unmetered. Because the ceiling now sees a client's full traffic, its
  defaults were raised accordingly: requests-per-minute from 200 to 1200,
  burst from 20 to 100. If you had tuned these values down, review them:
  issuing a single 3-name certificate costs at least 18 requests.

• New abuse limiter, enabled by default. It does not cap requests; it
  marks an IP that behaves in a way no conformant client does — a signature
  that does not verify, or an attempt on a resource belonging to another
  account. A marked IP is then refused on everything until it recovers, which
  takes about thirty seconds of good behaviour. Ten such events are tolerated
  first, so a client that slips once is unaffected.

  Marks are weighted. A request for an identifier that simply does not exist
  counts a quarter, because it has an innocent reading — a client returning to a
  URL whose resource has since been cleaned up gets the same answer as someone
  probing at random. Four such misses make one abuse, so occasional ones cost
  nothing while systematic probing still blocks. Routine outcomes count nothing
  at all, badNonce in particular: it happens to every client whenever the
  server restarts. See the configuration reference for the full table.

• Account creation now allows a deployment wave. account-creation moves
  from 5/hour with a burst of 2 to 10/hour with a burst of 10. Creating
  an account is a once-per-machine-for-life event, so legitimate traffic arrives
  in bursts when you provision, not at a steady rate — and a burst smaller than
  the hourly allowance refused the third machine of a batch deployed behind a
  single NAT address. The sustained ceiling, which is what actually bounds
  abuse, only doubles.

If your clients reach Certeasy through a reverse proxy, set trusted-proxies in
the server section so the limiters see real client addresses. Whitelisting the
proxy would exempt every client behind it.

Schema and migrations

A restart is rarely something a human decided — a crash, a reboot, a service
manager or a failed health check all restart the process, and none of them is a
moment when someone is standing by with a backup. Certeasy now applies on its own
only what doing nothing could have survived.

• A restart applies additive migrations only. Anything that cannot be undone
  by rolling the binary back stops startup and names what is pending. Nothing
  changes today for an existing deployment: every migration currently shipped is
  additive.
• New command certeasy migrate, with --confirm to acknowledge a backup and
  --sql to write the statements instead of running them.
• New setting database.noddl for accounts that hold no schema rights.
• A database newer than the binary, or left mid-upgrade, is refused rather
  than started on.

See Migrations for the full contract, the exit
codes and the noddl workflow.

Breaking changes

• The adcs-cli connector takes certreq.exe and certutil.exe from the
  Windows system directory (typically C:\Windows\System32) instead of
  looking them up through %PATH%. An unset key, or a bare file name with or
  without the .exe extension, resolves there — existing configurations keep
  working. Set a full path to run a copy kept elsewhere, for instance on a path
  carved out of an EDR policy. A path relative to the working directory
  (tools\certutil.exe) is now refused at startup and by certeasy validate.
  The native connector is unaffected: it runs in-process over COM and starts no
  external binary.
• ADCS ca-name and certificate-template are refused when they contain a
  control character or a colon, or start with a dash. Those characters
  delimit fields in the request sent to the CA, so a value carrying one changes
  the request rather than naming it. Ordinary names — PKI01\Lab-Issuing-CA,
  Web Server v2 — are unaffected.
• A dns-validation-profiles entry with neither allow-cidrs nor
  deny-cidrs is refused at startup, and by certeasy validate. An empty
  resolved-ip-policy accepted every address DNS returned — link-local and cloud
  metadata (169.254.169.254) included. Unset is not the same as deliberately
  open, so it is refused instead of defaulted. Add the networks your targets live
  on, or allow-cidrs: ["0.0.0.0/0", "::/0"] if you accept any address on
  purpose. This applies to every profile whatever challenge you use: challenge
  types cannot be restricted per profile, so a profile that has only ever seen
  dns-01 still offers the paths this policy guards. Configurations produced by
  `...

v0.9.3

New features

• ADCS certificate revocation: ACME revocations now propagate to the backing Microsoft ADCS CA (CRL / OCSP), not just Certeasy's own database. RFC 8555 §7.6 authorization is supported with both the account key (kid) and the certificate key (jwk). Propagation can be turned off per authority with disable-ca-revocation: true (for service accounts without the required CA role, or air-gapped deployments). Note: revoking on the CA needs the Certificate Manager role — a higher privilege than enrollment.
• certeasy adcs check — a read-only preflight for ADCS authorities: checks that the CA is reachable, that the certificate template is published, and reports the template's key requirement. Use it to diagnose ADCS setup before starting the server (or to hand support a clear status).
• Configurable server-certificate key: a pki-mode bundle in the TLS certificate manager now accepts an explicit key: — type: rsa with size: (bits), or type: ecdsa with curve: (P-256/P-384/P-521). Set it when the CA template mandates a specific key. In particular, an ADCS template that requires RSA 4096 previously rejected Certeasy's default ECDSA key and prevented startup; key: { type: rsa, size: 4096 } resolves it. The default is unchanged (ECDSA P-256).

Improvements

• certeasy init — ADCS onboarding: the wizard now defaults to ADCS, lists the CA's published certificate templates so you select the exact one (no typos, only published templates), and reads the template's key requirement to set the server-certificate key automatically — falling back to asking you when the template cannot be read.
• Clearer ADCS denial messages: when the CA denies a request, Certeasy now surfaces the actual reason (for example, "the public key does not meet the template's key size requirement", CERTSRV_E_KEY_LENGTH) with an actionable hint, instead of an opaque CR_DISP_DENIED. The diagnosis is keyed on the CA's error code, so it stays accurate regardless of the CA's display language.

Security

• Updated the Go toolchain to 1.26.5.

---

v0.9.2

New features

• Native ADCS connector (now the default for type: adcs): Certeasy enrolls against ADCS in-process, without launching certreq.exe. This removes the child-process (LOLBin) signature that strict EDRs flag, making Certeasy eligible for more hardened deployment perimeters. Existing type: adcs configurations switch to it automatically on upgrade — no change required.
• certeasy validate — a configuration check in the spirit of nginx -t. certeasy validate -f <config> parses and validates a configuration statically, with no side effects (no database, no network, no file writes). serve now runs the same validation as a fail-fast boot gate, so an invalid configuration is rejected before startup instead of failing halfway through.

Improvements

• certeasy init now lets you choose the ADCS connector (native in-process, or certreq.exe) when generating a configuration.

Changes

• The certreq.exe-based integration remains available as an opt-in fallback under type: adcs-cli.
• The unused cert-util-timeout ADCS option is no longer documented; it is still accepted in existing configurations but has no effect.
• ADCS request timeout: default-timeout now defaults to 4 minutes and is honored as configured. Previously a legacy behavior capped the effective ADCS wait at 30 seconds regardless of default-timeout; that cap is removed. Keep default-timeout below workers.max-job-duration (default 5m) — Certeasy warns at startup if it is greater than or equal.

Fixes

• certeasy init generated an ADCS authority block with incorrect field names; it now emits the correct ca-name / certificate-template schema.
• SQL Server backends: upgraded the SQL Server driver to go-mssqldb v1.10.0, which improves connection handling when a query is cancelled or times out. Recommended for all SQL Server deployments.
• DNS validation profiles: the zone protocol field (udp / tcp) is now honored. It was previously parsed but ignored (DNS lookups were always UDP-first with a TCP fallback); set protocol: tcp to force DNS validation over TCP on networks where UDP/53 is unavailable.

---

v0.9.1

New features

• certeasy init command — interactive (and scriptable) wizard to generate a config.yml.
• Database connection: new conn-max-lifetime and conn-max-idle-time options.

Improvements

• Readable text output for one-shot subcommands (license, backup, audit, cold-start). The serve daemon keeps its structured JSON output.
• All displayed and logged dates are in UTC.
• Richer startup banner: installation ID and license ID.

Changes

• The --grace and --cold-start-plan flags are removed. The boot mode (valid license, post-expiration, cold-start, refusal) is now determined automatically from persistent state.
• License registration is validated by the portal; a portal refusal is surfaced verbatim to the operator.
• A license retired by the portal enters a grace window before boot is refused.

Fixes

• Shutdown stability: removed a possible SQLite panic and a goroutine leak on the ACME rate limiter.

---