Skip to content

[platform] Add wildcard certificate support for multi-tenant deployments #2400

Description

@myasnikovdaniil

What this issue is about

Currently, all TLS certificates in Cozystack are issued per-hostname via cert-manager ingress annotations. Each tenant endpoint (e.g. s3.tenant-a.example.org, app.tenant-b.example.org) gets its own individual certificate from Let's Encrypt.

This approach hits Let's Encrypt rate limits (50 certificates per registered domain per week) once the platform exceeds ~50 tenant endpoints, making it unsuitable for production multi-tenant deployments at scale.

Current limitations

  1. No wildcard Certificate resources — no mechanism to create *.tenants.example.org or *.s3.example.org certs
  2. Ingress annotations = one cert per hostname — cert-manager issues individual certs per Ingress, never wildcards
  3. dns01 solver is Cloudflare-only — hardcoded in cert-manager-issuers templates, other DNS providers not supported
  4. http01 is the default solver — which cannot issue wildcard certs at all

Proposed solution

Add a platform-level wildcard certificate mode. Example configuration in platform values.yaml:

publishing:
  certificates:
    solver: dns01
    wildcardDomains:
      - "*.tenants.example.org"
      - "*.s3.example.org"

Implementation would involve:

  1. Standalone wildcard Certificate CRs — platform package creates Certificate resources for each wildcard domain, storing the resulting TLS secret
  2. Ingress references shared secret — instead of per-host cert-manager annotations, ingress resources reference the pre-existing wildcard TLS secret
  3. Generalize dns01 provider — support at least Cloudflare, Route53, and cert-manager webhook-based solvers (not just hardcoded Cloudflare)
  4. Hybrid mode — wildcard certs for platform-generated subdomains, individual certs for tenant custom domains (which are under different registered domains and have their own rate limit quota)

Impact

  • Removes Let's Encrypt rate limit bottleneck for platforms with many tenants
  • Reduces total number of certificates to manage (fewer renewals, less ACME traffic)
  • Required for production deployments expecting 50+ tenant endpoints per week

Release note

Add optional wildcard certificate support via dns01 solver for multi-tenant deployments at scale.

Activity

  1. added
    area/networkingIssues or PRs related to networking (ingress, gateway, vpn, metallb, kube-ovn)
    area/platformIssues or PRs related to platform infrastructure (bundle, flux, talos, installer)
    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
    on Jun 3, 2026
  2. lexfrei commented on Jun 3, 2026

    @lexfrei
    Contributor

    Tracked under epic #2811 as the ingress wildcard workstream, and kept as the canonical issue for it.

    Two premises here have shifted since filing, worth updating:

    • The dns01 solver is no longer Cloudflare-only — packages/system/cert-manager-issuers/templates/cluster-issuers.yaml:40-85 now supports cloudflare, route53, digitalocean and rfc2136.
    • Wildcard Certificate resources already exist on the Gateway API path: in dns01 mode the TenantGateway controller renders a per-apex wildcard (internal/controller/tenantgateway/renderers.go:368-426). The remaining gap is the default ingress-nginx path (gateway.enabled defaults to false, packages/core/platform/templates/apps.yaml:80), where every published hostname still mints its own per-host certificate via ingress-shim.

    So the scope that remains here is: bring the same wildcard-backed issuance to the ingress-nginx path. The bring-your-own (externally-issued / purchased) wildcard case is tracked separately as #2812.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

area/networkingIssues or PRs related to networking (ingress, gateway, vpn, metallb, kube-ovn)area/platformIssues or PRs related to platform infrastructure (bundle, flux, talos, installer)kind/featureCategorizes issue or PR as related to a new featurepriority/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

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions