Many environments haven’t yet moved to VMware Cloud Foundation and still rely on traditional vCenter setups.
In these architectures, certificate management remains a manual task handled through the VMware Certificate Authority.
When not maintained properly, the expiration of internal certificates can break authentication, SSO, and several core services.
Understanding how to approach this before it happens is essential.
The Typical Hybrid Setup
A standard configuration often combines two certificate sources:
- The Machine SSL Certificate, signed by a corporate Microsoft CA, secures external connections to the vCenter (web client, API, SDKs).
- The Solution User Certificates (machine, vpxd, vpxd-extension, hvc, wcp) and the STS certificate are issued by the internal VMCA.
- Additional internal stores like data-encipherment or trusted roots depend entirely on the VMCA.
This hybrid model works well, but it requires special attention when the VMCA root or any dependent certificates approach expiration.
The lifecycle of these internal certificates must be managed separately to avoid service interruptions.
Identifying Certificate Expiration
To review the status of all vCenter certificates, use the vecs-cli utility.
It lists all stores and their certificates with associated validity periods:
vp="/usr/lib/vmware-vmafd/bin/vecs-cli" for s in $($vp store list | grep -Ev "*CRLS"); do echo "[ $s ]" $vp entry list --store $s --text | grep -E "Alias|Not After" done
This command provides an overview of expiration dates across all stores.
If several internal certificates show similar validity periods and are about to expire, it’s time to plan a controlled regeneration.
Why Avoid Using Certificate-Manager in Mixed Environments
certificate-manager can regenerate all certificates managed by the VMCA, including the Machine SSL certificate.
In mixed environments where that certificate is signed by an external CA, running a full regeneration will overwrite it.
To prevent this, use vCert, a Broadcom Python tool designed for selective certificate renewal.
vCert allows administrators to regenerate specific internal certificates without touching the externally signed Machine SSL certificate.
It is particularly useful in environments where the VMCA root must be replaced but the external CA must remain untouched.
Recommended Regeneration Sequence with vCert
When internal certificates are near expiration, the proper order of operations is as follows:
- Regenerate the VMCA root
- Regenerate all Solution User certificates (machine, vpxd, vpxd-extension, hvc, wcp)
- Regenerate the STS certificate
- Restart all vCenter services to reload the new certificates.
Following this sequence ensures that dependencies remain consistent, as each certificate is reissued under the new VMCA root while the Machine SSL certificate remains intact.
Post-Renewal Maintenance
After regenerating certificates, several clean-up tasks are recommended to maintain a healthy VECS environment.
Trusted Roots
Remove obsolete VMCA roots from the TRUSTED_ROOTS store using the procedure described in Broadcom KB 326288.
Outdated certificates can generate unnecessary alarms and complicate future renewals.
STS_INTERNAL_SSL_CERT
Older environments upgraded from vCenter 6.x may still contain the legacy STS_INTERNAL_SSL_CERT store.
Modern versions use the Machine SSL Certificate for STS.
Follow KB 316625 to update the STS configuration in server.xml and delete the obsolete store.
Data Encipherment Certificate
The data-encipherment certificate encrypts sensitive data handled by the vpxd service, including Guest OS customization information.
It is issued by the VMCA but not automatically regenerated.
To renew it, follow the procedure in KB 312152 using certool to generate a new key pair and certificate:
/usr/lib/vmware-vmca/bin/certool --genkey --privkey=/etc/vmware-vpx/ssl/data-encipherment.key --pubkey=/etc/vmware-vpx/ssl/data-encipherment.pub /usr/lib/vmware-vmca/bin/certool --server <vcenter-fqdn> --genCIScert --dataencipherment --privkey=/etc/vmware-vpx/ssl/data-encipherment.key --cert=/etc/vmware-vpx/ssl/data-encipherment.crt --Name=data-encipherment --FQDN=<vcenter-fqdn>
Verification Checklist
After regeneration and cleanup, verify that all certificates are valid and that services are running normally:
/usr/lib/vmware-vmafd/bin/vecs-cli store list /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store <name> --text | grep "Not After" service-control --status --all
The expiration dates should reflect the new validity period, and the browser should continue to display the external SSL certificate chain.
Key Principles to Remember
1. VMCA and Corporate PKI are separate systems.
The VMCA manages internal trust. The corporate PKI secures external access.
Do not let one overwrite the other.
2. Always regenerate in the correct order.
VMCA root → Solution Users → STS → service restart.
Add the Data Encipherment renewal afterward.
3. Audit regularly.
Monitoring certificate validity avoids unexpected downtime and simplifies future maintenance windows.
4. Keep documentation ready.
A clear procedure transforms what could be a crisis into a short, predictable operation.
Conclusion
Until all environments transition to VCF and benefit from automated certificate lifecycle management, maintaining VMCA-based trust chains remains part of an administrator’s job.
Knowing how to regenerate internal certificates, clean legacy stores, and preserve external PKI integration ensures stability and continuity.
When the VMCA eventually reaches the end of its lifetime, following a precise regeneration plan avoids service disruption and keeps the vCenter secure and operational.