certctl

gsadmin/certctl

Fork 0

mirror of https://github.com/shankar0123/certctl.git synced 2026-06-07 23:21:30 +00:00

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
shankar0123	8b75e0311b	chore: rename Go module path to github.com/certctl-io/certctl Mechanical sed across the main go.mod's module declaration, the f5-mock-icontrol sub-module's go.mod, every Go file's import path (361 files), and a rebuild of the checked-in f5-mock-icontrol binary so its embedded build-info reflects the new module path. No behavior change. Choice B from cowork/transfer-certctl-to-org.md, executed 2026-05-04. Choice A (keep module path declared as github.com/shankar0123/certctl regardless of repo URL) shipped on the day of the org transfer (2026-05-03) since we had no external Go consumers; this commit closes that deferral. Backward-compat: GitHub HTTP redirects continue to forward github.com/shankar0123/certctl → github.com/certctl-io/certctl at the URL level, but Go's module proxy uses the path declared in go.mod as the canonical name. Pre-fix, anyone trying `go get github.com/certctl-io/certctl/...` hit a "module path mismatch" error because go.mod said github.com/shankar0123/certctl and the URL they fetched it from said certctl-io/certctl. Post-fix, the canonical name and the URL agree, so go get / go install / external Go consumers / Go-tooling integrations work cleanly via either the new path (preferred) or the old path (which redirects and Go follows the redirect for source fetch). Anyone still importing the old path inside their own code keeps working provided they update their go.mod's `require` line to match — the module path declared in their consumer's go.sum / go.mod is the authoritative import name, so a mass sed across their import statements is the migration on the consumer side. No external consumers exist today. Diff shape: 361 *.go files — import path replacement only 2 go.mod — module declaration replacement only 1 binary — deploy/test/f5-mock-icontrol/f5-mock-icontrol rebuilt so embedded build-info reflects the new path (8618965 vs 8618933 bytes; 32-byte diff is the build-info change) Total: 364 files, 730 insertions / 730 deletions, net-zero size, pure mechanical substitution. Verification: gofmt: 17 files needed re-alignment after sed (the new path is one char shorter than the old, so column-aligned import groups drifted). Applied `gofmt -w` to fix. go mod tidy: clean exit on both modules. go vet ./...: clean exit. go build ./...: clean exit. go test -short -count=1 on representative packages: all green (internal/domain, internal/validation, internal/crypto, internal/crypto/signer, cmd/agent). Test output now reads `ok github.com/certctl-io/certctl/...` confirming the module path resolves correctly. binary: f5-mock-icontrol rebuilt; `strings \| grep shankar0123` returns nothing; `strings \| grep certctl-io/certctl` shows the new module path embedded in build-info. Files intentionally NOT touched in this commit: README.md / CHANGELOG.md / docs/ / etc. — already swept to certctl-io URLs in commit `0729ee4` (the post-transfer URL refresh). This commit is purely the Go-tooling layer. Scarf pixels (`shankar0123.docker.scarf.sh/...`) — Scarf-account namespace, not a Go import or GitHub repo URL. Stays. This is a non-blocking, non-customer-impacting change. Operators pulling container images, running `make verify`, hitting the API, or installing the agent see no functional difference. Only Go-tooling consumers (none today) are affected, and they're enabled — not broken — by this commit.	2026-05-04 00:30:29 +00:00
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

shankar0123

8b75e0311b

chore: rename Go module path to github.com/certctl-io/certctl

Mechanical sed across the main go.mod's module declaration, the f5-mock-icontrol
sub-module's go.mod, every Go file's import path (361 files), and a rebuild of
the checked-in f5-mock-icontrol binary so its embedded build-info reflects the
new module path. No behavior change.

Choice B from cowork/transfer-certctl-to-org.md, executed 2026-05-04. Choice A
(keep module path declared as github.com/shankar0123/certctl regardless of
repo URL) shipped on the day of the org transfer (2026-05-03) since we had no
external Go consumers; this commit closes that deferral.

Backward-compat: GitHub HTTP redirects continue to forward
github.com/shankar0123/certctl → github.com/certctl-io/certctl at the URL
level, but Go's module proxy uses the path declared in go.mod as the
canonical name. Pre-fix, anyone trying `go get github.com/certctl-io/certctl/...`
hit a "module path mismatch" error because go.mod said
github.com/shankar0123/certctl and the URL they fetched it from said
certctl-io/certctl. Post-fix, the canonical name and the URL agree, so
go get / go install / external Go consumers / Go-tooling integrations
work cleanly via either the new path (preferred) or the old path (which
redirects and Go follows the redirect for source fetch).

Anyone still importing the old path inside their own code keeps working
provided they update their go.mod's `require` line to match — the module
path declared in their consumer's go.sum / go.mod is the authoritative
import name, so a mass sed across their import statements is the migration
on the consumer side. No external consumers exist today.

Diff shape:
  361 *.go files  — import path replacement only
    2 go.mod     — module declaration replacement only
    1 binary     — deploy/test/f5-mock-icontrol/f5-mock-icontrol rebuilt
                   so embedded build-info reflects the new path (8618965 vs
                   8618933 bytes; 32-byte diff is the build-info change)

  Total: 364 files, 730 insertions / 730 deletions, net-zero size, pure
  mechanical substitution.

Verification:
  gofmt: 17 files needed re-alignment after sed (the new path is one char
    shorter than the old, so column-aligned import groups drifted). Applied
    `gofmt -w` to fix.
  go mod tidy: clean exit on both modules.
  go vet ./...: clean exit.
  go build ./...: clean exit.
  go test -short -count=1 on representative packages: all green
    (internal/domain, internal/validation, internal/crypto, internal/crypto/signer,
    cmd/agent). Test output now reads `ok github.com/certctl-io/certctl/...`
    confirming the module path resolves correctly.
  binary: f5-mock-icontrol rebuilt; `strings | grep shankar0123` returns
    nothing; `strings | grep certctl-io/certctl` shows the new module path
    embedded in build-info.

Files intentionally NOT touched in this commit:
  README.md / CHANGELOG.md / docs/ / etc. — already swept to certctl-io
    URLs in commit 0729ee4 (the post-transfer URL refresh). This commit is
    purely the Go-tooling layer.
  Scarf pixels (`shankar0123.docker.scarf.sh/...`) — Scarf-account
    namespace, not a Go import or GitHub repo URL. Stays.

This is a non-blocking, non-customer-impacting change. Operators pulling
container images, running `make verify`, hitting the API, or installing the
agent see no functional difference. Only Go-tooling consumers (none today)
are affected, and they're enabled — not broken — by this commit.

2026-05-04 00:30:29 +00:00

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

3 Commits