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.

internal/api/handler/scep.go

@@ -74,6 +74,13 @@ type SCEPHandler struct {
 	svc    SCEPService
 	raCert *x509.Certificate // RFC 8894 path: RA cert clients encrypt CSR to
 	raKey  crypto.PrivateKey // RFC 8894 path: RA key for EnvelopedData decrypt + CertRep signing
+
+	// SCEP RFC 8894 + Intune master bundle Phase 6.5: per-profile mTLS
+	// trust bundle. When set, HandleSCEPMTLS verifies the inbound client
+	// cert chain against this pool. Nil when the profile has MTLSEnabled=false
+	// — HandleSCEPMTLS rejects unconditionally in that case (the route
+	// shouldn't even be registered, but defense in depth).
+	mtlsTrustPool *x509.CertPool
 }
 
 // NewSCEPHandler creates a new SCEPHandler with the legacy MVP-only behavior.
@@ -91,6 +98,75 @@ func (h *SCEPHandler) SetRAPair(raCert *x509.Certificate, raKey crypto.PrivateKe
 	h.raKey = raKey
 }
 
+// SetMTLSTrustPool injects the per-profile client-cert trust pool the
+// `/scep-mtls/<PathID>` sibling route uses to verify inbound device
+// bootstrap certs. SCEP RFC 8894 + Intune master bundle Phase 6.5.
+//
+// The TLS layer (cmd/server/main.go::buildServerTLSConfig) uses
+// VerifyClientCertIfGiven against the UNION of every enabled mTLS
+// profile's bundle, so the same TLS listener serves both /scep
+// (challenge-password-only) and /scep-mtls/<PathID> (cert + challenge).
+// The per-profile gate at the handler layer enforces 'cert must chain to
+// THIS profile's bundle' so a cert that chains to profile A's bundle
+// cannot enroll against profile B even though it passed the TLS layer.
+func (h *SCEPHandler) SetMTLSTrustPool(pool *x509.CertPool) {
+	h.mtlsTrustPool = pool
+}
+
+// HandleSCEPMTLS is the entry point for the `/scep-mtls/<PathID>` sibling
+// route. SCEP RFC 8894 + Intune master bundle Phase 6.5.
+//
+// Gates on the inbound client cert chain — the request must:
+//
+//  1. Carry a TLS connection (r.TLS != nil) — defense in depth even
+//     though the HTTPS-only listener guarantees this.
+//  2. Have presented a peer cert (len(r.TLS.PeerCertificates) > 0) — the
+//     listener uses VerifyClientCertIfGiven, so a missing cert is a
+//     legitimate failure here, not a TLS error.
+//  3. The peer cert chain must verify against THIS profile's trust pool
+//     (h.mtlsTrustPool). The TLS layer verified against the union pool
+//     of all mTLS profiles, but a cert that chains to profile A cannot
+//     enroll against profile B — verify per-profile here.
+//
+// Failures return HTTP 401 (Unauthorized — mTLS failure is authentication,
+// not authorization). On success the call delegates to HandleSCEP — the
+// challenge-password gate still fires (defense in depth: mTLS is additive,
+// not replacement).
+func (h SCEPHandler) HandleSCEPMTLS(w http.ResponseWriter, r *http.Request) {
+	if h.mtlsTrustPool == nil {
+		// Profile is misconfigured — handler registered for /scep-mtls but
+		// SetMTLSTrustPool was never called. The startup preflight should
+		// have caught this; surfacing as 500 makes the deploy bug loud.
+		ErrorWithRequestID(w, http.StatusInternalServerError, "mTLS handler missing trust pool", middleware.GetRequestID(r.Context()))
+		return
+	}
+	if r.TLS == nil || len(r.TLS.PeerCertificates) == 0 {
+		// Client didn't present a cert. With VerifyClientCertIfGiven the
+		// TLS handshake completes anyway — the per-profile gate enforces
+		// 'cert required' at the application layer.
+		ErrorWithRequestID(w, http.StatusUnauthorized, "Client certificate required for /scep-mtls", middleware.GetRequestID(r.Context()))
+		return
+	}
+	leaf := r.TLS.PeerCertificates[0]
+	intermediates := x509.NewCertPool()
+	for _, c := range r.TLS.PeerCertificates[1:] {
+		intermediates.AddCert(c)
+	}
+	if _, err := leaf.Verify(x509.VerifyOptions{
+		Roots:         h.mtlsTrustPool,
+		Intermediates: intermediates,
+		KeyUsages:     []x509.ExtKeyUsage{x509.ExtKeyUsageClientAuth, x509.ExtKeyUsageAny},
+	}); err != nil {
+		ErrorWithRequestID(w, http.StatusUnauthorized, "Client certificate not trusted by this profile", middleware.GetRequestID(r.Context()))
+		return
+	}
+	// Defense in depth — mTLS is ADDITIVE. The request still flows through
+	// HandleSCEP which enforces the challenge-password gate at the service
+	// layer. A stolen device cert without the matching challenge password
+	// still gets rejected (and vice versa).
+	h.HandleSCEP(w, r)
+}
+
 // HandleSCEP is the single entry point for all SCEP operations.
 // It dispatches based on the "operation" query parameter.
 func (h SCEPHandler) HandleSCEP(w http.ResponseWriter, r *http.Request) {