6.3 Certificate & Password Lifecycle Management in VCF Operations

6.3 Certificate & Password Lifecycle Management in VCF Operations

Exam Focus: Security governance in an enterprise private cloud demands strict cryptographic integrity and disciplined credential rotation. For the VCP-VCF (2V0-17.25) exam, you must master centralized certificate lifecycle management across the VCF fleet, understand the three supported Certificate Authority (CA) operational modes (Microsoft ADCS, OpenSSL, and Custom External CA), and adhere to Subject Alternative Name (SAN) and PEM chain requirements. Furthermore, you must understand the encrypted credential store architecture, know the distinction between password rotation and password remediation, and know how to recover when an out-of-band credential modification occurs.

[!IMPORTANT] Where this lives in VCF 9.0. Broadcom moved the fleet-wide management surface in VMware Cloud Foundation 9.0. VCF Operations provides the fleet management capabilities — fleet extension, lifecycle, certificate, and password management. SDDC Manager still exists as a per-instance component and can still perform several of these tasks, but the SDDC Manager UI is deprecated and is slated for removal in a future major release, its lifecycle management APIs have moved to VCF Operations, and its identity-configuration APIs are deprecated in favour of VCF Operations. When an exam item asks where a fleet-wide task is performed in 9.0, VCF Operations is the current answer; treat SDDC Manager as the legacy surface that remains for compatibility.

---

Centralized Certificate Management Across the VCF Fleet

In a standalone virtualization deployment, administrators commonly replace Secure Sockets Layer (SSL) certificates by logging into individual appliance management consoles—such as the vCenter Server Appliance Management Interface (VAMI on port 5480) or NSX Manager APIs. In a VMware Cloud Foundation environment, this direct, manual approach is strictly forbidden.

The VCF management plane — VCF Operations for fleet-wide certificate management in 9.0, with SDDC Manager retained per instance — operates as the central orchestrator and authority for the platform. All core infrastructure components—SDDC Manager itself, vCenter Server instances, NSX Manager clusters, and physical ESXi hosts—participate in a mutually authenticated, cryptographically verified trust web. If an administrator manually replaces a certificate directly on a vCenter Server or NSX appliance, the mutual TLS (mTLS) trust binding with SDDC Manager breaks instantly. As a result:

• SDDC Manager loses API communication with the endpoint.
• Inventory tracking and health telemetry fail.
• All subsequent Lifecycle Management (LCM) pre-checks, upgrades, host commissioning, and cluster expansions are permanently blocked.

Therefore, all certificate generation, installation, and renewal operations across the VCF stack must be driven through the VCF management plane rather than through individual appliance consoles. In VCF 9.0 that means VCF Operations fleet management for fleet-wide certificate operations, with SDDC Manager remaining available per instance. What is never supported is bypassing both and editing a certificate directly on a vCenter or NSX appliance.

---

Supported Certificate Authority (CA) Modes

SDDC Manager provides three distinct Certificate Authority operational modes to accommodate enterprise PKI requirements:

1. Microsoft Active Directory Certificate Services (ADCS)

For enterprise environments utilizing Microsoft Windows PKI, SDDC Manager features native direct API integration with Microsoft ADCS:

• Hands-Off Automation: Once configured with ADCS connection details, an authorized service account, and an enterprise certificate template (e.g., VMware-Certificate-Template), SDDC Manager completely automates the certificate lifecycle.
• Workflow: SDDC Manager generates the private key and Certificate Signing Request (CSR), transmits the CSR to ADCS via remote procedure call (RPC) or HTTP web enrollment, retrieves the newly signed X.509 v3 certificate, validates the chain, and installs it onto the target endpoint without any manual file export or administrative handling.

2. Built-in OpenSSL CA (Development / POC Mode)

SDDC Manager includes an internal OpenSSL Certificate Authority engine:

• Use Case: Engineered strictly for non-production environments, proof-of-concept labs, and isolated staging environments where an enterprise PKI infrastructure is unavailable.
• Characteristics: SDDC Manager automatically generates root CA keys and signs component certificates locally. Because these certificates are signed by an untrusted internal CA, client web browsers will display security warnings unless the SDDC Manager root CA certificate is manually imported into client operating system truststores.

3. Custom External Certificate Authority (Enterprise CA / Public Third-Party CA)

Most enterprise security policies mandate that production certificates be signed by an official corporate Certificate Authority (e.g., an offline Root CA, an internal HashiCorp Vault PKI, or a trusted commercial public CA such as DigiCert or Sectigo). SDDC Manager supports an asynchronous CSR generation and upload workflow.

External Certificate Authority Replacement Workflow:

┌──────────────────────┐      ┌──────────────────────┐      ┌──────────────────────┐      ┌──────────────────────┐
│ 1. Generate CSR in   │ ───> │ 2. Sign with Ext CA  │ ───> │ 3. Assemble Chain    │ ───> │ 4. Validate & Deploy │
│    SDDC Manager      │      │ - Enterprise PKI /   │      │ - Server Leaf Cert   │      │ - Pre-check Checks   │
│ - Define SANs/VIPs   │      │   DigiCert / Vault   │      │ - Intermediate CAs   │      │ - Sequential Rolling │
│ - RSA 2048/4096-bit  │      │ - SHA-256 Signature  │      │ - Root CA (PEM fmt)  │      │   Appliance Installs │
└──────────────────────┘      └──────────────────────┘      └──────────────────────┘      └──────────────────────┘

---

Certificate Requirements, Chain Assembly, & Validation

When implementing custom external certificates, administrators must adhere to precise cryptographic specifications to prevent validation engine rejections.

Subject Alternative Name (SAN) Rules

Modern web browsers, operating systems, and VMware APIs reject certificates that rely solely on the Common Name (CN) attribute. Certificates generated by SDDC Manager enforce strict Subject Alternative Name (SAN) definitions:

• The primary Fully Qualified Domain Name (FQDN) of the appliance (e.g., vcenter-mgmt.corp.local).
• The short hostname (NetBIOS name) of the appliance (e.g., vcenter-mgmt).
• The management IP address of the appliance.
• Load-Balanced Virtual IPs (VIPs): For clustered components such as NSX Manager clusters, the certificate SAN must include the FQDNs and IP addresses of all individual node members plus the FQDN and IP address of the NSX Virtual IP (VIP) or external load balancer.

Cryptographic Specifications

• Key Algorithm & Length: RSA with a minimum key length of 2048 bits (3072-bit or 4096-bit recommended for high-security environments). Elliptic Curve Cryptography (ECC) is not universally supported across all legacy subcomponents.
• Signature Algorithm: SHA-256 or stronger (sha256WithRSAEncryption). Legacy algorithms such as SHA-1 or MD5 are strictly rejected.
• Key Usage Attributes: Must include Digital Signature, Key Encipherment, and Data Encipherment.
• Extended Key Usage (EKU): Must include both Server Authentication (1.3.6.1.5.5.7.3.1) and Client Authentication (1.3.6.1.5.5.7.3.2) to support mutual TLS communication between management daemons.

Assembling the Complete PEM Certificate Chain

When uploading signed certificates back into SDDC Manager, the certificate file must be formatted in Base64 ASCII (PEM format) and contain the complete, unbroken trust chain in strict sequential order:

-----BEGIN CERTIFICATE-----
[Server / Leaf Certificate for the specific VCF Endpoint]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Intermediate / Issuing CA Certificate]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Root CA Certificate]
-----END CERTIFICATE-----

[!CAUTION] The Broken Certificate Chain Trap: Uploading only the server leaf certificate without the intermediate and root CA certificates will cause the SDDC Manager validation engine to abort the installation. The validation engine performs a cryptographic chain walk; if any certificate in the hierarchy is missing, expired, or improperly ordered, the replacement task is cancelled to protect system stability.

Orchestrated Installation Sequence

Once validation completes successfully, SDDC Manager coordinates the rolling replacement of certificates across the target domain. It installs certificates, restarts the respective services (e.g., vpxd on vCenter, reverse proxies on SDDC Manager, and management daemons on NSX), validates port availability, and re-establishes API sessions without manual intervention.

---

Centralized Password Management Architecture

Password governance across dozens of virtual appliances and physical servers represents a major operational vulnerability if left to manual spreadsheets. SDDC Manager includes an enterprise-grade Credential Store that centralizes, encrypts, rotates, and remediates passwords across the entire infrastructure lifecycle.

Credential Store Architecture

• Encrypted Database: All system passwords, service account credentials, and recovery keys are maintained inside a dedicated, hardened PostgreSQL database residing on the SDDC Manager appliance.
• AES-256 Encryption: Stored credentials are encrypted at rest using industry-standard AES-256 encryption. The master cryptographic encryption keys are protected within an internal keystore, preventing extraction even in the event of an appliance snapshot compromise.

Account Classifications Managed by SDDC Manager

---

Password Lifecycle Operations: Rotation vs. Remediation

Candidates must understand the operational distinction between Password Rotation and Password Remediation.

Password Management Operational Distinction:

   ┌────────────────────────────────────────────────────────┐
   │                Password Rotation Task                  │
   │ - Scheduled policy (e.g., every 90 days) or On-Demand  │
   │ - SDDC Manager generates random high-entropy password   │
   │ - Logs into endpoint using CURRENT known password      │
   │ - Updates endpoint password AND encrypted store        │
   └────────────────────────────────────────────────────────┘

   ┌────────────────────────────────────────────────────────┐
   │               Password Remediation Task                │
   │ - Triggered after an OUT-OF-BAND password change       │
   │   (e.g., admin reset root via DCUI, VAMI, or SSH)      │
   │ - SDDC Manager stored credential is DESYNCHRONIZED     │
   │ - Admin supplies active out-of-band password           │
   │ - SDDC Manager tests connection & updates stored cred  │
   └────────────────────────────────────────────────────────┘

1. Automated & Scheduled Password Rotation

Password rotation is a proactive security measure designed to limit credential exposure windows:

• Automated Schedules: Administrators can configure rotation policies (e.g., mandatory rotation every 90 or 180 days) conforming to enterprise compliance frameworks.
• Complexity Enforcement: SDDC Manager enforces strict password complexity rules: minimum length (12-14 characters), uppercase letters, lowercase letters, numeric digits, and special characters. It automatically filters out shell-restricted characters (such as $, \, or ") that could corrupt background automation scripts.
• Execution Workflow: During a scheduled or manual rotation, SDDC Manager authenticates to the target component using the currently synchronized password, generates a cryptographically random new password, issues the API command to change the password on the endpoint, verifies the new credential, and updates its internal AES-256 encrypted database.

2. Password Remediation Workflow (Fixing Desynchronization)

In real-world enterprise operations, emergency troubleshooting sometimes requires an administrator to change a credential out-of-band—for example, resetting an ESXi host root password via the Direct Console User Interface (DCUI) after a network isolation incident, or resetting the vCenter root password via the VAMI (port 5480) when a console session expires.

When an out-of-band change occurs:

• SDDC Manager's stored credential becomes desynchronized from the actual active password on the endpoint.
• Subsequent automated health checks, LCM pre-checks, automated backups, and cluster expansion workflows fail.
• Attempting a Password Rotation will FAIL: Because SDDC Manager attempts to authenticate using its outdated stored credential, the rotation task is rejected by the endpoint.

[!IMPORTANT] The Password Remediation Solution: To recover from an out-of-band credential modification, the administrator must execute the Remediate Password workflow in SDDC Manager:

1. In SDDC Manager, navigate to Administration > Password Management.
2. Locate the desynchronized account and select Remediate.
3. Enter the new out-of-band password that was configured directly on the endpoint.
4. SDDC Manager connects to the endpoint using the supplied credential, validates authentication, updates its internal encrypted credential store, and clears the synchronization alert.
5. Full automated lifecycle and monitoring operations are restored instantly.