Skip to main content

1.6.0

Released 18 October 2026

New​

  • Elchi distribution target. CertAutoPilot keeps a certificate in its own TLS secret in every version Elchi serves — no version to enter — and afterwards updates only those secrets (including the copy Elchi makes when a listener moves to a new version), which Elchi publishes to the listeners that use them; binding the secret to a listener is done in Elchi. A secret of the same name that CertAutoPilot did not create stops the deploy before anything is written.

  • Limit a user to the resources you choose. A project role can now cover only granted resources: an admin or operator then sees and manages just the resources granted to them — certificates, targets, credentials, modules, certificate authorities, DNS zones, discovery sources, notification channels and the rest — with a role per resource, and their lists, dashboard, jobs and audit log show only those. Grants are set on each resource's new Access tab or in Settings → Users → Roles → Grants, where you can also allow creating new ones; a deleted resource takes its grants with it.

Multi-node installs: upgrade every node before limiting a user

A user's role can be limited to granted resources only once every node runs 1.6.0 — until then the role screen refuses it.

Multi-node installs: upgrade every node before adding an Elchi target

A node still on 1.5.57 has no Elchi module and fails a distribution job for an Elchi target it happens to run. Add Elchi targets after every node runs 1.6.0.

  • User groups. Give roles and resource grants to a group in Settings → Groups and every member has them, its own roles and its groups' counting together with the highest winning; groups show up in each resource's Access picker and in a user's Roles dialog. A group can follow LDAP groups: at every LDAP sign-in the user joins the linked groups and leaves the ones it left in the directory, while members added by hand stay.
Multi-node installs: upgrade every node before relying on groups

A node still on 1.5.57 ignores group roles and grants, so on that node a member has only its own roles.

  • Approval per project, for chosen operators. Settings → Approvals sets, for each operation — issue, renew, re-issue, revoke, download, configuration changes and distribution actions — whether no operator, every operator, or only selected users and groups need approval. Admins and owners are never asked, and only an organization owner can change a project's approvals.
  • Expiry alerts follow each certificate's renewal plan. An automatically renewed certificate alerts only when its renewal is overdue (after a configurable grace, default 24 hours); a certificate nobody renews automatically alerts at configurable lead times (default 30, 14, 7 and 1 days before expiry), shortened for short-lived certificates; every certificate alerts daily in its last 3 days. Set both on Settings → General; the alert now says how many days are left and why.

Improved​

  • Choose the role new LDAP users get. Settings → LDAP → Default role for new LDAP users keeps the org-wide viewer by default; None gives a new LDAP user only what its groups give. The default is applied once, when the account is created.
  • A new sign-in screen. Sign-in and first-run setup open beside a short animation of what CertAutoPilot does with a certificate — discover, validate over DNS, issue, distribute, renew; on a phone the form stands alone.
  • The LDAP group-filter test shows the group names a sign-in would read and warns when the found group entries lack the configured Group attribute — for example memberOf, which would read no names and remove LDAP users from their groups at every sign-in.
  • The Settings menu marks pages that are not about the selected project with Global: they apply to every project.

Changed behaviour​

  • Approval settings moved from Settings → General to each project. Every project starts from the defaults — configuration changes need approval from every operator, nothing else does; switches turned on under General before the upgrade are not carried over, so turn them on again per project.
Multi-node installs: upgrade every node before saving an approval policy

A node still on 1.5.57 does not know project approvals and keeps applying the switches it reads from General settings — until General settings are saved on an upgraded node, which drops those switches, so that node then asks no operator for approval except for configuration changes. Save General settings and a project's approvals only once every node runs 1.6.0; saving approvals is refused before that.

  • IIS certificates carry a friendly name. An IIS deploy now labels the certificate in the Windows store CAP-<certificate name> (its primary domain when it has no name), replacing any friendly name it had, so it can be told apart in the IIS binding dialog and the certificate manager. Certificates already in the store get the label the next time a deploy updates their binding.
  • Expiry alerts are no longer sent every day. A certificate used to raise Expiring Soon every day for its last 30 days, healthy automatic renewals included; each lead time now alerts once and an automatic renewal on schedule stays quiet. On the first check after the upgrade, certificates that expired in the last 30 days send one Certificate Expired alert. Until every node runs this version, an older node may still send the daily alerts.

Fixed​

  • An LDAP sign-in whose directory entry lacks the Username attribute is refused. Such sign-ins used to share one account with an empty name; an entry with several values signs in with the one matching the name typed, and saving the LDAP page now refuses a user or group filter without %s.
  • The stored LDAP bind password stays with its directory. Changing the LDAP host now asks for the password again, and Test Connection / Test Filter against a different host no longer send the stored password there.
  • Drop-down lists open again on computers with animations turned off. Since 1.5.57 no selection list (certificate authority, ACME account, every other drop-down) opened on such machines — common on Windows over Remote Desktop or VDI — because it was placed off-screen.
  • The dashboard's "expiring soon" count covers only the selected project. It used to count every project's certificates.
  • The zoomed lifetime axis on a certificate's chain of trust no longer piles its month labels on top of each other for a certificate that expired long ago; long windows are labelled by quarter, half year or year.
  • An approved download saves the file you asked for. Executing it used to open a new tab showing the raw response, private key included, whatever format had been picked; the file is now saved in that format for whoever executes it — the requester or a project admin (an admin's Execute used to hand back a token nobody could use) — and a PFX or JKS comes with a generated password shown once.
  • An approval request on a certificate revoked after approval is closed. It used to stay approved, with an Execute button that failed every time.
  • Reviewers see what a request touches. Distribution requests are named certificate → module (a rollback adds the version), referenced modules, targets and credentials appear by name, and an update lists each changed field next to its current value.
  • A project admin can execute an approved request from Pending reviews, as the requester can, and the Pending reviews count no longer changes to the total of the list being shown.
  • Confirmations on icon buttons are readable and named. The button's tooltip no longer covers the confirmation's Cancel button, and icon-only buttons on the targets, target groups, libraries and variables pages carry a name for screen readers.
  • Certificate Expired notifications are sent. No version sent them before, although rules could subscribe; they now fire once per expiry — also for a certificate left in renewal failed, which used to stop alerting the moment it expired.