VMware vCenter Certificate Automation

SSL Nexus can manage the vCenter Machine SSL certificate through the native vCenter REST API. R13 uses a two-stage external-CA workflow so vCenter generates and retains the private key while SSL Nexus handles the CSR, CA order, signed certificate return and lifecycle tracking.

Prerequisites

• HTTPS management reachability from SSL Nexus to the vCenter appliance, normally TCP 443.
• A dedicated vCenter service identity with the privileges required for TLS CSR generation and Machine SSL certificate replacement.
• The vCenter FQDN that clients and administrators actually use.
• Certificate subject information required by the CSR workflow, including organisation, locality, state/province, two-letter country code and CSR email address.
• A target-bound CA profile configured in SSL Nexus.

Add A VMware vCenter Target

1. Open Deployment targets and choose Add target.
2. Select platform Network and application VMware vCenter.
3. Enter the vCenter FQDN/address, HTTPS API port, API username and password.
4. Enter the CSR email address.
5. Select the RSA key size: 2048, 3072 or 4096 bits. R13 defaults to 3072 bits.
6. Select and configure the CA adapter for this target, then save.

Test Connection

Test connection creates a vCenter API session and reads the vCenter TLS certificate-management endpoint without changing the certificate. A successful result confirms management reachability and the saved credentials. Test CA remains a separate health check for the target-bound certificate authority.

Private Key Stays In vCenter

During phase one, SSL Nexus asks vCenter to generate the Machine SSL CSR. The private key is created and retained by vCenter. SSL Nexus receives only the CSR, submits it to the selected CA, and later returns the signed certificate. The deployment binding records the Machine SSL object and notes that the private key resides in vCenter rather than the SSL Nexus secret store.

Two-Stage Deployment Workflow

1. SSL Nexus authenticates to vCenter and requests a Machine SSL CSR using the certificate identity and SANs.
2. The CSR is queued through the normal SSL Nexus CA lifecycle.
3. After the CA returns the signed certificate, SSL Nexus creates a new vCenter API session and submits the certificate to the Machine SSL TLS endpoint.
4. vCenter replaces the certificate and its services may restart as part of activation.
5. SSL Nexus waits for the management API to return, authenticates again and reads the active TLS certificate endpoint to confirm the appliance recovered.
6. The managed certificate remains bound to this vCenter target for later renewals.

Trust-Chain Planning

Certificate replacement can introduce a new issuing chain to the vCenter management plane. Make sure administrators, automation systems and any components that validate the vCenter endpoint trust the required CA chain before production deployment. The temporary allow untrusted management certificate target option is a bootstrap aid only and should not become the normal production state.

ESXi Is A Separate Target

R13 intentionally scopes this adapter to the vCenter Machine SSL certificate. ESXi host certificate lifecycle is not silently included. Host certificates have their own VMware certificate-management workflow and should be implemented and validated as a separate first-party target so permissions, failure handling and renewal scope remain explicit.

Production Validation Checklist

• Test connection succeeds with the dedicated service identity.
• Test CA succeeds independently.
• A lab CSR is generated with the expected FQDN, SANs and subject information.
• The private key remains vCenter-held throughout the workflow.
• Machine SSL replacement completes and the vCenter management API returns after activation.
• The live vCenter endpoint presents the expected certificate and trusted chain.
• Recovery/rollback expectations are documented before unattended renewal is enabled.

See also Network Operator role and Deployment targets.