Fleet PostgreSQL certificate policy

The certificate policy a host applies when stado-database places a new PostgreSQL database.

Before a new PostgreSQL placement, the placement host must declare database.postgres_tls. Its JSON object has two required positive whole-number fields: certificate_days and rsa_bits. They govern both the database's certificate authority and its server certificate; neither has a built-in value.

stado config set database.postgres_tls "$POSTGRES_TLS_JSON"
stado config get database.postgres_tls
stado config validate

WC_DATABASE_POSTGRES_TLS overrides that document with the same JSON shape. Configure the host that runs database place, not just the machine that submits database create --host. Stado Desktop's Compute providers configuration operation accepts this dotted key and JSON value on the selected endpoint. Databases → Create… uses that host's policy through the same placement.

Missing policy is refused before initdb or certificate issuance: fleet PostgreSQL TLS policy is not declared: set database.postgres_tls on the placement host with stado config set, or WC_DATABASE_POSTGRES_TLS with its JSON document. Malformed JSON names the override variable. Missing or unknown fields, zero, negative, fractional and out-of-range values are refused with database.postgres_tls must declare positive whole-number certificate_days and rsa_bits and the parser's cause. Configuration writes and config validate use the same parser. OpenSSL remains responsible for accepting the declared key size and validity; its failed operation and error output are retained.

A successful new placement includes tls_policy in its JSON receipt. Existing placements are reused without replacing their certificates or requiring a new policy. Changing the declaration affects later issuance, not existing keys.

Configuration qualification

tests/database/tls-policy.mjs runs the installed CLI with an isolated home and configuration below build/database-tls-policy/. It persists a valid policy, then verifies that invalid writes leave the preceding document unchanged.

STADO_BIN="$CANDIDATE_STADO" \
STADO_TEST_DATABASE_TLS_POLICY="$VALID_POLICY_JSON" \
STADO_TEST_DATABASE_TLS_REFUSALS="$INVALID_POLICIES_JSON" \
node tests/database/tls-policy.mjs

The valid input is the policy object shown above. The refusal input is an array of objects with name and value; value is the complete invalid policy. Required names are missing-days, missing-bits, unknown-member, zero-days, zero-bits, negative-days, fractional-days, text-bits, and null-policy. Each value must exercise the condition its name describes. The journey reads a process's success from the process itself (tests/native/process.mjs), so no exit status is supplied.

The retained run-*/report.json includes the checkout revision and relevant uncommitted changes, test hash, executable version and hash, commands and exit statuses, and persisted before/after documents. An older binary accepting an invalid policy fails the journey.

Source: this website