If your company policy requires it, you can use the CLI to replace some or all certificates used in vSphere with certificates that are signed by a third-party or enterprise CA. If you do that, VMCA is not in your certificate chain. You are responsible for storing all vCenter certificates in VECS.

You can replace all certificates or use a hybrid solution. For example, consider replacing all certificates that are used for network traffic but leaving VMCA-signed solution user certificates. Solution user certificates are used only for authentication to vCenter Single Sign-On. vCenter Server uses solution user certificates for internal communication only. Solution user certificates are not used for external communication.
Note: If you do not want to use VMCA, you are responsible for replacing all certificates yourself, for provisioning new components with certificates, and for tracking certificate expiration.

Even if you decide to use custom certificates, you can still use the VMware Certificate Manager utility for certificate replacement. See Replace All Certificates with a Custom Certificate Using the Certificate Manager.

If you encounter problems with vSphere Auto Deploy after replacing certificates, see the VMware knowledge base article at https://kb.vmware.com/s/article/2000988.

Request Certificates and Import a Custom Root Certificate Using the CLI

You can use custom certificates from an enterprise or third-party CA. The first step is requesting the certificates from the certificate authority then using the CLI to import the root certificates into VMware Endpoint Certificate Store (VECS).

Prerequisites

The certificate must meet the following requirements:

  • Key size: 2048 bits (minimum) to 8192 bits (maximum) (PEM encoded)
  • PEM format. VMware supports PKCS8 and PKCS1 (RSA keys). When keys are added to VECS, they are converted to PKCS8.
  • x509 version 3
  • For root certificates, the CA extension must be set to true, and the cert sign must be in the list of requirements.
  • SubjectAltName must contain DNS Name=<machine_FQDN>.
  • CRT format
  • Contains the following Key Usages: Digital Signature, Key Encipherment
  • Start time of one day before the current time.
  • CN (and SubjectAltName) set to the host name (or IP address) that the ESXi host has in the vCenter Server inventory.
Note: vSphere's FIPS certificate only validates RSA key sizes of 2048 bits and 3072 bits.

Procedure

  1. Send the Certificate Signing Requests (CSRs) for the following certificates to your enterprise or third-party certificate provider.
    • A machine SSL certificate for each machine. For the machine SSL certificate, the SubjectAltName field must contain the fully qualified domain name (DNS NAME=machine_FQDN).
    • Optionally, five solution user certificates for each node. Solution user certificates do not need to include IP address, host name, or email address. Each certificate must have a different certificate Subject.

    Typically, the result is a PEM file for the trusted chain, plus the signed SSL certificates for each vCenter Server node.

  2. List the TRUSTED_ROOTS and the machine SSL stores. 
    vecs-cli store list
    1. Ensure that the current root certificate and all machine SSL certificates are signed by VMCA.
    2. Note down the Serial number, issuer, and Subject CN fields.
    3. (Optional) With a Web browser, open an HTTPS connection to a node where the certificate is to be replaced, view the certificate information, and ensure that it matches the machine SSL certificate.
  3. Stop all services and start the services that handle certificate creation, propagation, and storage. 
    service-control --stop --all
service-control --start vmafdd
service-control --start vmdird
service-control --start vmcad
  4. Publish the custom root certificate. 
    dir-cli trustedcert publish --cert <my_custom_root>
    If you do not specify a user name and password on the command line, you are prompted.
  5. Restart all services. 
    service-control --start --all

What to do next

You can remove the original VMCA root certificate from the certificate store if your company policy requires it. If you do, you have to refresh the vCenter Single Sign-On certificate. See Replace a vCenter Server STS Certificate Using the Command Line.

Replace Machine SSL Certificates with Custom Certificates Using the CLI

After you receive the custom certificates, you can use the CLI to replace each machine certificate.

You must have the following information before you can start replacing the certificates:
  • Password for administrator@vsphere.local
  • Valid Machine SSL custom certificate (.crt file)
  • Valid Machine SSL custom key (.key file)
  • Valid custom certificate for Root (.crt file)

Prerequisites

You must have received a certificate for each machine from your third-party or enterprise CA.

  • Key size: 2048 bits (minimum) to 8192 bits (maximum) (PEM encoded)
  • CRT format
  • x509 version 3
  • SubjectAltName must contain DNS Name=<machine_FQDN>.
  • Contains the following Key Usages: Digital Signature, Key Encipherment

Perform the steps on each vCenter Server host.

Procedure

  1. Back up the current machine SSL certificate. 
    /usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store MACHINE_SSL_CERT --alias __MACHINE_CERT > oldmachine.crt
/usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store MACHINE_SSL_CERT --alias __MACHINE_CERT > oldmachinekey.key
  2. Log in to each host and add the new machine certificates that you received from the certificate authority to VECS.
    All hosts need the new certificate in the local certificate store to communicate over SSL.
    1. Delete the existing certificate. 
      /usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store MACHINE_SSL_CERT --alias __MACHINE_CERT
    2. Add the new certificate. 
      /usr/lib/vmware-vmafd/bin/vecs-cli entry create --store MACHINE_SSL_CERT --alias __MACHINE_CERT --cert <cert-file-path> --key <key-file-path>
  3. Extract the hash of the old certificate to be replaced. 
    openssl x509 -in <path_to_old_machinessl_certificate> -noout -sha1 -fingerprint

    Output similar to the following appears:

    SHA1 Fingerprint=13:1E:60:93:E4:E6:59:31:55:EB:74:51:67:2A:99:F8:3F:04:83:88
  4. Update the lookup service registration endpoint manually. 
    /usr/lib/vmware-lookupsvc/tools/ls_update_certs.py --url https://<vCenterServer_FQDN>/lookupservice/sdk --certfile <cert-file-path> --user 'administrator@vsphere.local' --password '<password>' --fingerprint <SHA1_hash_of_the_old_certificate_to_replace>

    If you encounter problems running ls_update_certs.py, see the VMware Knowledge base article at https://kb.vmware.com/s/article/95982.

  5. Restart all services. 
    service-control --stop --all && service-control --start --all