# Backlog

Deferred items surfaced during design / planning / execution that we've decided *not* to build right now but want to keep visible. Append-only — close items by marking them and moving to the "Closed" section with a link to the delivering commit/spec.

---

## Open

### BL-001 — Managed CA bundles for outbound HTTPS

**Opened:** 2026-04-19
**Surfaced by:** [Alerting design](specs/2026-04-19-alerting-design.md) — TLS trust section
**Tracking:** [gitea#137](https://gitea.siegeln.net/cameleer/cameleer-server/issues/137)
**Status:** Open

**Context.** The alerting feature introduces server → external HTTPS webhooks, which makes outbound TLS trust a cross-cutting concern (joining the existing OIDC token-exchange / JWKS fetch paths). Alerting v1 handles this with a shared `OutboundHttpClientFactory` + system config (`cameleer.server.outbound-http.trusted-ca-pem-paths`) + a per-webhook `TrustMode` override (`SYSTEM_DEFAULT` / `TRUST_ALL` / `TRUST_PATHS`). CA files in v1 are filesystem-resident, managed via deployment config — there is no in-app upload surface.

**What's deferred.**

1. **In-app CA bundle management.** Admin UI to upload, list, and delete trusted CA PEMs. Storage in PG (`trusted_ca_certs` table) so all replicas see a consistent set without a filesystem sync step. Likely lives under `/admin/outbound-http` (new admin surface) or as a tab on the existing admin navigation.

2. **SaaS-layer CA reuse — design investigation (do first).** The SaaS layer already manages CA material for the server (for its reverse-proxy → OIDC path and related). Before building in-app CA management in the OSS server, investigate whether the SaaS CA mechanism can be extended/exposed so the server can consume trust material from the SaaS layer directly. Goal: KISS + DRY — don't duplicate a CA store in the server if the SaaS side already owns one. If reuse is viable, in-app CA upload in the server may never be needed — the SaaS layer becomes the authoritative admin surface and the server just reads.

**Acceptance criteria.**
- Investigation concludes with a one-page decision: reuse SaaS / build in-server / hybrid, with rationale and an implementation sketch.
- If "build in-server" is chosen: spec + plan + implementation following the normal flow. Must include PG-backed storage, audit logging on CA change (category already introduced: `OUTBOUND_HTTP_TRUST_CHANGE`), and cluster-consistent propagation.
- If "reuse SaaS" is chosen: spec for the extension on the SaaS side + a small server-side consumer; the server's current file-path-based trust config remains as the OSS fallback for non-SaaS deployments.

**Why we're not doing it now.**
- Alerting v1's file-based trust config is identical to how the server handles other trust material today (OIDC issuer URIs, Ed25519 keys), so it's no regression.
- Building in-server CA management before the SaaS reuse investigation risks duplicating work we may throw away.
- Most early alerting users will target public SaaS webhooks (Slack, PagerDuty, Teams) whose certs chain to public roots — no custom CA needed.

**Links.**
- `cameleer-server-app/src/main/java/com/cameleer/server/app/http/` (v1 outbound HTTP module — the investigation will extend this)
- OIDC trust touch-points in `OidcProviderHelper`, `OidcTokenExchanger` (alignment reference)

---

## Closed

_(nothing yet)_