fix(ci): set CERTCTL_ACME_INSECURE_ACK=true in test compose

Phase 2 SEC-M4 (commit 5062624) added a fail-closed pairing
requirement: when CERTCTL_ACME_INSECURE=true, the server refuses to
start unless CERTCTL_ACME_INSECURE_ACK=true is also set. The integration
test compose at deploy/docker-compose.test.yml has been setting
CERTCTL_ACME_INSECURE=true (correct — Pebble's self-signed ACME
directory needs TLS verification disabled) but never set the paired
ACK, so the certctl-test-server container restart-loops with:

  Failed to load configuration: phase-2 SEC-M4 fail-closed guard:
  CERTCTL_ACME_INSECURE=true but CERTCTL_ACME_INSECURE_ACK is not
  true — refuse to start.

This breaks the deploy-vendor-e2e CI job that exercises the EST/ACME
integration stack.

Fix: set CERTCTL_ACME_INSECURE_ACK=true alongside the existing
CERTCTL_ACME_INSECURE=true. The ACK posture is correct here because
the integration suite is built around Pebble's self-signed directory
— that's the design. The guard's purpose (block accidental production
deploys with TLS verify disabled) is preserved by the ACK still being
explicit per-environment, not a fail-open default.
This commit is contained in:
shankar0123
2026-05-13 23:06:22 +00:00
parent 921dac7e6b
commit d364ace02a
+8
View File
@@ -272,6 +272,14 @@ services:
CERTCTL_ACME_EMAIL: test@certctl.dev
CERTCTL_ACME_CHALLENGE_TYPE: http-01
CERTCTL_ACME_INSECURE: "true"
# Phase 2 SEC-M4 (2026-05-13): CERTCTL_ACME_INSECURE=true requires
# the paired CERTCTL_ACME_INSECURE_ACK=true; without the ACK the
# server's Config.Validate() refuses to start. This integration
# stack uses Pebble's self-signed ACME directory, so disabling
# TLS verification is correct — but the ACK env var has to be
# set explicitly so the test posture matches what production
# operators are blocked from doing accidentally.
CERTCTL_ACME_INSECURE_ACK: "true"
# step-ca issuer (iss-stepca)
CERTCTL_STEPCA_URL: https://step-ca:9000