SCEP RFC 8894 + Intune master bundle Phase 5.6 follow-up.
Closes the 'lying field' gap from the original Phase 5.6 commit (35fcfa7).
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.
Problem (CWE-306 Missing Authentication for Critical Function):
internal/service/scep.go PKCSReq skipped the shared-secret check when
s.challengePassword was empty. An unconfigured-but-enabled SCEP server
accepted any unauthenticated client reaching /scep and issued a
certificate against the configured issuer for any CSR with a valid
signature. No audit trail distinguished authenticated from
unauthenticated enrollments. This matches the two-layer fail-closed
pattern already used for C-2 (fb4ce1a): reject at startup AND reject
at the service boundary.
Fix (two layers, defense-in-depth):
Layer 1 — startup pre-flight in cmd/server/main.go:
preflightSCEPChallengePassword returns a non-nil error when SCEP is
enabled and CERTCTL_SCEP_CHALLENGE_PASSWORD is empty. main logs and
os.Exit(1)s before the SCEP service is constructed. Disabled SCEP is
unaffected. The helper is unit-testable in isolation.
Layer 2 — service-layer rejection in internal/service/scep.go:
PKCSReq refuses enrollment when s.challengePassword == "" even though
main already blocks this state — protects future call sites (tests,
library reuse, a REST-over-HTTPS wrapper). When a secret is
configured, the comparison now uses crypto/subtle.ConstantTimeCompare
so response time does not leak the configured secret through a
short-circuiting byte compare.
Files:
- cmd/server/main.go: preflightSCEPChallengePassword helper; call site
inside the `if cfg.SCEP.Enabled` block before issuer lookup; fatal
slog error references CWE-306 and names the env var so operators can
diagnose the startup failure without reading code.
- cmd/server/main_test.go: TestPreflightSCEPChallengePassword with five
table-driven subtests (disabled empty, disabled set, enabled empty
rejected, enabled set, single-char boundary). The enabled-empty case
asserts the error string contains both CERTCTL_SCEP_CHALLENGE_PASSWORD
and CWE-306 so the log message remains actionable.
- internal/config/config.go: SCEPConfig.ChallengePassword godoc now
states the field is REQUIRED when SCEP.Enabled and cross-references
preflightSCEPChallengePassword.
- internal/service/scep.go: imports crypto/subtle; PKCSReq rewritten
with the two-layer check; comment block cites H-2 / CWE-306 and the
constant-time rationale.
- internal/service/scep_test.go: existing tests that relied on the
vulnerable empty-password path now configure a secret on both sides.
TestSCEPService_PKCSReq_ChallengePassword_NotRequired is replaced by
TestSCEPService_PKCSReq_ChallengePassword_EmptyServerConfigRejected
which iterates ["", "any-value", "guess"] against an unconfigured
server and asserts "not configured" in the error. A new
TestSCEPService_PKCSReq_ChallengePassword_ConstantTimeLengthIndependence
exercises same-prefix-longer and wrong-case inputs to guard against a
regression from ConstantTimeCompare to a short-circuiting byte compare.
- internal/service/m11c_crypto_enforcement_test.go: four tests
(RejectsWeakKey, AcceptsStrongKey, MaxTTL_ForwardedToIssuer,
NoProfileRepo_PassesThrough) constructed NewSCEPService with an empty
challenge password and exercised PKCSReq through the now-rejected
vulnerable path. All four now configure "secret123" on both sides with
an inline H-2 comment; the crypto/MaxTTL/profile behavior they assert
is unchanged.
Wire-format / behavioral invariants preserved:
- RFC 8894 SCEP handler is untouched (internal/api/handler/scep.go and
internal/pkcs7/*): GetCACaps/GetCACert responses, PKIOperation request
parsing, and the PKCS#7 certs-only response format are byte-identical.
- RFC 7030 EST handler is untouched
(internal/api/handler/est.go + internal/pkcs7/*).
- Revocation idempotency composite key (H-1, migration 000012) untouched.
- AES-256-GCM config encryption (C-2) untouched.
- CRL DER bytes and OCSP response bytes unchanged.
Verification:
- go build ./... silent success
- go vet ./... silent success
- go test -race -count=1 ./internal/service/ ./cmd/server/
./internal/api/handler/ ./internal/integration/ all OK
- Coverage with comfortable headroom over CI gates:
service 67.8% (gate 55%)
handler 79.0% (gate 60%)
domain 92.7% (gate 40%)
middleware 80.0% (gate 30%)
cmd/server 1.6% (preflightSCEPChallengePassword: 100%)
internal/service/scep.go PKCSReq statement coverage: 100%.
- rg sweeps: no `s.challengePassword != ""` remains;
no `challengePassword != s.challengePassword` remains.
Operational note: operators with SCEP enabled but no challenge password
set will see a fatal startup error and a log line citing
CERTCTL_SCEP_CHALLENGE_PASSWORD and CWE-306 after upgrading. This is the
intended fail-closed behavior. Fix by either setting the env var to a
non-empty shared secret or setting CERTCTL_SCEP_ENABLED=false.
Audit report: certctl-audit-report.md (revision 5) logs this under
H-2 Resolution Log.
Enforce certificate profile crypto constraints across all 5 issuance paths
(renewal, agent CSR, EST, SCEP). ValidateCSRAgainstProfile() rejects CSRs
with key algorithm/size that don't match profile rules. MaxTTL enforcement
caps certificate validity per issuer connector (Local CA, Vault, step-ca
enforce directly; ACME/DigiCert/Sectigo pass through). Key algorithm and
size are now persisted in certificate_versions for audit compliance.
16 new tests (12 service-layer + 4 Local CA connector). Removes hardcoded
version number from GUI sidebar. Documentation updated across architecture,
features, connectors, and README.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
certctl-copilot