📋 Recommended Actions

⚠️ Action Required
Immediate action is not universally required but highly recommended to review the default changes for promoted feature gates (like NameConstraints and UseDomainQualifiedFinalizer now defaulting to true) and the deprecation of ValidateCAA (now defaulting to false). Adjust your configurations as necessary to maintain desired behavior, especially if you rely on the previous implicit defaults. Consider leveraging the new literal keystore password option for simplified management.

This cert-manager v1.17.0 release brings exciting advancements and crucial refinements, enhancing both security and operational flexibility. Key highlights include the promotion of the NameConstraints and UseDomainQualifiedFinalizer feature gates to Beta, signaling their readiness for broader adoption. We’re also introducing support for literal keystore passwords for JKS and PKCS#12, streamlining certificate management. A notable improvement to the CA injector now allows merging certificate authority bundles, making webhook and API service bundle updates more robust. Additionally, Azure DNS managed identity configurations gain more flexibility with the new tenantID option. This update also includes numerous dependency bumps, bug fixes, and logging improvements, bolstering overall stability and performance.

✨ Feature Gate Promotions: NameConstraints and UseDomainQualifiedFinalizer to Beta

Cert-manager v1.17.0 marks a significant step for two key features: NameConstraints and UseDomainQualifiedFinalizer, which have now graduated to Beta. This promotion signifies their increased stability and readiness for production environments, offering users more powerful and reliable tools for certificate management and resource cleanup. As Beta features, they are now enabled by default, meaning their benefits—enhanced security policies for certificate issuance and improved consistency in Kubernetes resource finalization—will be automatically applied, although you can still explicitly disable them if needed.

The NameConstraints feature gate, now defaulting to true, enables you to define precise restrictions on DNS names and IP addresses within certificates issued by your CAs. This is critical for enforcing organizational security policies. The UseDomainQualifiedFinalizer feature gate, also defaulting to true, introduces a standardized finalizer format (acme.cert-manager.io/finalizer) for cert-manager managed resources, ensuring more predictable and robust cleanup workflows across your Kubernetes clusters. While these features are now enabled by default, the ValidateCAA feature gate has been deprecated and now defaults to false, with plans for removal in v1.18. Users who relied on its prior implicit behavior should explicitly set it to true if continued validation is required.

Here’s an updated snippet from the Helm chart values.yaml illustrating the new default states:

    featureGates:
      AdditionalCertificateOutputFormats: true # BETA - default=true
      AllAlpha: false # ALPHA - default=false
      AllBeta: false # BETA - default=false
      ExperimentalCertificateSigningRequestControllers: false # ALPHA - default=false
      ExperimentalGatewayAPISupport: true # BETA - default=true
      LiteralCertificateSubject: true # BETA - default=true
      NameConstraints: true # BETA - default=true
      OtherNames: false # ALPHA - default=false
      SecretsFilteredCaching: true # BETA - default=true
      ServerSideApply: false # ALPHA - default=false
      StableCertificateRequestName: true # BETA - default=true
      UseCertificateRequestBasicConstraints: false # ALPHA - default=false
      UseDomainQualifiedFinalizer: true # BETA - default=false
      ValidateCAA: false # ALPHA - default=false

Source:

  • internal/controller/feature/features.go (lines 124-147,166-168)

  • internal/webhook/feature/features.go (lines 67-70,98)

  • deploy/charts/cert-manager/README.template.md (lines 374,377)

  • deploy/charts/cert-manager/values.yaml (lines 244,247)

  • cmd/controller/app/options/options.go (lines 261-264)

🔑 Literal Keystore Passwords for JKS & PKCS#12

Managing keystore passwords can often be a cumbersome process, frequently requiring external Secret management. Cert-manager v1.17.0 addresses this by introducing the ability to specify literal passwords directly within the Certificate resource for JKS and PKCS#12 keystores. This greatly simplifies configuration for users who prefer direct inline password specification or when integrating with systems that generate passwords dynamically, providing a more flexible approach to keystore creation.

New password fields have been added to both JKSKeystore and PKCS12Keystore sections of the Certificate spec. These fields are mutually exclusive with the existing passwordSecretRef, meaning you can use one or the other to provide your keystore password. This offers more direct control and can reduce the overhead of managing separate Secret resources for simple password scenarios. Validation logic ensures that exactly one password source (literal password or passwordSecretRef) is provided and that a literal password, if used, is not empty.

Here’s how you can now configure a JKS keystore with a literal password:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-certificate
  namespace: default
spec:
  secretName: my-certificate-secret
  commonName: example.com
  issuerRef:
    name: my-issuer
    kind: Issuer
  keystores:
    jks:
      create: true
      password: "my-super-secret-password"
      alias: "my-cert-alias"
    pkcs12:
      create: true
      password: "another-secret"
      profile: "Modern2023"

Source:

  • deploy/crds/crd-certificates.yaml (lines 204-207,237-240)

  • internal/apis/certmanager/types_certificate.go (lines 414-417,467-470)

  • pkg/apis/certmanager/v1/types_certificate.go (lines 472-475,524-527)

  • internal/apis/certmanager/validation/certificate.go (lines 197,376-407)

  • pkg/controller/certificates/issuing/internal/secret.go (lines 262-277,307-321)

🤝 CA Injector Merging for Webhook & API Service Bundles

To improve the reliability and flexibility of CA bundle updates, cert-manager v1.17.0 introduces a new alpha feature that allows the CA injector to merge certificates into existing bundles, rather than replacing them entirely. This is a significant enhancement for ensuring continuous operation, especially when multiple sources might contribute to a CA bundle or during certificate rotations, preventing temporary service disruptions by intelligently adding new CA certificates while retaining older, still-valid ones.

Controlled by the CAInjectorMerging alpha feature gate (defaulting to false), this functionality modifies how CA bundles are managed in validating/mutating webhooks, API services, and CRD conversion webhooks. When enabled, instead of overwriting the caBundle field, the injector will append new certificates to the existing bundle, ensuring that all valid CAs are present. A new internal utility, cainjectorbundle.AppendCertificatesToBundle, handles the merging logic, which also deduplicates certificates and removes any expired ones, keeping the bundle clean and efficient. This makes the injection process more resilient to eventual consistency issues and transient errors in CA provisioning.

To enable this alpha feature, you would set the following in your controller configuration:

featureGates:
  CAInjectorMerging: true

Source:

  • internal/cainjector/feature/features.go (lines 46-51,60)

  • internal/cainjector/bundle/bundle.go (lines 1-81)

  • pkg/controller/cainjector/injectables.go (lines 110-120,145-155,179-190,211-222)

🗺️ Enhanced Azure DNS Managed Identity with Tenant ID

For users leveraging Azure DNS for ACME DNS01 challenges, cert-manager v1.17.0 introduces greater flexibility in configuring Managed Identity authentication. You can now specify an explicit tenantID alongside your Managed Identity configuration, which is particularly beneficial in complex Azure environments, such as multi-tenant setups or when Managed Identities are defined across different tenants. This update streamlines authentication by allowing precise targeting of the Azure AD tenant for identity resolution.

The AzureManagedIdentity object within the ACME Issuer and ClusterIssuer specs now includes an optional tenantID field. This enables specifying the Azure Active Directory tenant ID, which helps in scenarios where the managed identity might exist in a different tenant than the resource group or subscription. Importantly, validation rules ensure that tenantID cannot be used simultaneously with resourceID, and clientID remains a required field when tenantID is specified to ensure correct identity resolution.

Example configuration in your Issuer manifest:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: my-azuredns-issuer
spec:
  acme:
    # ... (other ACME config)
    solvers:
    - dns01:
        azureDNS:
          resourceGroupName: my-resource-group
          subscriptionID: <your-subscription-id>
          managedIdentity:
            clientID: <your-client-id>
            tenantID: <your-tenant-id>

Source:

  • deploy/crds/crd-challenges.yaml (lines 287-290)

  • deploy/crds/crd-clusterissuers.yaml (lines 394-397)

  • deploy/crds/crd-issuers.yaml (lines 394-397)

  • internal/apis/acme/types_issuer.go (lines 596)

  • internal/apis/acme/v1/zz_generated.conversion.go (lines 1392,1403)

  • internal/apis/certmanager/validation/issuer.go (lines 472-478)

  • pkg/apis/acme/v1/types_issuer.go (lines 710-713)

  • pkg/issuer/acme/dns/azuredns/azuredns.go (lines 110-112)

🐛 Improved ACME HTTP-01 Challenge Solver for IPv6

Cert-manager v1.17.0 addresses an important edge case for ACME HTTP-01 challenges, particularly in IPv6 environments, by enhancing the robustness of its challenge solver. Previously, the HTTP-01 solver might have struggled with certain IPv6 address formats when parsing hostnames from incoming requests. This improvement ensures accurate host extraction, guaranteeing that ACME challenges are reliably resolved for services running on IPv6 addresses, leading to smoother certificate issuance and renewal.

The HTTP01Solver now includes a more resilient parseHost function, which correctly extracts the hostname from request Host headers, including those containing IPv6 addresses (e.g., [::1]:8080). This refined parsing logic prevents potential failures during ACME validation for services exposed via IPv6, ensuring the solver correctly identifies the target domain. This fix directly impacts the acmesolver component, providing greater compatibility for modern network configurations and preventing validation errors due to incorrect host resolution.

Example of affected HTTP request host parsing:

func parseHost(s string) string {
	// ip v4/v6 with port
	addrPort, err := netip.ParseAddrPort(s)
	if err == nil {
		return addrPort.Addr().String()
	}

	// ip v4/v6 without port
	addr, err := netip.ParseAddr(s)
	if err == nil {
		return addr.String()
	}

	host := strings.Split(s, ":")
	return host[0]
}

Source:

  • pkg/issuer/acme/http/solver/solver.go (lines 55-113)

  • pkg/issuer/acme/http/solver/solver_test.go (lines 1-141)

Minor Updates & Housekeeping

This release also updates cert-manager’s base Go version to 1.23, along with bumping Kubernetes client-go and API dependencies to v0.32.0. Numerous internal components, including vcert (now v5.8.0), kind images (v0.26.0), and various build tools, have been updated. Improvements include a fix for the renewBeforePercentage logic, refactored DNS validation tests, enhanced structured logging in controllers, and proper shutdown handling for informers. A new e2e test suite has been added to validate foreground deletion behavior for Certificates.