VMware Cloud Foundation 4.5

5.2 5.1 5.0 4.5
Deutsch Français Italiano 日本語 English

Install Third-Party CA-Signed Certificates in VMware Cloud Foundation Using a Certificate Bundle

VMware Cloud Foundation
 supports two ways to install third-party certificates. This procedure describes the legacy method of using a certificate bundle. To use the legacy method, you must modify your preferences and then use this procedure to generate CSRs, sign the CSRs with a third-party CA, and finally upload and install the certificates.
VMware Cloud Foundation
 4.5.1 introduces a new method for installing third-party CA-signed certificates. By default,
VMware Cloud Foundation
 use the new method. See Install Third-Party CA-Signed Certificates Using Server Certificate and Certificate Authority Files for information using the new method. If you prefer to use the legacy method, you must modify your preferences.
  1. In the
    SDDC Manager UI
    , click the logged in user and select
    Preferences
    .
    An image showing the location of the Preferences menu.
  2. Use the toggle to switch to legacy certificate management.
    A screenshot of the toggle used to switch to legacy certificate management.
Uploading CA-signed certificates from a third-party Certificate Authority using the legacy method requires that you collect the relevant certificate files in the correct format and then create a single .tar.gz file with the contents. It's important that you create the correct directory structure within the .tar.gz file as follows:
  • The name of the top-level directory must exactly match the name of the workload domain as it appears in the list on the
    Inventory
    Workload Domains
    . For example,
    sfo-m01
    .
    • The PEM-encoded root CA certificate chain file (must be named
      rootca.crt
      ) must reside inside this top-level directory. The
      rootca.crt
       chain file contains a root certificate authority and can have
      n
       number of intermediate certificates.
      For example:
      -----BEGIN CERTIFICATE-----
<Intermediate1 certificate content>
-----END CERTIFICATE------
-----BEGIN CERTIFICATE-----
<Intermediate2 certificate content>
-----END CERTIFICATE------
-----BEGIN CERTIFICATE-----
<Root certificate content>
-----END CERTIFICATE-----
      In the above example, there are two intermediate certificates,
      intermediate1
       and
      intermediate2
      , and a root certificate.
      Intermediate1
       must use the certificate issued by
      intermediate2
       and intermediate2 must use the certificate issued by Root CA.
    • The root CA certificate chain file, intermediate certificates, and root certificate must contain the
      Basic Constraints
       field with value
      CA:TRUE
      .
    • This directory must contain one sub-directory for each component resource for which you want to replace the certificates.
  • Each sub-directory must exactly match the resource hostname of a corresponding component as it appears in the Resource Hostname column in the
    Inventory
    Workload Domains
    Certificates
     tab.
    For example,
    nsxManager.vrack.vsphere.local
    ,
    vcenter-1.vrack.vsphere.local
    , and so on.
    • Each sub-directory must contain the corresponding .csr file, whose name must exactly match the resource as it appears in the Resource Hostname column in the
      Inventory
      Workload Domains
      Certificates
       tab.
    • Each sub-directory must contain a corresponding .crt file, whose name must exactly match the resource as it appears in the Resource Hostname column in the
      Inventory
      Workload Domains
      Certificates
       tab. The content of the .crt files must end with a newline character.
      For example, the
      nsxManager.vrack.vsphere.local
       sub-directory would contain the
      nsxManager.vrack.vsphere.local.crt
       file.
  • All certificates including
    rootca.crt
     must be in UNIX file format.
  • Additional requirements for NSX-T certificates:
    • Server certificate (
      NSXT_FQDN
      .crt
      ) must contain the
      Basic Constraints
       field with value
      CA:FALSE
      .
    • If the NSX-T certificate contains HTTP or HTTPS based CRL Distribution Point it must be reachable from the server.
    • The extended key usage (EKU) of the generated certificate must contain the EKU of the CSR generated.
All resource and hostname values can be found in the list on the
Inventory
Workload Domains
Certificates
 tab.
  1. In the navigation pane, click
    Inventory
    Workload Domains
    .
  2. On the
    Workload Domains
     page, from the table, in the domain column click the workload domain you want to view.
  3. On the domain summary page, click the
    Certificates
     tab.
  4. Generate CSR files for the target components.
    1. From the table, select the check box for the resource type for which you want to generate a CSR.
    2. Click
      Generate CSRs
      .
      The
      Generate CSRs
       wizard opens.
    3. On the
      Details
       dialog, configure the settings and click
      Next
      .
      Option
      Description
      Algorithm
      Select the key algorithm for the certificate.
      Key Size
      Select the key size (2048 bit, 3072 bit, or 4096 bit) from the drop-down menu.
      Email
      Optionally, enter a contact email address.
      Organizational Unit
      Use this field to differentiate between divisions within your organization with which this certificate is associated.
      Organization Name
      Type the name under which your company is known. The listed organization must be the legal registrant of the domain name in the certificate request.
      Locality
      Type the city or locality where your company is legally registered.
      State
      Type the full name (do not abbreviate) of the state, province, region, or territory where your company is legally registered.
      Country
      Type the country name where your company is legally registered. This value must use the ISO 3166 country code.
    4. (Optional) On the
      Subject Alternative Name
       dialog, enter the subject alternative name(s) and click
      Next
      .
      You can enter multiple values separated by comma (,), semicolon (;), or space ( ). For NSX-T, you can enter the subject alternative name for each node along with the Virtual IP (primary) node.
      Wildcard subject alternative name, such as *.example.com are not recommended.
    5. On the
      Summary
       dialog, click
      Generate CSRs
      .
  5. Download and save the CSR files to the directory by clicking
    Download CSR
    .
  6. Complete the following tasks outside of the
    SDDC Manager UI
    :
    1. Verify that the different .csr files have successfully generated and are allocated in the required directory structure.
    2. Request signed certificates from a Third-party Certificate authority for each .csr.
    3. Verify that the newly acquired .crt files are correctly named and allocated in the required directory structure.
    4. Create a new .tar.gz file of the directory structure ready for upload to
      SDDC Manager
      . For example:
      <domain name>.tar.gz
      .
  7. Click
    Upload and Install
    .
  8. In the
    Upload and Install Certificates
     dialog box, click
    Browse
     to locate and select the newly created
    <domain name>.tar.gz
     file and click
    Open
    .
  9. Click
    Upload
    .
  10. If the upload is successful, click
    Install Certificate
    . The Security tab displays a status of Certificate Installation is in progress.

Content feedback and comments