Skip to main content

1.5.49

Released 8 Sep 2026

New​

  • IIS sites and bindings can now be picked from the server. When you set up an IIS target — or set a per-certificate binding override — CertAutoPilot can list the machine's sites, HTTPS bindings and application pools instead of asking you to type them from memory. Each binding shows the certificate it carries right now, with its subject and expiry date, so you can see before clicking whether a binding already belongs to another certificate. Every field still accepts a typed value, and falls back to plain text entry when the server can't be reached.

    Listing through a saved target is a project operator action; browsing from a target form you haven't saved yet uses the connection details on screen and is restricted to project admins.

  • Kubernetes namespaces, TLS Secrets and workloads can be picked from the cluster. The Kubernetes target form and the per-certificate override drawer list the cluster's namespaces, the namespace's TLS Secrets — each showing the certificate it currently holds and whether CertAutoPilot already manages it, so you can see whether picking one would overwrite another certificate — and its Deployments, StatefulSets and DaemonSets with the Secrets each one mounts, so a restart target that never uses the certificate stands out. Secret data never leaves the cluster; only a certificate summary is shown. Every field still accepts a typed value. The same rule as for IIS applies: listing through a saved target is an operator action, an unsaved form needs project admin, and an in-cluster target lists with the pod's own service account.

  • HashiCorp Vault mounts and paths, and Azure Key Vault certificate names, can be picked too. On a Vault target the mount list comes from the server with each mount's KV version (a mismatch with the target's engine type is flagged) and the secret path can be browsed folder by folder — nothing is read, only listed. On an Azure Key Vault target the certificate-name field lists the vault's certificates with their expiry and whether CertAutoPilot already manages them for another certificate. Both work in the target form and in a certificate's override row.

  • See which bindings a placement would touch, before deploying. A Preview affected bindings button next to the IIS placement fields — on the target and on each certificate's per-target override row — lists exactly the bindings a deploy would update, together with the certificate on each one. It warns when a filter matches several bindings (which would fail a single-binding deployment), when it matches none, and when a listed host header exists nowhere on the site. No certificate is sent and nothing is changed.

  • SSH targets can now refuse a changed host key. A new per-target setting, Require approval when the host key changes, remembers the first key a server presents and stops deployments if it ever changes — the certificate and its private key are not sent until you review the new fingerprint and approve it. The targets list flags the affected target, a failed deployment links straight to it, and the review dialog shows how long the previous key had been trusted, how many deployments it served, and the command to verify the new one on the host itself.

    Approving queues the affected certificates for redistribution, so the deployment resumes without further action. If some targets in that distribution already had the certificate, re-run it once from the certificate's Distributions tab. A blocked target does not affect the others in the same distribution — because nothing was written to it, the hosts that did receive the certificate keep it.

    It can stop deployments once you enable it

    The setting is off by default and changes nothing until you turn it on, so existing targets keep behaving exactly as before. Once on, a changed key stops deployments to that target until you approve it — which is the point, but plan for it. Leave it off where one name fronts several machines (load balancer, HA pair): each presents a different key, so verification would fail at random.

  • Palo Alto Networks PAN-OS firewalls are now a distribution target (PAN-OS 9.0+): the certificate, key and chain land as one named certificate object, committed with a partial commit scoped to CertAutoPilot's own API user — other administrators' pending work is never pushed. Renewals re-import under the same name, so existing SSL/TLS profile and GlobalProtect bindings are preserved automatically, and certificates the module did not upload are never touched. An optional setting leaves the import uncommitted in the candidate configuration for review.

  • Zero-config Kerberos for every Windows connection. Kerberos authentication no longer requires any setup on the CertAutoPilot host — no krb5.conf, no environment variables, no container mounts. The Kerberos configuration is built in memory and the domain controller is discovered automatically from the DNS SRV record every Active Directory domain publishes. Just set the realm on the connection and address the target by its AD FQDN.

  • Optional KDC Address field. For hosts whose DNS cannot resolve Active Directory records, an optional per-connection KDC Address field (host or host:port) pins the domain controller explicitly — a form field, never a file. Available on WinRM, Exchange and IIS targets, and Windows DNS credentials.

  • Kerberos on IIS targets. The IIS module now authenticates with Kerberos, and the auth method can now be chosen on the IIS target (aligned with the WinRM and Exchange targets; a target without one keeps using the credential's auth fields). This unlocks IIS deployments on hardened, domain-joined servers where a GPO blocks incoming NTLM and Basic authentication.

Improved​

  • Windows failures no longer arrive as markup. When a command fails on a Windows server (IIS, WinRM or Exchange targets), PowerShell answers with a serialized object stream. CertAutoPilot now decodes it: job logs show the error text and PowerShell's position lines instead of a page of XML, and the IIS pickers and placement preview reduce it further to the one sentence that matters, such as "Site 'Web1' not found". The IIS error code inside that stream is also recognised again, so failures are reported as what they are rather than a generic import error.

  • The Targets list has a type filter next to the search box; like the search, it applies across every page of the list.

  • Bare usernames everywhere. WinRM and IIS credentials now take just the account name — the NTLM DOMAIN\ prefix is added automatically from the target's Domain field, and with no domain the account is explicitly marked local (.\user). Names you qualify yourself (DOMAIN\user, user@fqdn, .\user) are used verbatim.

Changed behaviour​

krb5.conf is no longer read

The WinRM transport no longer reads /etc/krb5.conf or the KRB5_CONFIG environment variable — existing files are simply ignored, and connections keep working through automatic DNS discovery. If your environment relied on a krb5.conf that pointed at a domain controller your DNS cannot resolve, enter that address in the new KDC Address field on the connection. (The RFC 2136 GSS-TSIG DNS provider is unaffected: it still uses the system krb5.conf.)

Multi-node upgrade: finish every worker before saving a site-less IIS override

An IIS override with an empty Site name is new in this release. A worker still on an older version does not understand it and deploys such a certificate to the target's own binding instead — silently. On a multi-node installation, upgrade every node before you save an override that leaves the Site name empty.

  • The Site name in a per-certificate IIS binding override is now optional. Leave it empty and the override applies to the target's own site, so you can give each certificate its own port or host header without repeating the site name. Filling it still moves the certificate to another site. A target that sweeps every site has no single site to inherit, so an override there must still name one.

  • Browsing a saved target from the server (the IIS and Kubernetes pickers, the placement preview) always uses the credential the target was saved with. Switching an existing target to a different credential and browsing before saving now needs project admin — that pairing is what the configuration approval reviews.

  • The MerlinCDN distribution and canonical-name pickers now use the shared live-picker API call. The two MerlinCDN-only listing calls they used before are gone; a script that called them directly must switch to the shared call (see the API reference).

  • An unrecognized auth_type on an IIS credential is now rejected when saving. Previously any value other than basic silently fell back to NTLM.

NTLM: a bare username with an empty Domain now means a LOCAL account

Previously a bare username with no domain was sent unqualified, letting the Windows server resolve it — on a domain-joined machine that could match a domain account. It is now sent as .\user (explicitly local). If a WinRM, IIS or Windows-DNS connection that used a bare domain-account name starts failing with 401 after upgrading: set the Domain on the connection, or prefix the username as DOMAIN\user (prefixed names are always used as-is). Relatedly, a WinRM target with an empty auth_type no longer ignores its Domain field.

  • Kerberos usernames must be bare account names: a DOMAIN\- or @-qualified name (which can never authenticate — the KDC does not know such a principal) is now rejected with a clear message when the connection is built, and at save time for Exchange credentials, instead of failing at deploy time with a cryptic KDC error.

Fixed​

  • A Kubernetes target in in-cluster mode no longer accepts an API server override, a proxy URL or "skip TLS verification": those settings would have sent CertAutoPilot's own service-account token to whatever address they named. Saving such a combination is now refused, and existing targets that carry one ignore it and dial the pod's own API server. Naming a credential when browsing an in-cluster target is refused the same way instead of being silently ignored.

  • Kerberos login failures caused by an undiscoverable domain controller now explain exactly what to fix: point the host's DNS at the AD DNS servers, or set the connection's KDC Address field.

  • Running a key command without the wrapper now says what to do. On a standalone install the credentials live in a file only the service loads, so invoking the binary directly failed with an unexplained "Unauthorized" from the database. The error now names the wrapper command to use instead.

  • The log line after a key rotation no longer asks for cleanup that is not needed. It reported that the active key version differs from the one in the configuration file and told operators to tidy it up. That value only seeds the very first install and is ignored afterwards, so a rotation leaves it behind on purpose; the line now says so and no longer implies an unfinished step.

  • A key rotation that skipped records no longer looks like a hang. When some records could not be re-sealed, the cluster rotation command did not recognise the outcome and sat silently until it timed out after twenty minutes — on the one run that actually needed attention. It now reports the result immediately, says the records are still readable under the old key, and gives the command to re-run.

  • The guard against starting a second rotation now works. It looked for a status the product never reports, so it matched nothing for the whole time a rotation was in flight — exactly when it was needed.

  • On-screen and command-line guidance about key rotation now matches what the product does. kek rotate --help told operators to set an encryption version variable across the fleet first and claimed the command enforced it — neither was true, since that value only seeds a first install. The KEK Versions screen said rotations were recorded in the audit log (they are not; the operator is recorded on the rotation itself), and both that screen and Cluster instances described a version-mismatch warning as a hard gate on starting a rotation, which it is not. The keystore-drift alert also no longer prescribes a restart: instances adopt a newly activated version on their own within about 30 seconds, and an alert that persists means the key material is missing on that host.

  • The cluster key-rotation command now reports that it finished. It could exit silently right after starting the rotation, printing no completion summary and no follow-up guidance. The rotation itself always ran to completion server-side; only the command's own reporting stopped early, and it did so more readily the more rotation history an installation had.

  • Cloudflare deployments no longer overwrite a certificate CertAutoPilot did not upload. A zone's production wildcard covers every subdomain, so a deployment for a single hostname could adopt and replace the certificate serving the whole domain. Such a deployment now fails and names the certificate that blocked it.

Taking over an existing Cloudflare certificate is now deliberate

Only two things count as CertAutoPilot's own: a certificate it uploaded, and one whose id an operator pinned on the target. If its record of its own certificate is ever lost — a restore from a backup taken before the upload, for instance — the next deployment refuses instead of silently re-adopting. Pin the id once to hand it back.