VerticalTrustRolloutStatus

VerticalTrustRolloutStatus
Vertical Certificate Rotation Status

Certificate rotation status for a single vertical. What is visible through this API depends on the vertical (which varies by deployment):

With node-level detail - Per-node rotation progress is tracked and reported. rollout_result reaches COMPLETED_SUCCESSFULLY or COMPLETED_WITH_FAILURES, and node-level arrays (success_nodes, failed_nodes, pending_nodes) are populated when requested via POST /trust/trust-rollout-status.

Start acknowledgment only - Only whether rotation was successfully initiated is recorded; actual progress is managed externally. rollout_result is START_SUCCESSFUL or FAILED_TO_START_ROTATION. Node-level arrays are always empty.

JSON Example
{
    "vertical_key": "string",
    "rollout_result": "string",
    "status_summary": {
        "success_node_count": 0,
        "failed_node_count": 0,
        "pending_node_count": 0
    },
    "success_nodes": [
        {
            "node_display_name": "string",
            "node_id": "string",
            "error_message": "string",
            "update_status": "string"
        }
    ],
    "failed_nodes": [
        {
            "node_display_name": "string",
            "node_id": "string",
            "error_message": "string",
            "update_status": "string"
        }
    ],
    "pending_nodes": [
        {
            "node_display_name": "string",
            "node_id": "string",
            "error_message": "string",
            "update_status": "string"
        }
    ]
}
vertical_key
Required

Identifies a vertical (platform component or integrated service) in the certificate rotation rollout. The set of verticals active in any given rotation depends on the deployment configuration (form factor and which services are deployed and enabled). Use GET /trust/trust-rollout-status to discover which verticals are involved in the current or most recent rotation.

Verticals fall into two behaviorally distinct categories:

With node-level detail - Trust manager tracks per-node rotation progress for these verticals. Their rollout_result reaches COMPLETED_SUCCESSFULLY or COMPLETED_WITH_FAILURES, and node-level arrays (success_nodes, failed_nodes, pending_nodes) are populated.

Start acknowledgment only - Trust manager records only whether rotation was successfully initiated. Actual rotation progress for these verticals is managed externally and is not visible through this API. Their rollout_result is START_SUCCESSFUL or FAILED_TO_START_ROTATION; node-level arrays are always empty.

Which specific verticals fall into which category depends on the deployment configuration. The known values are listed in the enum below.

Key naming conventions:

  • SSP - LicenseHub pushing its CA to remote SSP (ATP) sites it has onboarded.
  • LH - SSP (cluster-api) pushing its ingress certificate update to LicenseHub.
  • NSX - LicenseHub pushing its CA to remote NSX managers.
  • AVI - LicenseHub pushing its CA to remote AVI Copilot sites.
Enumeration: BAREMETALSECURITY, SENSOR, SSP, LH, NSX, AVI
rollout_result
Optional

The terminal result for a single platform vertical's certificate rotation. Only set once the vertical reaches a terminal state; PENDING and START_SUCCESSFUL indicate intermediate states.

For verticals (deployment-specific; trust manager polls directly for node-level status) - these states reflect actual node progress:

  • PENDING - Rotation was successfully initiated; node updates are underway.
  • COMPLETED_SUCCESSFULLY - All nodes successfully rotated their certificates.
  • COMPLETED_WITH_FAILURES - All nodes reached an end state but one or more failed. Node counts in status_summary reflect the actual distribution.
  • CLEANUP_SUCCESSFUL - Post-rotation cleanup (removal of obsolete CA) completed.
  • FAILED_TO_CLEANUP - Rotation completed but cleanup of the obsolete CA failed. Node counts in status_summary are still valid.
  • FAILED_TO_START_ROTATION - Trust Manager could not initiate rotation. Node status counts are not available.

For verticals with start acknowledgment only (deployment-specific) - actual rotation progress is managed externally; node-level arrays are never populated:

  • START_SUCCESSFUL - Rotation was successfully initiated. No further status is tracked through this API.
  • FAILED_TO_START_ROTATION - Trust Manager could not initiate the rotation.
Enumeration: COMPLETED_SUCCESSFULLY, COMPLETED_WITH_FAILURES, CLEANUP_SUCCESSFUL, PENDING, START_SUCCESSFUL, FAILED_TO_START_ROTATION, FAILED_TO_CLEANUP
status_summary
Required

Aggregated node counts for a single vertical's certificate rotation result. Always present in the status response, regardless of whether node-level detail is requested. Use these counts to quickly identify if a vertical has failures without fetching full node details.

success_nodes
Required

Detailed status for each node that successfully completed certificate rotation within this vertical. Only populated when this vertical is included in a POST /trust/trust-rollout-status filter with include_status containing SUCCESS.

failed_nodes
Required

Detailed status for each node where certificate rotation failed within this vertical, including error messages for diagnosis. Only populated when this vertical is included in a POST /trust/trust-rollout-status filter with include_status containing FAILED. Check error_message on each entry for remediation guidance.

pending_nodes
Required

Detailed status for each node where certificate rotation is still in progress or has not yet started within this vertical. Only populated when this vertical is included in a POST /trust/trust-rollout-status filter with include_status containing PENDING.