Offline Depot Missing Version Info in VCF 9.x Due to Missing Subject Alternative Name (SAN) in Certificates
search cancel

Offline Depot Missing Version Info in VCF 9.x Due to Missing Subject Alternative Name (SAN) in Certificates

book

Article ID: 438066

calendar_today

Updated On:

Products

VMware Cloud Foundation VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

  • In VMware Cloud Foundation (VCF) 9.x, the offline software depot may show a status of "Connected," but metadata fails to sync, binaries do not download, and the UI displays no version information.

  • The VCF Fleet management appliance logs /var/log/vrlcm/vmware_vrlcm.log to check for binary downloads shows below entries
    YYYY-MM-DDTDD:HH:SS.839901739Z stdout F org.springframework.web.client.HttpServerErrorException$BadGateway: 502 Bad Gateway: "connection failed: Get "https://<offline depot fqdn>:443/PROD/metadata/productVersionCatalog/v1/productVersionCatalog.json": tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead<EOL>"

  • Copying the URL in a browser https://<offline depot fqdn>:443/PROD/metadata/productVersionCatalog/v1/productVersionCatalog.json shows "tls: failed to verify certificate: x509: certificate relies on legacy Common Name field, use SANs instead"

Environment

VCF 9.x

Cause

The issue is caused by a custom certificate that lacks Subject Alternative Name (SAN) information. During the certificate generation process, if the OpenSSL signing command omits specific extension switches, the SAN details defined in the configuration file are ignored. This results in a certificate that the system cannot properly validate for secure metadata communication.

Resolution

To resolve this, you must re-sign the Certificate Signing Request (CSR) using the correct extensions to ensure the SAN information is included in the final certificate.

Prerequisites

  • The CSR file (e.g., request.csr).
  • The configuration file used for the CSR (e.g., conf.cfg) containing the [req_ext] section.
  • Root access to the vCenter Server Appliance (VCSA).


Procedure

  1. Transfer Files: Copy both the request.csr and conf.cfg files to the vCenter Server Appliance (e.g., to the /root/ or /tmp/ directory) using SCP or SFTP.
  2. SSH into VCSA: Open an SSH session to the vCenter Server and log in as the root user.
  3. Sign the Certificate with Extensions: Execute the following updated OpenSSL command. This command explicitly includes the -extensions and -extfile switches required to process the SAN data:
    openssl x509 -req -days 365 -in /root/request.csr -CA /var/lib/vmware/vmca/root.cer -CAkey /var/lib/vmware/vmca/privatekey.pem -CAcreateserial -out /root/server.crt -sha256 -extensions req_ext -extfile /tmp/conf.cfg
  4. Complete the Certificate Chain: Append the VMCA root certificate to your newly generated server certificate to ensure a complete chain of trust:

  5. Verify the Certificate: You can verify that the SAN is now present by running:

    openssl x509 -in /root/server.crt -text -noout | grep -A 1 "Subject Alternative Name"

  6. Apply Certificate: Import the corrected server.crt into your offline depot configuration.

Additional Information

VCF 9.0 installer fails to connect to an offline depot with "Secure protocol communication error, check logs for more details.

If you need to provide logs to Broadcom Support, you can collect a specialized Fleet Management bundle using the command line:

Command:
vc-support --operations-fleet-logs
Result: This collects only the VCF Operations Fleet Management support logs.