Get-DeployRule fails with a Base-64 parsing error after upgrading to VCF PowerCLI 9.0
search cancel

Get-DeployRule fails with a Base-64 parsing error after upgrading to VCF PowerCLI 9.0

book

Article ID: 430122

calendar_today

Updated On:

Products

VMware vCenter Server

Issue/Introduction

  • After upgrading from VMware PowerCLI 13.3 to VCF PowerCLI 9.0 (v13.4.0), Get-DeployRule fails with a Base-64 parsing error. Auto Deploy rules cannot be viewed or changed.
  • You see an error similar to:
    VMware.VimAutomation.Sdk.Types.V1.ErrorHandling.VimException.VimException:
    Get-DeployRule The input is not a valid Base-64 string as it contains a
    non-base 64 character, more than two padding characters, or an illegal
    character among the padding characters.
    
  • In the PowerCLI stack trace, you see the failure occurs at System.Convert.FromBase64String() during RbdConnectivityService.Connect():
    at System.Convert.FromBase64String(String s)
    at VMware.DeployAutomation.Client50.RbdConnectivityService.Connect()
    
  • Cannot get or change Deploy rules

Environment

  • vCenter Server 8.0
  • VCF PowerCLI 9.0 (VMware.DeployAutomation 13.4.0) with Auto Deploy enabled

Cause

The Auto Deploy extension (com.vmware.rbd) stores its certificate in the Extension Manager's ServerCertificate field. In some environments, this field contains a certificate chain (two PEM certificates joined together) instead of a single leaf certificate. Previous PowerCLI versions accepted this, but VCF PowerCLI 9.0 introduced stricter certificate validation that expects only a single PEM certificate. When the chain is present, the parsing fails.

This is a known issue. The Auto Deploy service populates the ServerCertificate field with both the leaf certificate and a subordinate CA certificate. Only the leaf certificate should be stored.

Resolution

This issue is under review with Broadcom Engineering. It is planned for a fix to be available in a future release. Subscribe to this article to receive updates.

Workaround

Update the Extension Manager entry so that only the leaf certificate is stored in the ServerCertificate field. Run the following steps in PowerShell:

  1. Connect to vCenter Server. Escape any $ signs in the password:
    Connect-VIServer <vcenter-server> -Username "<username>" -Password "<password>"
    
  2. Get a view of the Extension Manager and find the Auto Deploy extension:
    $extMgr = Get-View ExtensionManager
    $rbd = $extMgr.FindExtension("com.vmware.rbd")
    
  3. Check the first Server entry and confirm the Type field is SOAP:
    $rbd.Server[0]
    
  4. Note the ServerCertificate value in the output. It contains two certificates. Save a copy of the full original value before making any changes, in case you need to roll back.
  5. From the original value, copy only the first certificate (the leaf certificate), including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines. You can escape newlines with `n to fit it on one line.
  6. Set the leaf certificate and update the extension:
    $leafCertificate = "<leaf certificate>"
    $rbd.Server[0].ServerCertificate = $leafCertificate
    $extMgr.UpdateExtension($rbd)
    
  7. Verify the change took effect:
    $rbd = $extMgr.FindExtension("com.vmware.rbd")
    $rbd.Server[0]
    
  8. Run Get-DeployRule to confirm the error is resolved.

Note: This change persists through rbd service restarts and vCenter restarts. However, the extension certificate is overwritten if VMCA root certificates are rotated or renewed, or during a vCenter upgrade. In those cases, reapply the workaround.

Additional Information