2 Commits

Author	SHA1	Message	Date
shankar0123	a12a437664	feat(scep): mTLS sibling route /scep-mtls/<pathID> (opt-in) ... SCEP RFC 8894 + Intune master bundle — Phase 6.5 of 14 (opt-in, enterprise-procurement-checkbox). Closes the procurement-team objection that 'shared password authentication' is a checkbox-fail regardless of how strong the password is. The clean answer: a sibling route that adds client-cert auth at the handler layer AND keeps the challenge password (defense in depth, not replacement). Devices present a bootstrap cert from a trusted CA (e.g. a manufacturing-time cert), then SCEP-enroll for their long-lived cert. Same model Apple's MDM and Cisco's BRSKI use. internal/config/config.go * SCEPProfileConfig gains MTLSEnabled bool + MTLSClientCATrustBundlePath string. Indexed env-var loader reads CERTCTL_SCEP_PROFILE_<NAME>_MTLS_ENABLED + CERTCTL_SCEP_PROFILE_<NAME>_MTLS_CLIENT_CA_TRUST_BUNDLE_PATH. * Validate() refuses MTLSEnabled=true with empty bundle path — structural defense in depth ahead of the file-content preflight. cmd/server/main.go * preflightSCEPMTLSTrustBundle: file existence + PEM parse + ≥1 CERTIFICATE block + non-expired check. Returns the parsed *x509.CertPool ready to inject into the per-profile SCEPHandler. Failures os.Exit(1) with the offending PathID in the structured log. * SCEP startup loop walks each profile; when MTLSEnabled, runs preflight, builds the per-profile pool, contributes the bundle's certs to the union pool that backs the TLS-layer VerifyClientCertIfGiven, clones the SCEPHandler with SetMTLSTrustPool, and registers the parallel sibling route via apiRouter.RegisterSCEPMTLSHandlers. * Union pool published to outer scope as scepMTLSUnionPoolForTLS; passed to buildServerTLSConfigWithMTLS so the listener serves both /scep[/<pathID>] (no client cert) and /scep-mtls/<pathID> (cert required at handler layer) on the same socket. * Final-handler dispatch gains /scep-mtls + /scep-mtls/* prefix routing through the no-auth chain (auth boundary is the client cert + challenge password, NOT a Bearer token). cmd/server/tls.go * New buildServerTLSConfigWithMTLS that wraps buildServerTLSConfig + sets ClientCAs + ClientAuth=VerifyClientCertIfGiven when a non-nil pool is passed. nil pool = identical TLS shape to the pre-Phase-6.5 builder (no behavior change for deploys without mTLS profiles). * Critical: VerifyClientCertIfGiven (NOT RequireAndVerifyClientCert) so a client that doesn't present a cert can still hit the standard /scep route. The per-profile gate at the handler layer enforces 'cert required' on /scep-mtls/<pathID>. internal/api/handler/scep.go * SCEPHandler gains mtlsTrustPool *x509.CertPool field + SetMTLSTrustPool method. Per-profile pool injected by cmd/server/main.go after preflight. * HandleSCEPMTLS wrapper: gates on r.TLS.PeerCertificates non-empty + per-profile cert.Verify against THIS profile's pool. Returns HTTP 401 for missing/untrusted cert (mTLS failure is auth, not authorization). Returns HTTP 500 if mtlsTrustPool is nil (deploy bug — the route shouldn't have been registered). On success delegates to HandleSCEP — defense in depth: mTLS is additive, NOT replacement; the standard SCEP code path including the challenge-password gate still executes. * Per-profile re-verification via cert.Verify(...) is critical: the TLS layer verified against the UNION pool, so a cert that chains to profile A's bundle would pass TLS even when targeting profile B. The handler-layer gate prevents cross-profile bleed-through. internal/api/router/router.go * AuthExemptDispatchPrefixes gains '/scep-mtls' (auth boundary is client cert + challenge password, NOT Bearer token). * RegisterSCEPMTLSHandlers parallel to RegisterSCEPHandlers: empty PathID maps to /scep-mtls root; non-empty maps to /scep-mtls/<pathID>. Each handler in the map MUST have had SetMTLSTrustPool called. internal/api/router/openapi_parity_test.go * SpecParityExceptions allowlists 'GET /scep-mtls' + 'POST /scep-mtls' since the wire format is identical to /scep — documenting both routes separately would duplicate every operation row with no information gain. Documented alternative in docs/legacy-est-scep.md. internal/api/handler/scep_mtls_test.go (new, ~210 LoC) * 6 tests + 2 helpers covering the auth contract: 1. RejectsMissingClientCert — request with r.TLS=nil → 401 2. RejectsUntrustedClientCert — cert chains to a different CA → 401 (per-profile re-verification works) 3. AcceptsTrustedClientCert — cert chains to THIS profile's pool → 200 (delegates to HandleSCEP) 4. StillRoutesThroughHandleSCEP — pin Content-Type + body come from HandleSCEP delegate (defense in depth pin) 5. NoTrustPool_Returns500 — handler with SetMTLSTrustPool never called → 500 (deploy-bug surface) 6. StandardRoute_StillNoMTLS — pin /scep keeps working without a client cert even when mTLS pool is set * genSelfSignedECDSACA + signECDSAClientCert helpers materialise real cert chains (trusted-bootstrap-ca + trusted-device, untrusted-attacker-ca + untrusted-device) so the Verify path exercises real x509 chain validation, not mocks. docs/features.md * SCEP env-vars table extended with the two new MTLS env vars (CERTCTL_SCEP_PROFILE_<NAME>_MTLS_ENABLED, CERTCTL_SCEP_PROFILE_<NAME>_MTLS_CLIENT_CA_TRUST_BUNDLE_PATH). Closes the G-3 'env var defined in Go but never documented' gate. docs/legacy-est-scep.md * New 'mTLS sibling route (Phase 6.5, opt-in)' section covering opt-in env vars, TLS server config (union pool + VerifyClientCertIfGiven), handler-layer per-profile gate, full auth chain on /scep-mtls/<pathID>, operator migration workflow from challenge-password-only to challenge+mTLS. cowork/CLAUDE.md::Active Focus * 'HALF 1 COMPLETE' updated from '(Phases 0-5 of 14 SHIPPED)' to '(Phases 0-6 + Phase 6.5 of 14 SHIPPED)'. Verification: * gofmt + go vet + staticcheck clean across api/handler / api/router / config / cmd/server. * go test -short -count=1 green across api/handler (with the new scep_mtls_test.go) / api/router / service / config / pkcs7 / cmd/server / connector/issuer/local. * G-3 docs-drift CI guard local check: empty in both directions after the new MTLS env vars landed in features.md. * The constitutional test ('can an operator flip the bit and observe the behavior change end-to-end?') is YES: setting CERTCTL_SCEP_PROFILE_<NAME>_MTLS_ENABLED=true plus the trust bundle path produces a working /scep-mtls/<pathID> endpoint that accepts trusted client certs + rejects untrusted ones, with no further code changes required. Phase 6.5 of 14 in SCEP RFC 8894 + Intune master bundle. Half 1 (Phases 0-6 + 6.5) is now FEATURE-COMPLETE for the ChromeOS / general-MDM use case. Half 2 (Phases 7-12) adds the Microsoft Intune dynamic-challenge layer.	2026-04-29 13:58:18 +00:00
shankar0123	52248be717	v2.0.47: HTTPS Everywhere — TLS-only control plane, agents/CLI/MCP ... Breaking change release. Plaintext HTTP listener removed. The certctl control plane now terminates TLS 1.3 on :8443 via http.Server.ListenAndServeTLS. No CERTCTL_TLS_ENABLED=false escape hatch. No dual-listener mode. One-step cutover per docs/upgrade-to-tls.md. Server - cmd/server/tls.go: certHolder with SIGHUP hot-reload + atomic cert swap, buildServerTLSConfig (TLS 1.3 min, GetCertificate callback), preflightServerTLS validation - cmd/server/main.go: ListenAndServeTLS in place of ListenAndServe, watchSIGHUP wiring, cert/key path config threading - tls_test.go: 418-line regression coverage of reload, preflight, callback behavior, SAN validation Config - CERTCTL_TLS_CERT_PATH / CERTCTL_TLS_KEY_PATH (required) - Plaintext rejection: agents/CLI/MCP pre-flight-fail on http:// URLs with a pointer to docs/upgrade-to-tls.md Agents, CLI, MCP - All three pre-flight-reject http:// URLs with fail-loud diagnostic - CERTCTL_SERVER_CA_BUNDLE_PATH for private-CA trust - CERTCTL_SERVER_TLS_INSECURE_SKIP_VERIFY for dev-only bypass (loud warning on startup) - install-agent.sh emits both vars as commented template lines docker-compose - certctl-tls-init sidecar generates SAN-valid self-signed cert into deploy/test/certs/ on first boot - All demo-stack curls pin against ca.crt with --cacert Helm chart - Three TLS provisioning modes, exactly one required: - server.tls.existingSecret (operator-supplied) - server.tls.certManager.enabled (cert-manager integration) - server.tls.selfSigned.enabled (eval only — not for production) - server-certificate.yaml template for cert-manager mode - helm install without a TLS source fails at template render with a pointer to docs/tls.md CI - .github/workflows/ci.yml Helm Chart Validation step renders the chart in both existingSecret and cert-manager modes, plus an inverse guard-regression test that asserts helm template MUST refuse to render when no TLS source is configured. Previously the single `helm template` invocation hit the certctl.tls.required fail-loud guard and exit-1'd CI. Four invocations now: lint (existingSecret), template (existingSecret), template (cert-manager), template (no args — must fail). Integration tests - deploy/test/integration_test.go stands up the Compose stack over HTTPS, extracts the CA bundle, and exercises every certctl API over https://localhost:8443 - All 34 integration subtests green (per Phase 8 local CI-parity) Documentation - New: docs/tls.md (provisioning patterns, rotation, SIGHUP reload) - New: docs/upgrade-to-tls.md (one-step cutover, no-downgrade warnings, fleet-roll sequencing) - CHANGELOG.md: v2.2.0 "HTTPS Everywhere — The Irony" entry (file heading unchanged; release tag is v2.0.47) - All curls in docs/, examples/, deploy/helm/ guides use https://localhost:8443 --cacert Verification - grep -rn "ListenAndServe[^T]" cmd/ internal/ → 0 hits - grep -rn "\"http://" cmd/ internal/ → 2 benign hits (Caddy admin API default, SSRF doc comment) — zero certctl endpoints - Tasks #197–#206 (Phases 0–8) all closed in the tracker Files: 65 changed, 3489 insertions, 372 deletions (pre-CI-fix).	2026-04-20 03:43:10 +00:00