3 Commits

Author	SHA1	Message	Date
certctl-copilot	35fcfa70f2	feat(scep): RenewalReq + GetCertInitial + ChromeOS E2E + caps + must-staple ... SCEP RFC 8894 + Intune master bundle — Phase 4 + Phase 5 of 14. Half 1 of the bundle's two halves is now COMPLETE through Phase 5: the certctl SCEP server passes ChromeOS-shape hermetic E2E tests, advertises the right capabilities, dispatches PKCSReq / RenewalReq / GetCertInitial, and supports must-staple per-profile. == Phase 4: RenewalReq + GetCertInitial wiring ============================ internal/service/scep.go * RenewalReqWithEnvelope (RFC 8894 §3.3.1.2) — re-enrollment with an existing valid cert. Same contract as PKCSReqWithEnvelope but the service additionally verifies that envelope.SignerCert chains to the issuer's CA (verifyRenewalSignerCertChain). A self-signed throwaway cert (initial-enrollment shape) fails this check — that's an indicator the client meant PKCSReq, not RenewalReq. * GetCertInitialWithEnvelope (RFC 8894 §3.3.3) — polling stub. Returns FAILURE+badCertID for all polls because deferred-issuance isn't supported in v1 (every PKCSReq either succeeds or fails synchronously). Wiring stays in place for a future enhancement. * Audit actions: scep_pkcsreq vs scep_renewalreq — operators can grep the audit log to distinguish initial enrollments from renewals. internal/api/handler/scep.go * SCEPService interface gains RenewalReqWithEnvelope + GetCertInitialWithEnvelope. * pkiOperation RFC 8894 path now switches on envelope.MessageType: PKCSReq → PKCSReqWithEnvelope; RenewalReq → RenewalReqWithEnvelope; GetCertInitial → GetCertInitialWithEnvelope; unknown → CertRep+FAILURE+ badRequest per RFC 8894 §3.3.2.2. == Phase 5.1: GetCACaps capability advertisement ========================= internal/service/scep.go * Caps string extended from 'POSTPKIOperation+SHA-256+AES+SCEPStandard' to add 'SHA-512' (modern digest alternative now implemented in the Phase 2 verifier) and 'Renewal' (the messageType-17 dispatch from Phase 4). ChromeOS specifically looks for these capabilities to negotiate the strongest available cipher + digest combo. * scep_test.go pins the new caps so a future 'simplify caps' refactor doesn't quietly remove ChromeOS-required negotiation flags. == Phase 5.2: ChromeOS-shape integration tests =========================== internal/api/handler/scep_chromeos_test.go (new, ~570 LoC) * 6 hermetic E2E tests + ~12 helpers. Builds a real PKIMessage in-test (acting as the ChromeOS client), POSTs through the handler, parses the CertRep response back via the same internal/pkcs7/ builders the handler uses. * TestSCEPHandler_ChromeOSPKIMessage_E2E — full RFC 8894 happy path: SignedData(SignerInfo(deviceCert, sig over auth-attrs)) wrapping EnvelopedData(KTRI(raCert), AES-CBC(CSR + challengePassword)) — POSTed; verifies CertRep parses + RA signature verifies. * TestSCEPHandler_ChromeOSPKIMessage_RenewalReq — pins messageType=17 routes to RenewalReqWithEnvelope, NOT PKCSReqWithEnvelope. * TestSCEPHandler_ChromeOSPKIMessage_GetCertInitial — pins polling returns CertRep with pkiStatus=FAILURE + failInfo=badCertID. * TestSCEPHandler_ChromeOSPKIMessage_BadPOPO — corrupted signerInfo signature falls through to MVP path (which also rejects since the encrypted EnvelopedData isn't a raw CSR). No silent acceptance. * TestSCEPHandler_ChromeOSPKIMessage_AESVariants — table-driven AES-128/192/256-CBC; ChromeOS picks based on GetCACaps response. * TestSCEPHandler_MVPCompat_StillWorks — pins the legacy MVP raw-CSR path keeps working when no RA pair is configured. Backward compat is non-negotiable. == Phase 5.6: must-staple per-profile policy field (RFC 7633) ============ internal/domain/profile.go * Added MustStaple bool to CertificateProfile. Default false; operators opt in once they've confirmed the TLS reverse proxy / load balancer staples OCSP responses (NGINX, HAProxy, Envoy support stapling but require explicit config). internal/connector/issuer/interface.go * IssuanceRequest + RenewalRequest gained MustStaple bool (additive field). Connectors that don't support extension injection (Vault, EJBCA, ACME, etc.) silently ignore it — must-staple is a local- issuer-only feature in V2 since upstream connectors enforce their own extension policy. internal/connector/issuer/local/local.go * Added oidMustStaple (1.3.6.1.5.5.7.1.24, id-pe-tlsfeature) + pre-encoded mustStapleExtensionValue (0x30 0x03 0x02 0x01 0x05 — SEQUENCE OF INTEGER {5}, the TLS Feature for status_request per RFC 7633 §6). * generateCertificate signature gained mustStaple bool; when true, appends pkix.Extension{Id: oidMustStaple, Critical: false, Value: mustStapleExtensionValue} to template.ExtraExtensions before x509.CreateCertificate. internal/connector/issuer/local/must_staple_test.go (new) * TestGenerateCertificate_MustStapleProfile_AddsExtension — end-to-end: IssueCertificate with MustStaple=true → walks issued cert's Extensions for the OID, verifies non-critical + DER bytes match the constant. * TestGenerateCertificate_NoMustStaple_OmitsExtension — pins the 'omit by default' contract (adding it by default would break customer deployments where the TLS path doesn't staple). * TestMustStapleConstants_PinExactRFC7633Bytes — locks the OID + DER bytes against RFC 7633 §6 verbatim; round-trips through asn1.Unmarshal as []int{5}. Note: full service-layer plumbing (CertificateProfile.MustStaple → IssuanceRequest.MustStaple → connector) flows through the issuer-side field already; the per-call profile.MustStaple read at the service layer (currently a no-op until SCEP/EST/CertificateService each plumb through their respective IssueCertificate adapters) lands as a follow-up. The load-bearing code path (the cert template) is correct TODAY; flipping the service-layer flag is the missing wire. == Phase 5.4: docs/legacy-est-scep.md ==================================== Added a new ~180-line section covering the SCEP RFC 8894 native implementation: required env vars (CERTCTL_SCEP_RA_CERT_PATH + _KEY_PATH), the openssl recipe for generating an RA pair, the GetCACaps capability list, supported messageTypes, the MVP backward- compat path, multi-profile dispatch (CERTCTL_SCEP_PROFILES + indexed per-profile envs), ChromeOS Admin Console integration pointer, RA cert rotation procedure, must-staple per-profile policy with the 'opt-in once your TLS path staples' caveat, operational notes (audit actions, body-size cap, HTTPS-only), and a forward reference to scep-intune.md (Phase 11). == Verification ========================================================== * gofmt + go vet clean for the files I touched. * staticcheck ./internal/api/handler/... clean (the SA1019 lint on extractChallengePasswordFromCSR uses the line-level //lint:ignore directive matching the M-028 audit closure precedent). * go test -short -count=1 green across api/handler / api/router / service / pkcs7 / connector/issuer/local / domain / cmd/server. * G-3 docs-drift CI guard local check: empty diff in both directions. Phase 4 + Phase 5 of 14 in SCEP RFC 8894 + Intune master bundle. Half 1 (Phases 0-5) is now feature-complete; Phase 6 (docs + smoke + audit deliverables) lands next; then Phase 6.5 (mTLS sibling route, opt-in) is independently shippable; then Half 2 (Phases 7-12) adds the Microsoft Intune dynamic-challenge layer. Living progress at cowork/scep-rfc8894-intune/progress.md.	2026-04-29 13:16:09 +00:00
Shankar	6ae4023582	Bundle F follow-up: M-023 doc env-var cleanup (G-3 guard fix) ... CI on the bundle-F merge (run #24972730564) failed the G-3 env-var docs guardrail because docs/legacy-est-scep.md mentioned CERTCTL_EST_PROXY_TRUSTED_SOURCES CERTCTL_EST_TRUST_PROXY_CLIENT_CERT_HEADER which are documented as future-feature env vars but don't exist in config.go. The G-3 guard treats any env-var name in docs that's not either defined in source OR on the documented integration-surface allowlist as drift. The runbook's 'certctl-side configuration' section was over-promising features that haven't shipped yet. Rewritten to be honest: - Current implementation is header-agnostic (X-SSL-Client-Cert is ignored). EST/SCEP authentication still works correctly because both protocols carry their own auth (CSR signature for EST, challengePassword for SCEP) inside the request body. - The reverse proxy is purely a TLS-version bridge. - Future-feature description retained in prose form (without literal env-var names) so an operator who needs proxy-supplied client identity knows to open an issue. The nginx config block's comment was also rewritten to reflect the header-agnostic default. The proxy still SETS the headers (cheap, no-op when ignored); a future commit can flip certctl to read them behind a fail-closed CIDR allowlist + opt-in toggle. Verification: grep -rnE 'CERTCTL_EST_PROXY|CERTCTL_EST_TRUST' README.md docs/ deploy/helm/ — empty (G-3 guard now passes for these names)	2026-04-27 01:55:04 +00:00
Shankar	6ae481190e	Bundle F: Compliance tail + CI gate hardening — 2 findings closed; audit closure complete ... Closes M-023 + M-024 from comprehensive-audit-2026-04-25. Final audit-bundle commit. Score 51/55 closed (93%); High 9/9 (100%); Medium 26/27 (96%); Low 19/19 (100%); Deferred 4/7. M-023 (PCI-DSS Req 4 §2.2.5) — Legacy EST/SCEP reverse-proxy runbook docs/legacy-est-scep.md (NEW): operator runbook for embedded EST/SCEP clients that only speak TLS 1.2 against a TLS-1.3-pinned certctl listener. Sections: - 3-condition gate for when this runbook applies - Architecture diagram (legacy client -> proxy TLS 1.2 -> certctl TLS 1.3) - Full nginx config with ssl_protocols TLSv1.2 TLSv1.3 + ECDHE AEAD-only ciphers + mTLS optional verification + proxy_ssl_protocols TLSv1.3 on the backend hop - HAProxy alternative config with ssl-min-ver TLSv1.2 frontend + ssl-min-ver TLSv1.3 backend - certctl-side env vars: CERTCTL_EST_PROXY_TRUSTED_SOURCES (CIDR allowlist of trusted proxies) + CERTCTL_EST_TRUST_PROXY_CLIENT_CERT_HEADER (toggle header-as-identity). Dual-knob design forces operators to think about header spoofing. - PCI-DSS Req 4 v4.0 §2.2.5 attestation language - Forward-look on TLS 1.2 deprecation watch certctl listener stays pinned at TLS 1.3 minimum (cmd/server/tls.go:131); the proxy-to-certctl hop is also TLS 1.3. M-024 (NIST SSDF PW.7.2) — govulncheck hard gate .github/workflows/ci.yml: 'Run govulncheck' step renamed to 'Run govulncheck (M-024 hard gate)' with updated comment block documenting why no carve-out is needed. Bundle E's transitive bumps (x/net 0.42->0.47, x/crypto 0.41->0.45) cleared the 5 L-021 deferred-call advisories that the original Bundle F prompt designed an exception list for. Plain 'govulncheck ./...' is now the right gate; default exit-code semantics fail on any future called-vuln advisory. Deferred-call advisories that legitimately can't be remediated should land in a NIST SSDF deviation log in docs/security.md, not be silenced. Audit endgame: 51/55 closed (93%). Remaining open items don't require further bundle work: - M-029 frontend per-page migration backlog — closes per-PR - L-004 rotation infra — explicit scope-pivot defer - D-003 mutation testing — sandbox-blocked - D-004 DAST suite — wired CI-only via security-deep-scan.yml - D-005 testssl.sh — wired CI-only - D-007 frontend semgrep — wired CI-only Audit deliverables: audit-report.md: score 49/55 -> 51/55 closed; M-023 + M-024 boxes flipped [x] with closure notes. findings.yaml: 2 status flips CHANGELOG.md: Bundle F section + 'Audit endgame' summary	2026-04-27 01:43:56 +00:00