Skip to main content

1.5.43

Released 17 August 2026

For organisations whose infrastructure passwords rotate continuously, a deployment credential no longer has to be copied into CertAutoPilot at all — plus a fix for a status that could stay wrong indefinitely.

New​

  • Read a distribution credential from your own secret manager. A credential can now point at a secret in HashiCorp Vault or OpenBao instead of storing its value here. CertAutoPilot keeps only the reference and reads the value from the store every time it is needed, so rotating the secret on your side takes effect immediately — there is no copy here to update, and no waiting for the next renewal. Set it up under Settings → Distribution → Secret Stores, then choose External secret store as the Secret Source when creating a credential.

  • ManageEngine PAM360 joins Vault and OpenBao as a secret store. A credential can reference a PAM360 resource + account, and the account's password is fetched on every use through PAM360's REST API — validated against a live PAM360 install. Adding it changed nothing about how stores or credentials are configured, which is the design's core promise.

  • Secret stores are their own object. One store is shared by every credential that reads through it, so changing its address or rotating the login CertAutoPilot uses is a single edit rather than one per credential. Creating and editing a store requires admin, exactly as for credentials.

  • Test a secret store, and test a credential. Saving a store deliberately does not contact it; the Test button on the store list connects and verifies its credentials without reading any of your secrets. Test on a credential resolves it exactly as a deployment would and reports the shape of the result — whether it is JSON and which keys it holds, and which revision it read — never the value itself, and never its length.

  • The credential list shows where each value comes from. A new Source column distinguishes credentials stored in CertAutoPilot from those read out of a secret store.

  • Approval requests flag a change that binds a live credential. When an operator's target change would attach a store-backed credential, the review screen now says so: the value is fetched fresh on every deployment, so approving the target is what grants access to the current secret — and rotating it later does not take that access back.

Improved​

  • Azure Key Vault is no longer marked "(experimental)". The module's validation on real vaults is complete, and its labels in the module, target and credential pickers now match the other stable modules. Microsoft Exchange and Cloudflare keep the label for now.

  • Failures while preparing credentials now say "resolving" rather than "decrypting". For a credential that was never stored here, the old wording described something that does not happen; the message now names the credential, the store, and the underlying failure.

Changed behaviour​

If you adopt secret stores

A deployment that uses a store-backed credential now depends on that store being reachable. If it is not, the distribution fails before any target is touched, rather than deploying with a partial credential. Certificate issuance and renewal are unaffected. On a distribution large enough to be split into batches, each batch gets a single attempt, so an outage during such a run means the distribution has to be re-run.

  • Deleting is refused where it would break a deployment. A secret store cannot be deleted while any credential still reads through it, and a credential cannot be deleted while a secret store authenticates with it — in both cases the reference could not be repaired afterwards.

  • A credential's source is fixed once it is created. Switching a live credential between stored and store-backed would change its security posture silently, so it is not offered. Create a new credential and repoint the targets instead.

  • Deployment logs now record which revision of a store-backed secret was used. On versioned Vault mounts this makes it visible when the underlying secret changed between two runs, without exposing anything about the value.

  • Testing a credential now checks whether the value fits its type. A value stored in the wrong shape — a bare password where the module expects a username and password together — is reported by Test, instead of only surfacing as a deployment failure later.

  • Secret stores are monitorable. Reads, their duration, and the retries a failing store causes are exported as metrics, so a degrading secret manager can be alerted on directly rather than inferred from failed deployments.

Fixed​

  • A certificate kept showing "distribution pending" after a successful manual deployment. The certificate-level pending mark was only ever cleared by the automatic deployment that follows issuance or renewal. When that automatic run failed and used up its retry attempts, the only way forward was to run the distribution by hand — and a manual run, even a fully successful one, never cleared the mark. The certificate was then left contradicting itself: the distribution read success, while the certificate list and detail page still showed Dist. Pending, and it stayed that way until the next renewal.

    A successful deployment now clears the mark itself. It is cleared only when every enabled distribution of that certificate has delivered the current certificate version, so a certificate that still has other undelivered distributions keeps its pending state and its automatic retries. Rolling back does not clear it, because a rollback deliberately puts an older version in place.