Vault: publish and verify two consumers
On eligible Pro/Team workspaces, publish one certificate to your Vault KV v2, deploy that version to two Linux consumers, and check both live services. The issuing agent owns issuance/renewal; consumers retrieve the published version instead of issuing certificates themselves. TokenTimer coordinates jobs and stores public evidence, not the bundle's private key.
The video shows self-hosted TokenTimer. Cloud 0.18 uses the shared setup guide with hosted plan and delivery rules; follow the Cloud-specific steps below.
Before you start
Check Certificate Management → Settings → Job approval. With approval off, one authorized operator can perform publication and rollout. When approval is required by workspace policy or explicitly requested for a job, arrange another authorized manager to review it before execution.
Use a reachable HTTPS Vault with a KV v2 mount, DNS/CA access for the issuer, and distinct enrolled issuer and consumer identities. An existing web service and TLS listener are needed only for service delivery. Files-only delivery requires the matching updated API/worker and consumer-agent build; older agents reject its installed policy before changing files. Keep the selected workspace throughout. Cloud operates the control-plane worker and applies its plan/workspace admission rules.
Start the Cloud setup guide with Share one certificate across servers with Vault → Linux server. Select your existing issuer agent where appropriate. Merge local policy without dropping identity, write paths, reload rights or trust configuration.
Allocate the group and configure the hosts
Complete Turn on execution safely → Send a test job for the issuer, then use the Vault step's inline signed test for each consumer. Start with execution.enabled: true and execution.dryRun: true; inspect the completed timeline and read-only Agent output in the guide. This checks signed dispatch/reporting, not publication or deployment permissions. Before allocating the publication, stop the issuer service or disable its polling (execution.enabled: false) while preparing the group.
The publication job returns the real group ID used by its policies. Do not invent an unrelated group ID. Holding polling prevents an approval-disabled publication being claimed before that ID is configured; dryRun: true alone does not hold a queued real job.
- Job approval on: create the pending publication once, keep it unapproved while preparing the group, then have a different authorized manager approve it after readiness checks.
- Job approval off: do not assume submission will wait. Keep issuer execution disabled while allocating the first publication, until the returned group is applied and checks are complete. Only enable publication deliberately.
Use the group-scoped store/binding configuration and separate Vault Agent roles on the actual hosts. At Prepare the consumer server, choose Distribute certificate files only or Distribute and reload a service before assigning consumers. Check the local store alias, group, profile, allowed paths and token sink. File-only bindings omit reload commands and listener probes. Service delivery also needs allowlisted validate/reload commands and TLS probes. Each consumer needs its own credentials and binding authorization revision. Keep SecretIDs, tokens and private keys out of dashboard/API requests and terminal output.
In the Vault GUI, inspect the KV v2 engine and the actual policies: issuer create/read, each consumer read-only within the intended group's bundle path. Authenticate through your normal administrator method. This view complements the host setup; it does not install the TokenTimer agent or replace Vault Agent configuration.
Publish and inspect one version
Once the returned group, local policy and Vault access are ready, set issuer execution.enabled: true and execution.dryRun: false, then restart the agent. Complete the original publication under the workspace's actual approval policy. Do not enable polling with dry-run protection merely to repeat a no-op while the real publication is queued: it can claim and block that job. Follow the publication timeline and read-only Agent output directly in the guide; no Jobs or terminal API handoff is needed for this step.
Confirm the publication's public result, then inspect the corresponding Vault object's version metadata/history. Use version metadata for status checks; bundle Data or raw JSON contains private-key material. A published object is not a deployment. TokenTimer material version, Vault provider version and rollout generation are separate identifiers.
Assign consumers and deploy the version
In Assign consumers and deploy, assign the first consumer, then use Additional consumer → Add consumer for the second. Give each local deployment profile a distinct name. Copy each returned binding and authorization revision into that host's matching configuration, preserve enrollment, save and restart it. Run its signed test in the guide before enabling real execution, and confirm the saved configuration after restarting. Keep destinations, credentials, reload commands and TLS probes host-local; the confirmation records your action and is not deployment evidence.
Choose Published certificate version, review Maximum parallel deployments, then choose Deploy the selected version. Follow the rollout request and each consumer's deployment timeline and Agent output inside onboarding. With workspace Job approval off, the rollout starts without a second user; with approval on, another authorized manager must approve it through the existing Jobs review surface. Child-job approval follows the same workspace policy. Require All selected consumers installed for file-only delivery, or All selected consumers verified for service delivery. Files installed is not proof of live use; make independent live checks when a service is configured. A successful coordinator request alone does not prove installation. The API reference remains available for automation and advanced recovery.
To hold a particular rollout even with Job approval off, set requiresApproval: true in the API request. Workspace-forced approval cannot be bypassed with false; separately gated consumer jobs still require their own decisions.
Verify both consumers
For file-only delivery, inspect each installed certificate/key pair and its installation evidence; no listener is asserted. For service delivery, inspect each deployment/validation/reload result. Use two fresh independent TLS checks against the two concrete listeners, with hostname/SNI and trusted CA validation. Both must serve the intended published identity; do not reuse one endpoint's observation as proof for the other.
In Certificates → certificate → Deployments, compare desired/current versions and verification freshness. Renewals contains the source profile, not proof of all consumer rollouts. Keep published → deployed → verified in use distinct. A later issuer renewal publishes new material; distribution of it remains a separate rollout under the workspace approval policy. Keep Job approval off for unattended execution; publishing a renewed version does not automatically request a new rollout.
The publication step checks only the issuing agent. A consumer does not have to be registered yet. Complete the issuer signed test, stop only its TokenTimer service and confirm that stop before creating the publication job; this prevents an approval-disabled job being claimed while preparing Vault. Select and check the real consumer in Assign consumers and deploy (part 6) after its host configuration is ready. Changing Job approval does not release jobs already waiting for approval.