Managed CA bundles for outbound HTTPS (deferred from alerting v1) #137

New Issue

claude · 2026-04-19T14:32:20+02:00

claude commented

2026-04-19 14:32:20 +02:00

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. SaaS-layer CA reuse — design investigation (do first)

The SaaS layer already manages CA material for the server (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.

2. In-app CA bundle management (only if reuse isn't viable)

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.

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

Alerting design spec (to be committed): docs/superpowers/specs/2026-04-19-alerting-design.md
Local backlog entry: docs/superpowers/backlog.md → BL-001
v1 outbound HTTP module (the investigation will extend this): cameleer-server-app/src/main/java/com/cameleer/server/app/http/
OIDC trust touch-points (alignment reference): OidcProviderHelper, OidcTokenExchanger

## 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. SaaS-layer CA reuse — design investigation (do first) The SaaS layer already manages CA material for the server (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. ### 2. In-app CA bundle management (only if reuse isn't viable) 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. ## 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 - Alerting design spec (to be committed): `docs/superpowers/specs/2026-04-19-alerting-design.md` - Local backlog entry: `docs/superpowers/backlog.md` → BL-001 - v1 outbound HTTP module (the investigation will extend this): `cameleer-server-app/src/main/java/com/cameleer/server/app/http/` - OIDC trust touch-points (alignment reference): `OidcProviderHelper`, `OidcTokenExchanger`

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: cameleer/cameleer-server#137