Vault: publish and verify two consumers
Publish one certificate to your Vault KV v2 and deploy that version to Linux consumers. Choose file delivery alone, or also reload and verify a service. 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.
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. Core and Enterprise need a running CertOps worker; Cloud operates that worker and applies its plan/workspace admission rules.
Start the setup guide with Share one certificate across servers with Vault → Linux server. Select the existing agents where appropriate and 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. Follow the guide's prerequisite/configuration order before submitting. If allocating through the API first, keep issuer execution disabled until the returned group is applied and checks are complete. Only enable publication deliberately.
Use the generated 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.
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.