aicers · AcoPiper · Sep 2, 2026 · Sep 2, 2026 · Sep 2, 2026 · Sep 2, 2026
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -274,6 +274,23 @@ service host. For a component installed once per deployment, reusing its
 old `service_name` as the key reproduces every previous path and name
 byte for byte.
 
+### Removed
+
+- `bootroot-agent --insecure` is gone. The flag disabled TLS certificate
+  verification for the ACME server, so a run that carried it accepted any
+  certificate at all, and the daemon offered no narrower way to get past a
+  handshake failure. Certificate verification now has no off switch: the
+  agent verifies against `[trust]` when it is configured and against the
+  system CA store otherwise, and a run that passes `--insecure` is refused
+  at argument parsing rather than starting with verification off. A
+  deployment that relied on the flag needs its trust material in place
+  before the first run — `bootroot service add` and `bootroot-remote
+  bootstrap` already write `trust.ca_bundle_path` and
+  `trust.trusted_ca_sha256` for the managed onboarding flow. The compose
+  smoke path is the one place that ran without them, and
+  `agent.toml.compose` now carries a `[trust]` section to fill in from
+  `secrets/certs/`.
+
 ### Security
 
 - Bumped `h2` from 0.4.15 to 0.4.16 to address RUSTSEC-2026-0258

diff --git a/agent.toml.compose b/agent.toml.compose
@@ -26,6 +26,27 @@ http_responder_hmac = "CHANGE-ME"
 http_responder_timeout_secs = 5
 http_responder_token_ttl_secs = 300
 
+# The compose stack's step-ca is self-signed, and nothing in bootroot-agent
+# skips verifying it, so this run needs the deployment's own trust material.
+# Build the bundle and read the two fingerprints out of secrets/certs/:
+#
+#   mkdir -p certs
+#   cat secrets/certs/root_ca.crt secrets/certs/intermediate_ca.crt \
+#     > certs/compose-ca-bundle.pem
+#   for cert in secrets/certs/root_ca.crt secrets/certs/intermediate_ca.crt; do
+#     openssl x509 -in "$cert" -noout -fingerprint -sha256 \
+#       | cut -d= -f2 | tr -d ':' | tr 'A-Z' 'a-z'
+#   done
+#
+# trusted_ca_sha256 must hold those two values before deployment. The
+# placeholders below are not 64 hex characters, so a run that leaves them
+# in place is refused while the config is validated, before any connection
+# is attempted.
+# scripts/preflight/extra/agent-scenarios.sh stamps both in for its own runs.
+[trust]
+ca_bundle_path = "certs/compose-ca-bundle.pem"
+trusted_ca_sha256 = ["CHANGE-ME-ROOT", "CHANGE-ME-INTERMEDIATE"]
+
 [retry]
 backoff_secs = [5, 10, 30]
 

diff --git a/docs/en/cli.md b/docs/en/cli.md
@@ -1101,8 +1101,9 @@ automatically as part of onboarding.
 - `remote-bootstrap`: `bootroot service add` prepares the service trust
   payload in OpenBao, and `bootroot-remote bootstrap` applies it on the
   remote host.
-- `--insecure` is a per-run break-glass override. For full rules and
-  operating flow, see [Configuration > Trust](configuration.md#trust).
+- There is no override that skips verifying the ACME server. Trust must be in
+  place before the first run. For full rules and operating flow, see
+  [Configuration > Trust](configuration.md#trust).
 
 #### 4-3) Preview mode (`--print-only`/`--dry-run`)
 

diff --git a/docs/en/configuration.md b/docs/en/configuration.md
@@ -230,7 +230,7 @@ This section covers both mTLS trust and **ACME server TLS verification**.
 - when both trust keys are configured, bootroot-agent verifies the ACME
   server with that bundle and fingerprint set
 - when trust is not configured, bootroot-agent falls back to the system CA
-  store unless `--insecure` is used for a one-off override
+  store; there is no flag that relaxes verification below that
 
 `trusted_ca_sha256` must match real CA certificate fingerprints (not
 arbitrary values).
@@ -247,9 +247,11 @@ arbitrary values).
 
 #### 4) Runtime flag behavior
 
-- `--insecure`: disable ACME server TLS verification for that run only
-- no override flag: verify normally using the configured trust material or
-  the system CA store
+- there is no runtime flag that disables or relaxes ACME server TLS
+  verification. bootroot-agent always verifies, using the configured trust
+  material when `[trust]` is set and the system CA store otherwise
+- a handshake that fails is fixed by correcting the trust anchors, the SANs
+  or the clock, never by accepting the certificate anyway
 
 #### 5) Recommended operating flow
 
@@ -264,9 +266,10 @@ enabled"
      `ca-bundle.pem` locally.
    - `remote-bootstrap`: run `bootroot-remote bootstrap` once to apply the
      same trust payload on the remote host.
-4. Start `bootroot-agent` without `--insecure`; in the managed onboarding
-   flow trust should already be in place for normal verification.
-5. Reserve `--insecure` for temporary diagnosis or other break-glass cases.
+4. Start `bootroot-agent`; in the managed onboarding flow trust should
+   already be in place for normal verification. A run that starts before
+   trust is applied fails the ACME handshake instead of proceeding
+   unverified.
 
 In the default Bootroot deployment, step-ca may present its CA certificate
 directly on the HTTPS endpoint. When `trusted_ca_sha256` is configured,
@@ -276,7 +279,8 @@ bundle or a directly presented certificate whose fingerprint is pinned in
 
 #### 6) Failure/caution notes
 
-- `--insecure` bypasses verification only for that run
+- a TLS failure against the ACME server means the trust material is wrong or
+  missing; apply it and retry rather than looking for a bypass
 - in single-step-ca setups, reusing one `ca_bundle_path` for both mTLS and
   ACME verification is acceptable
 
@@ -1067,7 +1071,6 @@ Options:
 - `--eab-hmac <HMAC>`: EAB HMAC key
 - `--eab-file <PATH>`: EAB JSON file path
 - `--oneshot`: issue once and exit (disable daemon loop, default `false`)
-- `--insecure`: disable ACME server TLS verification (default `false`)
 
 All other settings (profiles, retry, scheduler, hooks, CA bundle paths, etc.)
 must be defined in `agent.toml`.

diff --git a/docs/en/installation.md b/docs/en/installation.md
@@ -591,14 +591,15 @@ updates and `rotate eab-clear` are silent no-ops for that agent. See
 [Operations > systemd operations procedure](operations.md#systemd-operations-procedure-recommended-for-bootroot-agent)
 for a hardened unit example.
 
-TLS verification override:
+TLS verification:
 
 For detailed behavior and the recommended operating flow, see
 [Configuration > Trust](configuration.md#trust).
 
-- `--insecure` disables verification for that run (**insecure**, overrides
-  normal behavior). In the normal managed onboarding flow, trust is prepared
-  before the first `bootroot-agent` run so verification can already be on.
+- bootroot-agent always verifies the ACME server's certificate, and there is
+  no flag that turns that off. In the normal managed onboarding flow, trust is
+  prepared before the first `bootroot-agent` run, so the first run verifies
+  against material that is already in place.
 
 #### CA bundle consumer permissions
 
@@ -611,20 +612,35 @@ service under the same user or group.
 bootroot-agent has no container image: it always runs as a host process, so
 there is nothing to `docker compose up`. To exercise a **one-shot** issuance
 against the compose stack, build the binary and point it at the ports the
-stack publishes to the host:
+stack publishes to the host.
+
+The compose stack's CA is self-signed and nothing skips verifying it, so
+prepare the trust material first from the deployment's own certificates:
+
+```bash
+mkdir -p certs
+cat secrets/certs/root_ca.crt secrets/certs/intermediate_ca.crt \
+  > certs/compose-ca-bundle.pem
+for cert in secrets/certs/root_ca.crt secrets/certs/intermediate_ca.crt; do
+  openssl x509 -in "$cert" -noout -fingerprint -sha256 \
+    | cut -d= -f2 | tr -d ':' | tr 'A-Z' 'a-z'
+done
+```
+
+Put those two fingerprints in `agent.toml.compose` under
+`trust.trusted_ca_sha256`, then run:
 
 ```bash
 cargo build --bin bootroot-agent
-./target/debug/bootroot-agent --oneshot --insecure --config agent.toml.compose
+./target/debug/bootroot-agent --oneshot --config agent.toml.compose
 ```
 
 `agent.toml.compose` is the config for exactly this run model — a native
-binary talking to the compose stack over `localhost`. `--insecure` is needed
-because the compose stack's CA is self-signed and this config carries no
-trust bundle; the managed onboarding flow prepares trust first and does not
-need it. This is a demo/smoke path, not an onboarding path: production
-services run the bootroot-agent host daemon described above with the config
-`bootroot service add` writes.
+binary talking to the compose stack over `localhost`, verifying step-ca
+against the bundle and pins prepared above. This is a demo/smoke path, not an
+onboarding path: production services run the bootroot-agent host daemon
+described above with the config `bootroot service add` writes, and
+`bootroot service add` prepares the same two trust keys for them.
 
 `scripts/preflight/extra/agent-scenarios.sh` drives the same binary the same
 way across its scenarios.

diff --git a/docs/en/operations.md b/docs/en/operations.md
@@ -3258,8 +3258,9 @@ This section covers how to operate two trust settings together:
 - bootroot-agent normally verifies the ACME server (step-ca) TLS
   certificate. If trust settings are configured, it uses the managed CA
   bundle and pins; otherwise it uses the system CA store.
-- CLI override: `bootroot-agent --insecure` disables verification only for
-  that run.
+- There is no CLI override that disables that verification. A run whose trust
+  material is missing or wrong fails the handshake rather than continuing
+  unverified.
 - In the managed onboarding flow, trust is prepared before the first
   `bootroot-agent` run:
   - `local-file`: `bootroot service add` writes trust settings and

diff --git a/docs/en/troubleshooting.md b/docs/en/troubleshooting.md
@@ -249,7 +249,10 @@ older builds, add `http_responder_hmac` to the `[acme]` section of
 
 - Ensure `server` URL is `https://` (`http://` is rejected)
 - Validate system trust or `trust.ca_bundle_path`
-- Use `bootroot-agent --insecure` only for temporary diagnosis
+- Verification cannot be turned off: fix the trust anchors, the certificate's
+  SANs, or the clock. Confirm the anchor the agent is configured with matches
+  the one that signed the ACME server's certificate:
+  `openssl s_client -connect <host>:<port> -showcerts </dev/null`
 
 ### `rotate infra-cert` fails with `permission denied` (older builds)
 

diff --git a/docs/ko/cli.md b/docs/ko/cli.md
@@ -1070,9 +1070,9 @@ EAB 갱신과 `rotate eab-clear`가 해당 에이전트에서 조용히 무시
 - `remote-bootstrap`: `bootroot service add`가 OpenBao에 서비스 trust
   payload를 준비하고, `bootroot-remote bootstrap`이 원격 호스트에
   반영합니다.
-- `--insecure`는 실행 단위 break-glass 오버라이드입니다. 자세한
-  규칙/운영 흐름은 [설정 > 신뢰](configuration.md#신뢰) 섹션을
-  참고하세요.
+- ACME 서버 검증을 건너뛰는 오버라이드는 없습니다. 첫 실행 전에 trust가
+  준비돼 있어야 합니다. 자세한 규칙/운영 흐름은
+  [설정 > 신뢰](configuration.md#신뢰) 섹션을 참고하세요.
 
 #### 4-3) preview 모드(`--print-only`/`--dry-run`)
 

diff --git a/docs/ko/configuration.md b/docs/ko/configuration.md
@@ -221,8 +221,8 @@ mTLS 신뢰와 **ACME 서버 TLS 검증**을 함께 다루는 섹션입니다.
 - `trusted_ca_sha256`: 신뢰할 CA 인증서 지문 목록(SHA-256 hex)
 - trust 두 값이 모두 있으면 bootroot-agent가 해당 번들과 지문으로
   ACME 서버를 검증합니다
-- trust가 비어 있으면 `--insecure`를 쓰지 않는 한 시스템 CA 저장소로
-  일반 검증을 수행합니다
+- trust가 비어 있으면 시스템 CA 저장소로 일반 검증을 수행합니다. 검증
+  수준을 그 아래로 낮추는 플래그는 없습니다
 
 `trusted_ca_sha256`는 임의 값이 아니라 실제 CA 인증서 지문이어야 합니다.
 
@@ -238,8 +238,11 @@ mTLS 신뢰와 **ACME 서버 TLS 검증**을 함께 다루는 섹션입니다.
 
 #### 4) 실행 플래그 동작
 
-- `--insecure`: 해당 실행에서만 ACME 서버 TLS 검증 비활성화
-- 오버라이드가 없으면: 구성된 trust 또는 시스템 CA 저장소로 일반 검증
+- ACME 서버 TLS 검증을 비활성화하거나 완화하는 실행 플래그는 없습니다.
+  bootroot-agent는 `[trust]`가 설정돼 있으면 그 trust 자료로, 아니면
+  시스템 CA 저장소로 항상 검증합니다
+- 핸드셰이크가 실패하면 trust 앵커, 인증서 SAN, 시계를 바로잡아
+  해결합니다. 인증서를 그대로 수용하는 우회 경로는 없습니다
 
 #### 5) 권장 운영 절차
 
@@ -253,9 +256,9 @@ mTLS 신뢰와 **ACME 서버 TLS 검증**을 함께 다루는 섹션입니다.
      `ca-bundle.pem`을 로컬에 기록합니다.
    - `remote-bootstrap`: `bootroot-remote bootstrap`을 1회 실행해 같은
      trust payload를 원격 호스트에 반영합니다.
-4. `--insecure` 없이 `bootroot-agent`를 시작합니다. managed onboarding
-   흐름에서는 이미 정상 검증에 필요한 trust가 준비돼 있어야 합니다.
-5. `--insecure`는 임시 진단이나 break-glass 상황에서만 사용합니다.
+4. `bootroot-agent`를 시작합니다. managed onboarding 흐름에서는 이미 정상
+   검증에 필요한 trust가 준비돼 있어야 합니다. trust 반영 전에 시작한
+   실행은 검증 없이 진행되지 않고 ACME 핸드셰이크에서 실패합니다.
 
 기본 Bootroot 배포에서는 step-ca가 HTTPS 엔드포인트에서 CA 인증서를 직접
 제시할 수 있습니다. `trusted_ca_sha256`가 설정되면 bootroot-agent는
@@ -264,7 +267,8 @@ mTLS 신뢰와 **ACME 서버 TLS 검증**을 함께 다루는 섹션입니다.
 
 #### 6) 실패/주의 사항
 
-- `--insecure` 실행은 해당 실행에서만 검증을 우회
+- ACME 서버 TLS 실패는 trust 자료가 없거나 잘못됐다는 뜻입니다. 우회
+  수단을 찾는 대신 trust를 반영하고 다시 실행합니다
 - 단일 step-ca 환경에서는 mTLS 번들과 ACME 검증에 같은 `ca_bundle_path` 재사용 가능
 
 #### 7) 점검 체크리스트
@@ -1110,7 +1114,6 @@ backoff_secs = [5, 10, 30]
 - `--eab-hmac <HMAC>`: EAB HMAC Key
 - `--eab-file <PATH>`: EAB JSON 파일 경로
 - `--oneshot`: 1회 발급 후 종료(데몬 루프 비활성화, 기본값 `false`)
-- `--insecure`: ACME 서버 TLS 검증 비활성화(기본값 `false`)
 
 그 외 설정(프로필, 재시도, 스케줄러, 훅, CA 번들 경로 등)은
 `agent.toml`에 정의해야 합니다.

diff --git a/docs/ko/installation.md b/docs/ko/installation.md
@@ -597,15 +597,14 @@ EAB 회전이 적용되려면 `--eab-file`이 필수입니다 — 없으면 EAB
 방법은 **설정** 섹션과 [운영 > systemd 운영 절차](operations.md)의
 하드닝된 유닛 예시를 참고하세요.
 
-TLS 검증 오버라이드:
+TLS 검증:
 
 자세한 동작 원리와 권장 운용 순서는 [설정 > 신뢰](configuration.md)를
 참고하세요.
 
-- `--insecure`: 해당 실행에서만 ACME 서버 TLS 검증 비활성화
-  (비보안 오버라이드). 일반적인 managed onboarding 흐름에서는 첫
-  `bootroot-agent` 실행 전에 trust가 준비되므로 처음부터 검증을 켤 수
-  있습니다.
+- bootroot-agent는 ACME 서버 인증서를 항상 검증하며, 이를 끄는 플래그는
+  없습니다. 일반적인 managed onboarding 흐름에서는 첫 `bootroot-agent`
+  실행 전에 trust가 준비되므로, 첫 실행부터 이미 반영된 자료로 검증합니다.
 
 #### CA 번들 소비 서비스 권한
 
@@ -618,20 +617,35 @@ mTLS를 사용하는 서비스는 `trust.ca_bundle_path`에 저장되는 CA 번
 bootroot-agent에는 컨테이너 이미지가 없습니다. 항상 호스트 프로세스로
 실행되므로 `docker compose up` 대상이 존재하지 않습니다. compose 스택을
 상대로 **1회 발급**(`--oneshot`)을 확인하려면 바이너리를 빌드한 뒤 스택이
-호스트에 게시한 포트로 연결합니다:
+호스트에 게시한 포트로 연결합니다.
+
+compose 스택의 CA는 자체 서명이고 이를 건너뛰는 수단은 없으므로, 배포가
+가진 인증서로 trust 자료를 먼저 준비합니다:
+
+```bash
+mkdir -p certs
+cat secrets/certs/root_ca.crt secrets/certs/intermediate_ca.crt \
+  > certs/compose-ca-bundle.pem
+for cert in secrets/certs/root_ca.crt secrets/certs/intermediate_ca.crt; do
+  openssl x509 -in "$cert" -noout -fingerprint -sha256 \
+    | cut -d= -f2 | tr -d ':' | tr 'A-Z' 'a-z'
+done
+```
+
+출력된 두 지문을 `agent.toml.compose`의 `trust.trusted_ca_sha256`에 넣은 뒤
+실행합니다:
 
 ```bash
 cargo build --bin bootroot-agent
-./target/debug/bootroot-agent --oneshot --insecure --config agent.toml.compose
+./target/debug/bootroot-agent --oneshot --config agent.toml.compose
 ```
 
 `agent.toml.compose`는 바로 이 실행 모델(네이티브 바이너리가 `localhost`로
-compose 스택에 접속)을 위한 설정입니다. compose 스택의 CA는 자체 서명이고
-이 설정에는 trust 번들이 없으므로 `--insecure`가 필요합니다. managed
-onboarding 흐름은 trust를 먼저 준비하므로 이 옵션이 필요하지 않습니다.
-데모/스모크 경로일 뿐 온보딩 경로가 **아니며**, 운영 서비스는 위에서 설명한
-대로 `bootroot service add`가 작성한 설정으로 bootroot-agent 호스트 데몬을
-실행합니다.
+compose 스택에 접속)을 위한 설정이며, 위에서 준비한 번들과 핀으로 step-ca를
+검증합니다. 데모/스모크 경로일 뿐 온보딩 경로가 **아니며**, 운영 서비스는
+위에서 설명한 대로 `bootroot service add`가 작성한 설정으로 bootroot-agent
+호스트 데몬을 실행합니다. `bootroot service add`도 같은 trust 두 값을
+준비해 줍니다.
 
 `scripts/preflight/extra/agent-scenarios.sh`도 동일한 바이너리를 같은 방식으로
 실행합니다.

diff --git a/docs/ko/operations.md b/docs/ko/operations.md
@@ -3087,8 +3087,8 @@ bootroot rotate \
 - bootroot-agent는 기본적으로 ACME 서버(step-ca)의 TLS 인증서를
   검증합니다. trust 설정이 있으면 관리되는 번들과 지문을 사용하고,
   없으면 시스템 CA 저장소를 사용합니다.
-- CLI 오버라이드: `bootroot-agent --insecure`
-  (해당 실행에서만 검증 비활성화).
+- 이 검증을 비활성화하는 CLI 오버라이드는 없습니다. trust 자료가 없거나
+  잘못된 실행은 검증 없이 진행되지 않고 핸드셰이크에서 실패합니다.
 - managed onboarding 흐름에서는 첫 `bootroot-agent` 실행 전에 trust를
   준비합니다.
   - `local-file`: `bootroot service add`가 trust 설정과

diff --git a/docs/ko/troubleshooting.md b/docs/ko/troubleshooting.md
@@ -247,7 +247,10 @@ bootroot service add \
 
 - `server` URL이 `https://`인지 확인 (`http://` 거부)
 - 시스템 trust 또는 `trust.ca_bundle_path`가 올바른지 확인
-- 임시 진단 용도로만 `bootroot-agent --insecure` 사용 (운영 비권장)
+- 검증은 끌 수 없습니다. trust 앵커, 인증서 SAN, 시계를 바로잡습니다.
+  에이전트에 설정한 앵커가 ACME 서버 인증서를 서명한 앵커와 같은지
+  확인하세요:
+  `openssl s_client -connect <host>:<port> -showcerts </dev/null`
 
 ### `rotate infra-cert`가 `permission denied`로 실패 (이전 빌드)