Files
certctl/docs
shankar0123 a849c8b8cf fix(security): close BUNDLE 2 — safe first run, demo mode, agent bootstrap
Bundle 2 closure (2026-05-12 acquisition diligence audit). Closes the
"docker compose up == accidental production" hazard: pre-Bundle-2 the
base deploy/docker-compose.yml WAS the demo path (AUTH_TYPE=none +
DEMO_MODE_ACK=true + KEYGEN_MODE=server + DEMO_SEED=true + literal
change-me-... placeholder creds), the README claimed "drop the demo
overlay for a clean install", and ENVIRONMENTS.md table documented
auth-type default as api-key — three contradictory stories layered on
the same compose file.

Source findings closed:
  R2 R3 C1 D9 finding-2 S9               (repo audit)
  SEC-H2 SEC-M1 SEC-M3 OPS-M3 LOW-5 HIGH-6 (cowork audit)

Compose split (deploy/docker-compose.yml + deploy/docker-compose.demo.yml):
The base now ships production-shaped — no AUTH_TYPE override, no
KEYGEN_MODE override, no DEMO_MODE_ACK, no DEMO_SEED, no literal
placeholder fallbacks. POSTGRES_PASSWORD / CERTCTL_AUTH_SECRET /
CERTCTL_CONFIG_ENCRYPTION_KEY / CERTCTL_API_KEY / CERTCTL_AGENT_ID
must come from deploy/.env (sample template in deploy/.env.example +
root .env.example). The demo overlay carries the full demo posture
(every env var + every placeholder credential) so the
`-f docker-compose.demo.yml` one-flag flip remains a zero-config
populated-dashboard path.

Fail-closed startup guards (internal/config/config.go::Validate):
Three new gates layered on the existing HIGH-12 demo-mode listen-bind
guard. All three exempt CERTCTL_DEMO_MODE_ACK=true so the demo overlay
keeps working:
  • HIGH-6:  AUTH_SECRET = "change-me-in-production"        → refuse
  • HIGH-6:  CONFIG_ENCRYPTION_KEY = "change-me-32-char..." → refuse
  • LOW-5:   CORS_ORIGINS contains "*"  (CWE-942 + CWE-352) → refuse

Visible DEMO MODE banner (cmd/server/main.go): every boot under
DEMO_MODE_ACK=true now emits a prominent WARN line with a 6-step
production-promotion checklist. The 2026-04-19 incident (a screenshot
run that kept running for three days) drove this; the per-startup
banner makes the posture unmissable in any log scraper.

Agent enrollment doc alignment:
  • docs/reference/configuration.md L83: corrected the non-existent
    URL `POST /api/v1/agents/register` to the real route
    `POST /api/v1/agents`; added the bootstrap-token note and the
    install-agent.sh handoff sequence.
  • docs/reference/architecture.md L154: replaced "agents register
    themselves at first heartbeat" (false — cmd/agent/main.go fail-
    fasts when CERTCTL_AGENT_ID is unset) with the actual two-step
    operator-driven flow (REST or GUI registration first, returned ID
    fed to install-agent.sh second).

Tests + CI guard:
  • 9 new TestValidate_Bundle2_* cases in internal/config/config_test.go
    covering: placeholder-secret refused + demo-ack exempt; placeholder
    encryption-key refused + demo-ack exempt; real key not mistaken for
    placeholder; wildcard CORS refused + demo-ack exempt; wildcard mixed
    into a concrete allowlist still refused; concrete allowlist accepted.
  • scripts/ci-guards/B2-compose-base-no-demo-env.sh: greps the base
    compose for any of the demo-mode env vars + placeholder credentials.
    Comments stripped before checking so the narrative header in the
    base file can still reference the overlay's posture in prose.

Cold-DB CI smoke (.github/workflows/ci.yml::cold-db-compose-smoke):
Switched to layering -f docker-compose.demo.yml on top of the base —
the new production base requires real env vars the smoke doesn't have,
and the smoke's purpose (catch migration-on-cold-DB regressions + the
bootstrap-token mint path) is orthogonal to which auth posture the
boot lands in.

Receipts:
  • Current first-run truth table
        compose flag                                  → posture
        -f docker-compose.yml                          (production)
                                                       → requires .env;
                                                       fail-fasts on
                                                       missing AUTH_SECRET
                                                       / CONFIG_ENCRYPTION
                                                       _KEY / POSTGRES
                                                       _PASSWORD; agent
                                                       fail-fasts on
                                                       missing AGENT_ID
        -f docker-compose.yml -f docker-compose.demo.yml  (demo)
                                                       → zero-config;
                                                       AUTH_TYPE=none +
                                                       DEMO_MODE_ACK=true
                                                       + KEYGEN=server +
                                                       DEMO_SEED=true;
                                                       boot banner WARN
        -f docker-compose.yml -f docker-compose.dev.yml   (dev)
                                                       → base + PgAdmin
                                                       + debug logging
        -f docker-compose.test.yml                     (test, standalone)
                                                       → production-shape
                                                       posture, real CA
                                                       backends
  • Verification (PATH=/tmp/go/bin export GO* paths to /tmp):
        gofmt -l                                      # clean (no diffs)
        go vet ./internal/config ./cmd/server         # clean
        go test -short -count=1 ./internal/config/... # PASS (cumulative +
                                                       all 9 new Bundle 2
                                                       cases green)
        go test -short -count=1                       # PASS (no regression
            ./internal/connector/target/configcheck    in the Bundle 1 -
                                                       closure tests)
        go build ./cmd/server ./cmd/agent             # clean
            ./cmd/cli ./cmd/mcp-server
        bash scripts/ci-guards/B2-compose-base-no-demo-env.sh  # clean
        bash scripts/ci-guards/H-1-encryption-key-min-length.sh # clean
        bash scripts/ci-guards/G-3-env-docs-drift.sh           # clean

Remaining operator warnings (not blocking; tracked in CLAUDE.md
"Open decisions"):
  • The first `docker compose -f docker-compose.yml up -d` against a
    pre-Bundle-2 .env (placeholder values still in place) will now
    fail-fast. This is the intended posture but operators upgrading
    from v2.0.x via .env-from-old-master need to rotate before
    upgrading. The CHANGELOG note for the v2.1.0 release should
    call this out alongside Auth Bundle 2's other breaking changes.

Audit-Closes: BUNDLE-2 R2 R3 C1 D9 S9 SEC-H2 SEC-M1 SEC-M3 OPS-M3 LOW-5 HIGH-6
2026-05-13 00:14:59 +00:00
..

certctl Documentation

Last reviewed: 2026-05-12

The full docs index, organized by audience. Pick the section that matches what you need to do; each link below opens a focused doc rather than a wall of text.

For the elevator pitch and quickstart commands, see the repo README.md at the root. For the marketing site, see certctl.io.


Getting Started

You're new to certctl, just cloned the repo, or want to understand what it does before installing.

Doc What it covers
Concepts TLS certificates explained for beginners — CAs, ACME, EST, private keys, the full glossary
Quickstart Five-minute setup with Docker Compose, dashboard tour, API tour
Examples Five turnkey scenarios — ACME+NGINX, wildcard DNS-01, private CA+Traefik, step-ca+HAProxy, multi-issuer
Advanced demo End-to-end certificate lifecycle with technical depth at each step
Why certctl Positioning vs ACME clients, agent-based SaaS, enterprise platforms; when to look elsewhere

Reference

You're operating certctl in production or building integrations and need authoritative technical detail.

Doc What it covers
Architecture System design, data flow, security model, deployment topologies
Profiles CertificateProfile policy object — issuer wiring, EKUs, RequiresApproval gate (with profile-edit closure)
API OpenAPI 3.1 spec, integration patterns, client SDK generation
CLI certctl-cli command reference and CI/CD integration patterns
Configuration CERTCTL_* environment variable reference (scheduler, rate limits, deploy verify, audit, agent)
MCP server Model Context Protocol integration for AI assistants
Release verification Cosign / SLSA / SBOM verification procedure
Intermediate CA hierarchy Multi-level CA tree management — RFC 5280 §3.2/§4.2.1.9/§4.2.1.10 enforcement
Auth standards implemented RFC + CWE evidence for the API-key + RBAC + OIDC + sessions + break-glass surface (NOT a compliance-mapping doc)
Deployment model Atomic write, post-deploy verify, rollback semantics across all targets
Vendor matrix Tested vendor versions per target connector

Connectors

The connector index is the canonical catalog (interfaces, registry, scanners, plus an inline reference per built-in). Per-connector deep-dive siblings cover operator-grade material — vendor edges, troubleshooting, rotation playbooks, when-to-use vs alternatives.

Issuers (13 deep-dives): ACME · ADCS · AWS ACM Private CA · DigiCert · EJBCA / Keyfactor · Entrust · GlobalSign Atlas HVCA · Google CAS · Local CA · OpenSSL / Custom CA · Sectigo SCM · step-ca / Smallstep · Vault PKI

Targets (15 deep-dives): Apache · AWS Certificate Manager · Azure Key Vault · Caddy · Envoy · F5 BIG-IP · HAProxy · IIS · Java Keystore · Kubernetes Secrets · NGINX · Postfix / Dovecot · SSH (agentless) · Traefik · Windows Certificate Store

Protocols

Doc What it covers
ACME server Run certctl as an RFC 8555 + RFC 9773 ARI ACME server
ACME server threat model Security posture for the ACME server endpoint
SCEP server RFC 8894 native SCEP server — RA cert config, multi-profile dispatch, must-staple, mTLS sibling route
SCEP for Microsoft Intune Intune-specific deployment guide — NDES replacement playbook
EST server RFC 7030 EST server — 802.1X / Wi-Fi enrollment, IoT bootstrap, channel binding
CRL & OCSP RFC 5280 CRL + RFC 6960 OCSP responder for relying parties
Async CA polling Bounded polling for async-CA issuer connectors

Operator

You're running certctl in production and need operational guidance.

Doc What it covers
Security posture Auth, rate limits, encryption at rest, key rotation, RBAC + OIDC + sessions + break-glass, bootstrap
RBAC operator reference Roles, permissions, scopes, scope-down + day-0 bootstrap
Auth threat model API-key + RBAC + OIDC + sessions + break-glass — token forgery, session hijacking, IdP compromise, role-grant abuse, bootstrap-token leak, audit-mutation
OIDC / SSO runbooks Per-IdP setup guides — Keycloak, Authentik, Okta, Auth0, Entra ID, Google Workspace
Control plane TLS Self-signed bootstrap, operator-supplied Secret, cert-manager Certificate CR
Database TLS PostgreSQL transport encryption
Approval workflow Two-person integrity gate for high-stakes issuance + profile-edit closure
Helm deployment Kubernetes installation via the bundled chart
Performance baselines Operator-runnable benchmarks for regression spot checks
Auth benchmarks Session + OIDC validation p99 targets and measured baselines
Legacy clients (TLS 1.2) Reverse-proxy runbook for embedded EST/SCEP clients on TLS 1.2

Runbooks

Runbook When
Cloud targets AWS ACM + Azure Key Vault deployment, debugging, rollback
Expiry alerts Per-policy multi-channel routing matrix, severity tiers
Disaster recovery CRL cache, OCSP responder cert, CA private-key rotation, Postgres restore

Migration

You're moving from another cert-management tool to certctl, or running both in parallel.

From Doc
Certbot migration/from-certbot.md
acme.sh migration/from-acmesh.md
cert-manager (coexistence, not replacement) migration/cert-manager-coexistence.md
Caddy ACME (point Caddy at certctl) migration/acme-from-caddy.md
cert-manager ACME (point cert-manager at certctl) migration/acme-from-cert-manager.md
Traefik ACME (point Traefik at certctl) migration/acme-from-traefik.md
API keys → RBAC (v2.0.x → v2.1.0) migration/api-keys-to-rbac.mdAUDIT YOUR API KEYS post-upgrade
Enable OIDC SSO migration/oidc-enable.md — step-by-step OIDC onboarding for an existing API-key + RBAC deployment

Contributor

You're contributing to certctl, running tests locally, or trying to understand the CI pipeline.

Doc What it covers
Testing strategy What we test and why; per-PR fast gates vs daily deep-scan
Test environment Local environment with real CAs (Pebble, step-ca, etc.)
QA prerequisites Before running QA: stack boot, demo data baseline, env vars
QA test suite qa_test.go reference for release QA
GUI QA checklist Manual GUI verification pass for release
Release sign-off Release-day checklist — code state, automated gates, manual QA, artefact verification
CI pipeline CI shape, regression guards, adding new checks
CI guards Per-class CI guards (code-shape, contract-parity, build/dep, operational); how to add one

Archive

Historical docs preserved for reference. Most operators don't need these.

Doc Why archived
Upgrade to TLS (v2.2) Pre-v2.2 HTTPS-everywhere upgrade procedure
Upgrade past v2 JWT removal G-1 milestone JWT auth removal procedure

Reading order by role

First-time operator: ConceptsQuickstartExamples. About 90 minutes end to end.

Production operator: ArchitectureSecurity postureControl plane TLSDisaster recovery runbook. About 4 hours end to end.

PKI engineer: ACME serverSCEP serverEST serverIntermediate CA hierarchy. About 6 hours end to end.

Contributor: ArchitectureTesting strategyTest environmentCI pipeline. About 3 hours end to end.