Certificate requirements depend on whether you use the VMware Certificate Authority (VMCA) as an intermediate certificate authority or you use custom certificates. Requirements are also different for machine certificates.

Before you begin to change certificates, ensure that all nodes in your vSphere environment are time synchronized.

Note: vSphere deploys only RSA certificates for server authentication and does not support generating ECDSA certificates. vSphere verifies ECDSA certificates presented by other servers. For example, if vSphere connects to a syslog server and the syslog server has an ECDSA certificate, vSphere supports verifying that certificate.

Requirements for All Imported vSphere Certificates

  • Key size: 2048 bits (minimum) to 16384 bits (maximum) (PEM encoded)
    Note: In vSphere 8.0, you can only generate CSRs with a minimum key length of 3072 bits when using the vSphere Client or the vSphere Certificate Manager. vCenter Server still does accept custom certificates bearing a key length of 2048 bits. In vSphere 8.0 Update 1, you can use the vSphere Client to generate a CSR with a key length of 2048 bits.
    Note: vSphere's FIPS certificate only validates RSA key sizes of 2048 bits and 3072 bits.
  • PEM format. VMware supports PKCS8 and PKCS1 (RSA keys). When you add keys to VECS, they are converted to PKCS8.
  • x509 version 3
  • SubjectAltName must contain DNS Name=machine_FQDN
  • CRT format
  • Contains the following Key Usages: Digital Signature, Key Encipherment.
  • Exempting the vpxd-extension solution user certificate, Extended Key Usage can be either empty or contain Server Authentication.
vSphere does not support the following certificates.
  • Certificates with wildcards.
  • The algorithms md2WithRSAEncryption, md5WithRSAEncryption, RSASSA-PSS, dsaWithSHA1, ecdsa_with_SHA1, and sha1WithRSAEncryption are not supported.
  • When creating a custom machine SSL certificate for vCenter Server, Server Authentication and Client Authentication are not supported, and must be removed when using the Microsoft Certificate Authority (CA) templates. For more information, see the VMware knowledge base article at https://kb.vmware.com/s/article/2112009.

vSphere Certificate Compliance to RFC 2253

The certificate must be in compliance with RFC 2253.

If you do not generate CSRs using vSphere Certificate Manager, ensure that the CSR includes the following fields.

String X.500 AttributeType
CN commonName
L localityName
ST stateOrProvinceName
O organizationName
OU organizationalUnitName
C countryName
STREET streetAddress
DC domainComponent
UID userid
If you generate CSRs using vSphere Certificate Manager, you are prompted for the following information, and vSphere Certificate Manager adds the corresponding fields to the CSR file.
  • The password of the administrator@vsphere.local user, or for the administrator of the vCenter Single Sign-On domain that you are connecting to.
  • Information that vSphere Certificate Manager stores in the certool.cfg file. For most fields, you can accept the default or provide site-specific values. The FQDN of the machine is required.
    • Password for administrator@vsphere.local
    • Two-letter country code
    • Company name
    • Organization name
    • Organization unit
    • State
    • Locality
    • IP address (optional)
    • Email
    • Host name, that is, the fully qualified domain name of the machine for which you want to replace the certificate. If the host name does not match the FQDN, certificate replacement does not complete correctly and your environment might end up in an unstable state.
    • IP address of the vCenter Server node on which you run vSphere Certificate Manager.
Note: The OU (organizationalUnitName) field is no longer mandatory.

Certificate Requirements When Using VMCA as an Intermediate Certificate Authority

When you use VMCA as an intermediate CA, the certificates must meet the following requirements.
Certificate Type Certificate Requirements
Root certificate
  • You can use vSphere Certificate Manager to create the CSR. See Generate CSR Using the Certificate Manager and Prepare Root Certificate (Intermediate CA).
  • If you prefer to create the CSR manually, the certificate that you send to be signed must meet the following requirements.
    • Key size: 2048 bits (minimum) to 16384 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
    • The CA extension must be set to true for root certificates, and cert sign must be in the list of requirements. For example:
      basicConstraints        = critical,CA:true
      keyUsage                = critical,digitalSignature,keyCertSign
    • CRL signing must be enabled.
    • Extended Key Usage can be either empty or contain Server Authentication.
    • No explicit limit to the length of the certificate chain. VMCA uses the OpenSSL default, which is 10 certificates.
    • Certificates with wildcards or with more than one DNS name are not supported.
    • You cannot create subsidiary CAs of VMCA.

      See the VMware knowledge base article at http://kb.vmware.com/kb/2112009, Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 6.x, for an example using Microsoft Certificate Authority.

Machine SSL certificate

You can use vSphere Certificate Manager to create the CSR or create the CSR manually.

If you create the CSR manually, it must meet the requirements listed previously under Requirements for all Imported vSphere Certificates. You also have to specify the FQDN for the host.

Solution user certificate

You can use vSphere Certificate Manager to create the CSR or create the CSR manually.

Note: You must use a different value for Name for each solution user. If you generate the certificate manually, this might show up as CN under Subject, depending on the tool you use.

If you use vSphere Certificate Manager, the tool prompts you for certificate information for each solution user. vSphere Certificate Manager stores the information in certool.cfg.

For the vpxd-extension solution user, you can either leave Extended Key Usage empty or use "TLS WWW client authentication".

Requirements When Using Custom Certificates

When you want to use custom certificates, the certificates must meet the following requirements.
Certificate Type Certificate Requirements
Machine SSL certificate The machine SSL certificate on each node must have a separate certificate from your third-party or enterprise CA.
  • You can generate the CSR using the vSphere Client or the vSphere Certificate Manager, or create the CSR manually. The CSR must meet the requirements listed previously under Requirements for all Imported vSphere Certificates.
  • For most fields, you can accept the default or provide site-specific values. The FQDN of the machine is required.
Solution user certificate Each solution user on each node must have a separate certificate from your third-party or enterprise CA.
  • You can generate the CSRs using vSphere Certificate Manager or prepare the CSR yourself. The CSR must meet the requirements listed previously under Requirements for all Imported vSphere Certificates.
  • If you use vSphere Certificate Manager, the utility prompts you for certificate information for each solution user. vSphere Certificate Manager stores the information in certool.cfg.

    Note: You must use a different value for Name for each solution user. A manually generated certificate might show up as CN under Subject, depending on the tool you use.

When later you replace solution user certificates with custom certificates, provide the complete signing certificate chain of the third-party CA.

For the vpxd-extension solution user, you can either leave Extended Key Usage empty or use "TLS WWW client authentication".