Skip to content

cert-manager is started without --enable-gateway-api=true when gateway is enabled on platform and tenant level #3725

Closed

Description

@crossRT

Describe the bug
When gateway api is enabled on platform and tenant level, the cert-manager is not started with --enable-gateway-api=true, causing the acme http challenge process failed.

Environment

  • Cozystack version: v1.6.1
  • Provider: on-prem

To Reproduce
Steps to reproduce the behavior:

  1. Freshly install cozystack v1.6.1
  2. setup and configure the platform as documentation mentioned, but keep .spec.ingress: false in tenant-root
  3. enable gateway on platform level and tenant level as documentation mentioned.
  4. wait for all gateway related resources reconciled.
  5. check the certs for dashboard and bucket-cozy-backups-ui.

Expected behaviour
The acme challenge should complete successfully and the certificates become valid.

Actual behaviour
The certificates never become valid.

Logs

E0809 03:21:03.651853       1 controller.go:155] "re-queuing item due to error processing" err="couldn't Present challenge tenant-root/cozystack-xxxxxx-655084b1-tls-1-3139820371-2206439728: gateway api is not enabled" logger="cert-manager.controller"

Checklist

  • I have checked the documentation
  • I have searched for similar issues
  • I have included all required information
  • I have provided clear steps to reproduce
  • I have included relevant logs

Activity

  1. dosubot commented on Aug 10, 2026

    @dosubot

    This looks like a valid bug. The cert-manager deployment in Cozystack (v1.20.2) does not explicitly enable Gateway API support — featureGates is set to an empty string and config is {}, so neither --enable-gateway-api nor enableGatewayAPI in the controller config is being passed [1] [2]. There are also no overrides in the wrapper chart's values.yaml [3].

    The error you're seeing — gateway api is not enabled — confirms cert-manager doesn't know it should use Gateway API HTTPRoutes for the HTTP-01 ACME challenge solver.

    The fix would be to set enableGatewayAPI: true in cert-manager's controller configuration. In Cozystack's chart structure, this would go in packages/system/cert-manager/values.yaml under the cert-manager key, something like:

    cert-manager:
      config:
        apiVersion: controller.config.cert-manager.io/v1alpha1
        kind: ControllerConfiguration
        enableGatewayAPI: true

    This config gets rendered into a ConfigMap and mounted into the controller via --config [4] [5].

    Ideally this should be conditionally enabled based on whether gateway.enabled: true is set in the platform values, since the Gateway API CRDs may not be present when gateway is disabled.

    To reply, just mention @dosu.


    Share context across your team and agents. Try Dosu.

    Leave Feedback Learn about cozystack with Dosu Add Dosu to your team

  2. lexfrei commented on Aug 14, 2026

    @lexfrei
    Contributor

    Confirmed, and the two halves of this already disagree in the tree.

    packages/system/cert-manager-issuers/templates/cluster-issuers.yaml renders http01.gatewayHTTPRoute with a parentRef to the cozystack Gateway whenever gateway-enabled is true, so the ClusterIssuer does ask for the Gateway solver. The controller then refuses it, because packages/system/cert-manager/values.yaml sets no config block and --enable-gateway-api is off by default. That produces the couldn't Present challenge ...: gateway api is not enabled line on every challenge for as long as the Gateway is enabled.

    The fix is small:

    cert-manager:
      config:
        apiVersion: controller.config.cert-manager.io/v1alpha1
        kind: ControllerConfiguration
        enableGatewayAPI: true

    Enabling it unconditionally is safe. The controller only needs the Gateway API CRDs to exist at startup, and cozystack.cert-manager already declares dependsOn: cozystack.gateway-api-crds in the platform sources, so they land first in every variant that ships cert-manager.

  3. lexfrei commented on Sep 2, 2026

    @lexfrei
    Contributor

    Correction to my note above: the config block must not become a default of system/cert-manager. The same chart is installed into tenant Kubernetes clusters, where the Gateway API CRDs are an opt-in addon, and cert-manager v1.20 fails to start when the flag is on and the CRDs are missing (buildClients in pkg/controller/context.go returns an error on purpose). #4039 threads the flag from the platform bundle into the host cert-manager instead, the same way the tenant addon already does it under addons.gatewayAPI.enabled.

  4. added
    area/networkingIssues or PRs related to networking (ingress, gateway, vpn, metallb, kube-ovn)
    triage/acceptedIndicates an issue is ready to be actively worked on
    priority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next release
    and removed
    triage/needs-triageIndicates an issue needs triage by a maintainer
    on Sep 23, 2026
  5. added a commit that references this issue on Oct 7, 2026
    0a2bb5e
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/networkingIssues or PRs related to networking (ingress, gateway, vpn, metallb, kube-ovn)kind/bugCategorizes issue or PR as related to a bugpriority/important-soonMust be staffed and worked on either currently, or very soon, ideally in time for the next releasetriage/acceptedIndicates an issue is ready to be actively worked on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions