Log management config import validation fails for Legacy Operations for Logs with default certificate (empty SAN)

Products

VCF Operations

Issue/Introduction

When adding Log Management in VMware Cloud Foundation and choosing Import configuration from an earlier Operations for Logs instance, the validate step fails with a certificate-related error. Customers cannot proceed with the import flow.

Observed symptoms:

Validation fails with an error such as:

"Failed to validate import configuration. Validation failed. Please check the provided parameters and try again."

In LCM/fleet logs, the underlying error appears as:

"Certificate for <hostname> doesn't match common name of the certificate subject: VMware Cloud Foundation Operations for Logs"

Example log line:

SSL/TLS handshake failure for POST https://<legacy_logs_address>:9543/api/v1/sessions: Certificate for <fqdn> doesn't match common name of the certificate subject: VMware Cloud Foundation Operations for Logs

This occurs when the legacy (source) Logs appliance is using its default/self-signed certificate that has no Subject Alternative Name (SAN) and a Common Name (CN) that is not the appliance hostname.

Environment

VMware Cloud Foundation (VCF 9.1)
VCF Operations for Logs (Legacy/standalone appliance, e.g. 8.x/9.0.x) as the **source** instance for import
Lifecycle Manager (LCM) / Fleet LCM used to add Log Management and import configuration from the legacy instance

Cause

The legacy Operations for Logs appliance may be deployed with a default self-signed certificate that:

Has Common Name (CN) set to a product string (e.g. "VMware Cloud Foundation Operations for Logs") instead of the appliance FQDN.

Has no Subject Alternative Name (SAN) (or no DNS SAN entry for the appliance hostname).

During the LCM import flow, Fleet LCM validates the connection to the legacy appliance using standard TLS hostname verification (RFC 2818 / RFC 6125):

Subject Alternative Names (SANs) are validated first.

Common Name (CN) is used only as a fallback when no DNS SAN entries are present.

Because the default certificate has no SAN and the CN does not match the hostname used to connect (e.g. ops-li.vcf.nimbus.internal), hostname verification fails. LCM correctly does not disable hostname verification for security reasons (to prevent man-in-the-middle attacks). The failure is therefore expected when the legacy appliance certificate is not valid for the hostname.

Resolution

Apply a new certificate with proper SAN (and matching CN) on the legacy Operations for Logs appliance before initiating the import flow.

Before starting the LCM import:

Replace the default/self-signed certificate on the legacy (source) Operations for Logs appliance with a certificate that satisfies hostname verification.

Certificate requirements:

Common Name (CN): Set to the exact FQDN/IP used to reach the appliance (e.g. server.example.com).
Subject Alternative Name (SAN): Include a DNS entry for that same FQDN (e.g. DNS:server.example.com).
If the appliance is accessed by IP in your environment, include the IP in SAN as well (e.g. IP:###.###.###.###) in addition to the FQDN, as required by your setup.

How to apply the certificate:

Use the official procedure for replacing or rotating the certificate on a standalone VMware Cloud Foundation Operations for Logs appliance (e.g. 9.0).
Follow the Operations for Logs / vRLI documentation or runbook for certificate replacement for your version.
Ensure the new certificate (and chain, if applicable) is installed and the appliance services are restarted so that the HTTPS endpoint (e.g. port 9543) serves the new certificate.

After the new certificate is in place:

Retry the LCM flow: add Log Management → Import configuration from an earlier Operations for Logs instance → enter the legacy appliance FQDN and credentials → Validate.
Validation should succeed once the certificate presented by the legacy appliance matches the hostname (CN and SAN).

Additional Information

Preventive guidance: When deploying a new Operations for Logs appliance that may later be used as a source for import, use a certificate that includes the appliance FQDN (and IP if applicable) in both CN and SAN to avoid this issue.