Backup Jobs Fail at Disk Open (Err=1) Due to VDDK 8.0 TLS / DNS Name Mismatch
search cancel

Backup Jobs Fail at Disk Open (Err=1) Due to VDDK 8.0 TLS / DNS Name Mismatch

book

Article ID: 444199

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

 

  • All VM backup jobs on a vSphere/vSAN 8.0 cluster fail at the disk read phase.

  • The vSphere Storage APIs - Data Protection (VADP) snapshot is created successfully in vCenter, but the backup job immediately fails on the data plane with the error: VixDiskLib_Open Err=1 or Error opening the disks for virtual machine.

  • The CommVault proxy (or other backup appliance) successfully resolves DNS and has port 902 open to the ESXi hosts.

  • Log Signature: Reviewing the vixdisklib.log on the backup proxy during the time of failure reveals the following explicit SSL exceptions:
    warning -[20928] [Originator@6876 sub=IO.Connection] Failed to SSL handshake; SSL(<io_obj p:0x000002036bd0be08, h:3196, <TCP 'X.X.X.X : 65249'>, <TCP 'X.X.X.X: 443'>>), e: 167772294(certificate verify failed), duration: 4msec
    error -[20928] [Originator@6876 sub=IO] HandshakeCb; SSL(<io_obj p:0x00000, h:3196, <TCP 'X.X.X.X : 65249'>, <TCP 'X.X.X.X : 443'>>); error: class Vmacore::Ssl::SSLVerifyException(SSL Exception: Verification parameters:
    ### --> ExpectedPeerName: <hostname>.cluster  (or other unexpected suffix)
    ### --> The remote host certificate has these problems:
    ### --> * Host name does not match the subject name(s) in certificate.
    VixDiskLib: VixDiskLibConnectInt: Failed to start session. Other error encountered: SSL Exception: Verification parameters

 

Environment

  • vSphere / ESXi 8.0 U2 and later
  • Any backing storage (VMFS, NFS, vSAN, vVOLs)
  • CommVault (or other backup vendors utilizing VMware VDDK 8.0+)
  • Environments utilizing multiple ESXi IP addresses (e.g., dedicated backup networks) or custom reverse DNS (PTR) records.

Cause

Starting with vSphere/VDDK 8.0, VMware enforces strict zero-trust TLS certificate checking on the data plane. The backup failure occurs because the backup proxy resolves the ESXi host's IP address to a hostname that does not exactly match the ESXi host's SSL certificate.

In this scenario, the proxy connected to a secondary ESXi IP address. The local OS `hosts` file or DNS reverse lookup (PTR) appended an unexpected suffix (such as `.cluster`) to the `ExpectedPeerName`. When the ESXi host presented its certificate over Port 902, it only contained the standard FQDN in its Subject Alternative Name (SAN). Because the expected name and the certificate SAN did not match, the VDDK actively rejected the connection, resulting in the disk-open failure.

*(Note: The snapshot succeeds because snapshot commands occur on the vCenter control plane over Port 443, whereas the disk open occurs on the direct proxy-to-ESXi data plane over Port 902 where this strict TLS check is enforced).*

Resolution

To resolve the TLS name mismatch, the connection path must be aligned with the ESXi host certificates. Choose one of the following methods:

Recommended Resolution: Update the backup network configuration or backup server routing to target an ESXi host IP address that resolves to the standard FQDN. Bypassing the secondary network IP or DNS record that forces the unexpected suffix allows the proxy to resolve the standard hostname, perfectly matching the existing ESXi SSL certificates.

Alternative Resolution: If the alternate DNS suffix (e.g., .cluster) is an intentional, required design for the backup network, the ESXi host certificates must be regenerated in vCenter to explicitly include the alternate suffix/name in the Subject Alternative Name (SAN) field.

Additional Information

VMware Certificate Management: If pursuing the Alternative Resolution, refer to VMware's official documentation for safely updating ESXi host certificates via the vCenter Certificate Authority (VMCA) to ensure the Subject Alternative Name (SAN) matches the target connection string:

VMware VDDK 8.0 Security Enforcement: Starting in the vSphere 8.0 branch, the Virtual Disk Development Kit (VDDK) enforces strict cryptographic checks for NBD/NFC transport. The expected hostname passed via the proxy's DNS resolution must cryptographically match the ESXi host's SSL certificate SAN.

  • VMware VDDK 8.0 Release Notes: Explicitly details the deprecation of unverified network connections and the requirement for proper SSL verification parameters.

Cross-Vendor Applicability: Because this failure occurs entirely within the VMware VDDK layer, the exact SSL log signatures (Host name does not match the subject name(s) in certificate and unable to get local issuer certificate) apply broadly across the backup industry for any software utilizing VADP network transport.

For a public example of this exact VDDK behavior and log output documented by a third-party vendor, see:

Powered by Wolken Software