2 Commits

Author	SHA1	Message	Date
shankar0123	01f6eb9d09	feat(scep): plumb CertificateProfile.MustStaple end-to-end through service layer ... SCEP RFC 8894 + Intune master bundle Phase 5.6 follow-up. Closes the 'lying field' gap from the original Phase 5.6 commit (b33b843). That commit shipped CertificateProfile.MustStaple as a domain field + IssuanceRequest.MustStaple as the issuer-interface field + the local issuer's RFC 7633 extension generation + byte-exact tests against the spec — but the service layer (SCEP + EST + agent + renewal) never read profile.MustStaple and never set IssuanceRequest.MustStaple. Operators who set the field got: a stored value, an API that returned it, docs that promised it worked, and a cert with no extension. Worse than not having the field at all. Per the new operating rule landed in cowork/CLAUDE.md::Operating Rules ('Always take the complete path, not the easy path'), this commit closes the wire end-to-end. internal/service/renewal.go * IssuerConnector interface signature gains a mustStaple bool param on IssueCertificate + RenewCertificate. The original 'this is a wider refactor' framing was overstated — it's one extra arg threaded through six call sites, not a structural change. internal/service/issuer_adapter.go * IssuerConnectorAdapter.IssueCertificate + RenewCertificate accept the new param + populate IssuanceRequest.MustStaple / RenewalRequest.MustStaple. Connectors that don't honor extension injection (Vault, EJBCA, ACME, etc.) silently ignore the field — the Phase 5.6 commit's docblock already noted this. internal/service/scep.go * processEnrollment now reads profile.MustStaple alongside profile.MaxTTLSeconds and threads it through the IssueCertificate call. The SCEP path was the load-bearing one — the original Phase 5.6 docs example showed exactly this code shape but the wire was never landed. internal/service/est.go * Same pattern as SCEP: read profile.MustStaple + thread to IssueCertificate. Defense in depth so a deploy that mounts the same profile across SCEP + EST gets consistent extension behavior. internal/service/agent.go * The fallback direct-issuer signing path in heartbeatPipeline reads profile + threads MustStaple through. Server-mode keygen + ad-hoc CSR submission paths both go through this. internal/service/renewal.go (the renewal-loop side, not the interface) * Both renewal call sites (server-CSR-generated + agent-CSR-submitted) read profile.MustStaple + thread it through RenewCertificate. Renewed certs match their initial-issuance extension set when the bound profile changes mid-lifetime. internal/service/scep_must_staple_test.go (new) * TestSCEPService_PKCSReq_PlumbsMustStapleToIssuer — end-to-end integration test: profile.MustStaple=true → SCEP service → mock IssuerConnector saw mustStaple=true. This is the test the original Phase 5.6 commit should have shipped — proves the wire reaches the connector. * TestSCEPService_PKCSReq_NoMustStaplePropagatesFalse — companion pinning the symmetric contract; the mock pre-sets LastMustStaple=true so a stuck-at-true bug surfaces. internal/service/testutil_test.go + internal/service/m11c_crypto_enforcement_test.go + internal/service/issuer_adapter_test.go + cmd/server/preflight_test.go * Mock + fake IssuerConnector implementations gain the new mustStaple bool param. mockIssuerConnector + capturingIssuerConnector also gain a LastMustStaple / lastMustStaple field used by the new integration tests to assert the wire reached the connector. * Existing test call sites for adapter.IssueCertificate / adapter.RenewCertificate gain a trailing 'false' arg (mechanical bulk edit, no behavior change). Verification: * gofmt + go vet + staticcheck clean for all touched paths. * go test -short -count=1 green across cmd/agent / cmd/cli / cmd/mcp-server / cmd/server / api/handler / api/middleware / api/router / service / scheduler / pkcs7 / connector/issuer/local / every connector subpackage / domain / crypto / mcp / repository. * The new TestSCEPService_PKCSReq_PlumbsMustStapleToIssuer test passes, proving the wire works end-to-end. The follow-up rule from cowork/CLAUDE.md::Operating Rules — 'can an operator flip the configurable bit and observe the behavior change end-to-end with no further code changes?' — is now YES for must-staple on the SCEP + EST + agent + renewal paths.	2026-04-29 13:36:30 +00:00
shankar0123	1c099071d1	fix(bundle-4): EST/SCEP Attack Surface Hardening — 3 audit findings closed ... Closes 3 findings (1 High + 1 Medium + 1 Low) from /Users/shankar/Desktop/cowork/comprehensive-audit-2026-04-25/. Bundle 4 hardens the only attack surface reachable by an anonymous network attacker in certctl: the unauthenticated EST + SCEP enrollment endpoints. Findings closed: - H-004 (High): Hand-rolled ASN.1 parser had no fuzz target. The audit's original framing pointed at internal/pkcs7/, but recon confirmed that package is an ASN.1 ENCODER (BuildCertsOnlyPKCS7, ASN1Wrap*, ASN1EncodeLength) — not a parser. The actual hand-rolled PKCS#7 PARSING reachable via anonymous network is in internal/api/handler/scep.go::extractCSRFromPKCS7 + parseSignedDataForCSR. Added native go fuzz targets: * internal/api/handler/scep_fuzz_test.go::FuzzExtractCSRFromPKCS7 * internal/api/handler/scep_fuzz_test.go::FuzzParseSignedDataForCSR * internal/pkcs7/pkcs7_fuzz_test.go::FuzzPEMToDERChain (defense-in-depth) * internal/pkcs7/pkcs7_fuzz_test.go::FuzzASN1EncodeLength (defense-in-depth) Local 15s fuzz session: 150k execs on FuzzExtractCSRFromPKCS7, 937k on FuzzPEMToDERChain, 925k on FuzzASN1EncodeLength — zero panics. - M-021 (Medium): EST TLS-Unique channel binding (RFC 7030 §3.2.3). Added internal/api/handler/est.go::verifyESTTransport — defense-in-depth TLS pre-conditions (r.TLS != nil; HandshakeComplete; TLS ≥ 1.2). The full §3.2.3 channel binding only applies when EST mTLS is in use; certctl does not currently support EST mTLS, so the §3.2.3 requirement is moot today. RFC 9266 (TLS 1.3 tls-exporter) and EST mTLS are documented as deferred follow-ups in the verifyESTTransport doc comment. - L-005 (Low): EST/SCEP issuer-binding fail-loud at startup. Pre-Bundle-4 cmd/server/main.go validated that CERTCTL_EST_ISSUER_ID and CERTCTL_SCEP_ISSUER_ID existed in the registry but did NOT validate the issuer TYPE could emit a CA cert. An operator binding EST to an ACME issuer (whose GetCACertPEM returns explicit error) booted successfully and only failed at first /est/cacerts request. Post-Bundle-4: new preflightEnrollmentIssuer helper calls GetCACertPEM(ctx) at startup with a 10s timeout. Failure logs the connector error + the candidate issuer types and os.Exit(1). Tests added/modified: - internal/api/handler/est_transport_test.go (new) — 5 verifyESTTransport table cases covering plaintext-rejected, incomplete-handshake-rejected, TLS 1.0 rejected, TLS 1.2/1.3 accepted - cmd/server/preflight_test.go (new) — TestPreflightEnrollmentIssuer covering nil-connector, error-from-issuer, empty-PEM, valid cases - internal/api/handler/est_handler_test.go (modified) — 7 POST sites now stamp r.TLS to satisfy the new transport pre-condition - internal/integration/negative_test.go (modified) — setupTestServer wraps the test handler with a fake-TLS-state injector so the EST handler receives r.TLS != nil; production paths still rely on the real TLS listener Threat model reference: TB-11 (EST/SCEP client ↔ Server) per cowork/comprehensive-audit-2026-04-25/threat-model.md. Standards: RFC 7030 §3.2.3, RFC 8894 §3, RFC 5652, RFC 9266 (deferred).	2026-04-25 21:14:41 +00:00