gsadmin/certctl
1
0
Fork 0
mirror of https://github.com/shankar0123/certctl.git synced 2026-06-07 23:11:32 +00:00
Code Issues Packages Projects Releases Wiki Activity
673 Commits 1 Branch 82 Tags
45fae9952aaccc9e41fc785cf835c4d45bd2a7bb
Commit Graph

6 Commits

Author SHA1 Message Date
shankar0123 7e0a7deeff fix(deploy/test/libest): drop make-time CFLAGS/LDFLAGS pass-through 
estclient link was failing with `cannot find -lsafe_lib` despite
libsafe_lib.a building cleanly under safe_c_stub/lib/. Root cause:
libest's configure.ac (lines 193-195) appends the bundled safec
stub's path to user-supplied flags:

    CFLAGS="$CFLAGS -Wall -I$safecdir/include"
    LDFLAGS="$LDFLAGS -L$safecdir/lib"
    LIBS="$LIBS -lsafe_lib"

These get baked into the generated Makefile via @CFLAGS@/@LDFLAGS@/
@LIBS@ substitutions. Per automake's variable-precedence rules, a
command-line `make LDFLAGS=...` overrides the `LDFLAGS = @LDFLAGS@`
line in the Makefile — wiping the `-L/src/safe_c_stub/lib` that
configure put there.

The previous commit (f7ee64b) passed these flags at BOTH configure-
time AND make-time. The make-time pass-through was redundant
(configure already baked the flags in) and actively destructive
(it overrode configure's own additions). Configure-time alone is
correct: configure appends to the user's flags, writes the merged
value once, and every link command picks it up.

Verified against upstream r3.2.0:
- safe_c_stub/lib/Makefile.am produces noinst_LIBRARIES=libsafe_lib.a
- example/client/Makefile.am does NOT mention -lsafe_lib explicitly;
  it relies on the configure-baked LIBS+LDFLAGS to bring it in
- top-level Makefile.am has SUBDIRS=safe_c_stub src ... so the stub
  is built before src/est gets a chance to depend on it

CI fix #7 in the ci-pipeline-cleanup post-merge fix-up sequence. Each
"new bug" the cleaned-up CI surfaces is the same shape: a pre-existing
latent bug that the old per-vendor matrix or missing checks
structurally hid. The Docker build smoke step in the new
image-and-supply-chain job is exposing this libest sidecar's full
dependency chain for the first time.
 2026-04-30 23:21:59 +00:00
shankar0123 f7ee64bd79 fix(deploy/test/libest): CFLAGS=-fcommon + LDFLAGS=--allow-multiple-definition 
CI run 25193735664 (image-and-supply-chain) showed bullseye-slim
fixed the OpenSSL 3.0 FIPS_mode errors, but the multiple-definition
errors persisted. Root cause was misdiagnosed in commit bba4253 —
the cutover isn't binutils 2.35→2.40, it's GCC's -fcommon → -fno-common
default which flipped in GCC 10 (released 2020-05).

bullseye ships GCC 10.2 — already enforces -fno-common. So switching
the base bookworm (GCC 12) → bullseye (GCC 10.2) didn't restore the
default libest 3.2.0 was authored under. The next-older default-
fcommon GCC is 9.x in debian:buster (Debian 10), which went LTS-EOL
June 2024.

Restore the build contract via flags instead of base downgrade:

  CFLAGS=-fcommon
    Restores pre-GCC-10 default for tentative definitions.
    Resolves the 9 'e_ctx_ssl_exdata_index multiple definition'
    errors — libest's est_locl.h:593 declares the global without
    'extern', and pre-GCC-10 every TU could share the tentative
    definition. GCC 10+ requires explicit 'extern' for that.

  LDFLAGS=-Wl,--allow-multiple-definition
    Restores the pre-strict ld behavior that tolerates function-
    level duplicates. Resolves the 'ossl_dump_ssl_errors multiple
    definition' between libest's src/est/est_ossl_util.c:310 and
    example/client/util/utils.c:33 — these are real (non-tentative)
    function definitions; -fcommon doesn't apply, but
    --allow-multiple-definition lets ld link with last-defined-wins.

Both flags propagated to BOTH the configure invocation AND the make
recursive invocation (libest's autotools setup re-runs gcc through
both, and the inner make doesn't always inherit env in libtool's
recursion).

Why this is the proper path:
- These are the documented compatibility flags for projects authored
  under the GCC 9 / pre-strict-ld defaults. They don't disable real
  errors — they restore semantics the libest source assumes.
- Plenty of other projects (e.g., nettle, libtirpc 1.x, openldap 2.4)
  use these same flags for the same reason.

Combined with commit bba4253 (bullseye base for OpenSSL 1.1.x ABI),
this is the full set of toolchain-restoration flags libest 3.2.0
requires to build on a 2026-era runtime.

Cannot verify the actual docker build in the sandbox (out of disk +
no docker), but each flag has a textbook explanation for the exact
class of error observed in CI.
 2026-04-30 23:12:08 +00:00
shankar0123 bba425393b fix(deploy/test/libest): switch base bookworm-slim → bullseye-slim 
libest r3.2.0 (last upstream commit 2020-07-06) was authored against
OpenSSL 1.1.x and binutils ≤ 2.35. It does NOT build on the bookworm
toolchain for THREE independent reasons surfaced by ci-pipeline-cleanup
Phase 8's Docker build smoke (CI run 25192994486):

  1. FIPS_mode / FIPS_mode_set undefined references
     OpenSSL 3.0 removed these. libest r3.2.0 calls them in 5 places
     (est_client.c × 3, est_server.c × 1, estclient.c × 1).
     Even libest 'main' branch still uses them without OPENSSL_VERSION
     guards, so we can't escape this by bumping LIBEST_REF.

  2. e_ctx_ssl_exdata_index multiple definition
     est_locl.h:593 declares the symbol without 'extern', so every
     translation unit including the header gets its own definition.
     binutils 2.36+ defaults to -fno-common which refuses this; older
     binutils tolerated it. Fix is on libest main but not in r3.2.0.

  3. ossl_dump_ssl_errors duplicate symbol
     Symbol exists in both libest src + example/client/utils.c —
     same -fno-common shape.

debian:bookworm-slim ships OpenSSL 3.0 + binutils 2.40 — three for three.
debian:bullseye-slim ships OpenSSL 1.1.1n + binutils 2.35.2 — zero for three.

Switching the base eliminates all three errors at once. Both FROM lines
swap (builder + runtime) so the dynamically-linked libssl ABI matches.
Runtime apt: 'libssl3' → 'libssl1.1' for the same reason.

Why this is the proper path, not a band-aid:
- Bullseye is the actual environment libest 3.2.0 was authored against
  (per its configure.ac HAVE_OLD_OPENSSL macro). Bookworm was the wrong
  base for this dep from day 1 of the EST RFC 7030 hardening bundle.
- The libest sidecar runs in a hermetic test environment — not exposed
  to attackers, not shipped in production. OpenSSL 1.1.1 EOL (2023-09)
  is acceptable for a test-only fixture. Production certctl images
  remain on bookworm-slim with OpenSSL 3.0.
- Bullseye support timeline: regular updates until 2026-08, LTS until
  2028-08. Two+ years of runway before the next base bump.

Both FROM lines pinned to debian:bullseye-slim@sha256:1a4701c321b1...
(verified via OCI v2 manifest endpoint 2026-04-30).

Sandbox verification:
  bash scripts/ci-guards/H-001-bare-from.sh    → clean
  bash scripts/ci-guards/digest-validity.sh    → all 16 digests resolve

Cannot verify the actual docker build without docker; if the build
still fails on bullseye, the next layer of fixes is sed-patching the
libest source for the surviving issues (FIPS_mode guards) — but the
toolchain compatibility issue alone explains all three observed errors,
so this should resolve them.
 2026-04-30 22:53:32 +00:00
shankar0123 31ce64653d fix(deploy/test/libest): pin LIBEST_REF to upstream tag r3.2.0 
The Dockerfile at HEAD pinned LIBEST_REF=v3.2.0-2 — that ref does
NOT exist on cisco/libest upstream. Verified via:

    curl -sS https://api.github.com/repos/cisco/libest/tags
    # only tags returned: v1.0.0, r3.2.0, 1.1.0

The 'v' prefix and the '-2' patch suffix were both wrong from day
one (commit e9011ca, EST RFC 7030 hardening Phase 10.1). The bug
went undetected because the libest sidecar Dockerfile was never
built end-to-end — neither operator-side nor in CI. The Dockerfile's
own header comment ('last tag 3.2.0-2 from 2018') was inaccurate
in the same way.

This fix:
  - ARG LIBEST_REF=v3.2.0-2 → r3.2.0 (the actual upstream tag, sha
    4ca02c6d7540f2b1bcea278a4fbe373daac7103b verified via
    api.github.com/repos/cisco/libest/git/refs/tags/r3.2.0)
  - Updated the surrounding head-comment block to reflect the real
    upstream tag name + cite the 2026-04-30 GitHub API verification.
  - Added a note explaining the prior broken pin so future readers
    don't re-introduce it.

The estclient binary built from r3.2.0 supports the only RFC 7030
endpoint the est_e2e_test.go exercises ('estclient -g' = GET
cacerts), so the integration test still works against this ref.

Closes the libest-build-failure surfaced by ci-pipeline-cleanup
Phase 8's Docker build smoke step (CI run 25192163943, job
'image-and-supply-chain').
 2026-04-30 22:38:27 +00:00
shankar0123 e9011caac8 fix(deploy/libest): pin debian:bookworm-slim FROM lines to digest (H-001) 
CI's 'Forbidden bare FROM regression guard (H-001)' rejects any
Dockerfile FROM line missing an @sha256:... digest pin. The Phase 10
libest sidecar Dockerfile shipped two bare FROMs at lines 25 and 55,
both targeting debian:bookworm-slim. The repo's Bundle A / Audit
H-001 (CWE-829) policy has been in force on every other Dockerfile
since the bundle landed; the new sidecar simply needs to follow the
same convention.

Pinned both lines to:
  debian:bookworm-slim@sha256:f9c6a2fd2ddbc23e336b6257a5245e31f996953ef06cd13a59fa0a1df2d5c252

That's the OCI image-index digest from
https://hub.docker.com/v2/repositories/library/debian/tags/bookworm-slim
fetched 2026-04-29 (last_pushed 2026-04-22). Multi-arch index, so
Docker resolves the per-arch manifest correctly on the CI runner.

Added a comment at the top of the FROM block documenting the bump
procedure (curl + jq one-liner against the Docker Hub registry API),
matching the convention from the top-level Dockerfile.

Verified locally with the exact CI guard regex
(grep -HnE '^FROM\s+[^@#]+(\s+AS\s+\S+)?\s*$' across every
Dockerfile* under the repo, excluding web/node_modules) — passes.
Also verified the M-012 USER-drop guard still passes for the libest
sidecar (terminal USER estuser, set on line 73).
 2026-04-30 02:03:07 +00:00
shankar0123 5a682db8e2 EST RFC 7030 hardening master bundle Phases 10-11: libest sidecar e2e 
+ Cisco IOS quirk fixtures + ManagedCertificate.Source provenance +
EST bulk-revoke endpoint + 13 typed audit action codes.

Phase 10.1 — libest reference-client sidecar:
- deploy/test/libest/Dockerfile: multi-stage Debian-bookworm-slim
  build of Cisco's libest v3.2.0-2 from source (autoconf/automake/
  libtool + libcurl4-openssl-dev + libssl-dev). Runtime stage
  carries only estclient + bash + openssl + ca-certificates so the
  exec surface stays small + predictable.
- docker-compose.test.yml libest-client entry (profiles: [est-e2e])
  with bind mounts for /config/est (test workspace) + /config/certs
  (certctl CA bundle for TLS pinning); IP 10.30.50.9 (10.30.50.8
  was already taken by certctl-agent).
- deploy/test/est/.gitkeep keeps the bind-mount target tracked.

Phase 10.2 — 5 integration tests (//go:build integration) in
deploy/test/est_e2e_test.go:
- TestEST_LibESTClient_Enrollment_Integration (cacerts → simpleenroll
  → cert-shape assertion)
- TestEST_LibESTClient_MTLSEnrollment_Integration (mTLS sibling-route
  cert auth; skip when bootstrap cert absent)
- TestEST_LibESTClient_ServerKeygen_Integration (RFC 7030 §4.4
  multipart; skip when profile gate disabled)
- TestEST_LibESTClient_RateLimited_Integration (4th enroll trips
  per-principal cap, asserts 429-shaped error)
- TestEST_LibESTClient_ChannelBinding_Integration (libest
  --tls-exporter; skip when libest build lacks the flag).
- requireESTSidecar guard skips the suite when the operator forgot
  --profile est-e2e; helpful error message includes the exact
  command to bring the sidecar up.

Phase 10.3 — Cisco IOS quirk fixtures + 3 unit tests in
internal/api/handler/cisco_ios_quirks_test.go:
- testdata/cisco_ios_15x_pem_csr.txt: PEM body sent with
  Content-Type application/x-pem-file. Handler dispatches on
  body-prefix not Content-Type — accepts cleanly.
- testdata/cisco_ios_16x_trailing_newline_csr.txt: extra trailing
  newlines after base64 body. strings.TrimSpace tolerates.
- testdata/cisco_ios_crlf_b64_csr.txt: CRLF-wrapped base64.
  base64.StdEncoding handles CRLF + LF identically.

Phase 11.1 — ManagedCertificate.Source provenance:
- New domain.CertificateSource enum (Unspecified/EST/SCEP/API/Agent).
- Migration 000023_managed_certificates_source.up.sql adds source
  TEXT NOT NULL DEFAULT '' so existing rows scan as
  CertificateSourceUnspecified — back-compat: bulk-revoke filter
  treats empty as "any source".
- Postgres repo Insert/Update/scan paths all wire the new column.

Phase 11.2 — EST bulk-revoke endpoint:
- BulkRevocationCriteria.Source field (Source-only requests rejected
  as too broad — must accompany at least one narrower criterion).
- service.bulk_revocation.resolveCertificates post-filter by Source
  (empty=any, no SQL change so existing CertificateFilter callers
  unaffected).
- New BulkRevocationHandler.BulkRevokeEST method pins Source=EST +
  dispatches; new route POST /api/v1/est/certificates/bulk-revoke
  (M-008 admin-gated). openapi.yaml documented + parity-guard green.

Phase 11.3 — 13 typed audit action codes in
internal/service/est_audit_actions.go:
- est_simple_enroll_success / _failed
- est_simple_reenroll_success / _failed
- est_server_keygen_success / _failed
- est_auth_failed_basic / _mtls / _channel_binding
- est_rate_limited
- est_csr_policy_violation
- est_bulk_revoke
- est_trust_anchor_reloaded
- ESTService.processEnrollment + SimpleServerKeygen + ReloadTrust
  split-emit BOTH the legacy bare action codes (back-compat for the
  GUI activity-tab chip filters that match by exact string +
  existing audit-log analysers) AND the new typed _success / _failed
  variants (operator grep target + per-failure-mode counter).

Tests:
- internal/api/handler/bulk_revocation_est_test.go — 5 cases
  (admin-true happy path pins Source=EST + non-admin 403 +
  empty-criteria 400 + invalid-reason 400 + method-not-allowed).
- internal/service/est_audit_actions_test.go — 5 cases (SimpleEnroll
  legacy+typed emission / SimpleReEnroll typed / IssuerError
  typed-failed / PolicyViolation triple-emit /
  unique-string invariant).

Pre-commit verification (sandbox): gofmt clean, go vet clean
(excluding repository/postgres testcontainers limit), staticcheck
clean across api/handler/api/router/domain/service/deploy/test,
go test -short -count=1 green for every non-postgres Go package +
integration build (`go build -tags integration ./deploy/test/...`)
clean. G-3 docs-drift guard reproduced locally clean (Phases 10-11
added zero new env vars).

Spec preserved at cowork/est-rfc7030-hardening-prompt.md. Phases
12-13 (docs/est.md + WiFi/802.1X / IoT bootstrap / FreeRADIUS
recipes; release prep + tag) remain — post-2.1.0 work.
 2026-04-30 00:52:43 +00:00