Skip to main content

1.5.39

Released 9 August 2026

Certificates that land in Azure and stay current. Azure Key Vault becomes the fifteenth distribution target: each renewal is imported as a new version under the same name, so App Service, Application Gateway, API Management and AKS pick it up on their own.

New​

  • Azure Key Vault distribution target — Push the certificate, its chain and its private key into a vault as a Key Vault certificate. Every renewal becomes a new version of the same certificate object, so consumers that reference it without pinning a version pick up the renewal with no extra step. Sovereign clouds are detected automatically from the vault URL.
  • Azure service principal credential — A new credential type holding tenant, client ID and client secret. The principal needs the Key Vault Certificates Officer role, or Get + Import + List on access-policy vaults. A health check proves reachability, credentials and permissions before you deploy anything.
  • Per-certificate vault naming, or adopt an existing one — Leave the certificate name empty and a stable unique name is generated per certificate (previewed in the form), so a single vault target can serve many certificates. Set a name on the target, or override it per distribution, to take over an existing Key Vault certificate instead.
  • Built-in Azure troubleshooting — Six dedicated error codes with actionable hints appear on the distribution tab, including what to do about the common soft-deleted-name conflict (recover it, purge it, or pick another name) and how to tell a vault firewall block from a missing permission.

Changed behaviour​

  • Microsoft Exchange and Cloudflare are labelled "(experimental)" in the module, target and target-group pickers. Their behaviour is unchanged — the label signals that testing is not yet complete.
  • Azure Key Vault deployments cannot be rolled back. Earlier versions remain in the vault, but CertAutoPilot will not re-point consumers back to one, so the rollback action is not offered for this target type.
  • Strict validation on Azure targets. A Key Vault target accepts only a bare HTTPS vault URL on a recognised Key Vault domain — no port, path or embedded credentials — with a valid vault name; the certificate name is limited to letters, digits and hyphens. Anything else is rejected when you save the target or a per-distribution override.
  • The Key Vault certificate policy is written only on the first import. Renewals deliberately do not resend it, so lifetime actions or exportability you configure on the certificate afterwards are preserved. A name already owned by a different CertAutoPilot certificate produces a warning rather than a failure, and ownership moves.

Fixed​

  • Authorization headers could still leak into logs. Redaction masked only the scheme word, leaving the token itself visible in module and job logs. The whole header value is now redacted, and client secrets in JSON payloads are redacted too.
  • AD CS certificates showed a misleading validation method. The detail page labelled them DNS-validated; it now reads "not applicable — AD CS enrollment".