VKS Supervisor Cluster Deployment Stalls at Step 8 Due to CA Certificate Parse Failure
search cancel

VKS Supervisor Cluster Deployment Stalls at Step 8 Due to CA Certificate Parse Failure

book

Article ID: 423109

calendar_today

Updated On:

Products

VMware vSphere Kubernetes Service

Issue/Introduction

During the deployment of a vSphere Kubernetes Service (VKS) Supervisor Cluster within a VMware Cloud Foundation (VCF) workload domain, the process consistently stalls at step 8 of 17 while configuring the Supervisor Control Plane VMs.

Symptoms:

  • The deployment process remains in a stalled state indefinitely without generating an automated timeout or explicit UI failure.

  • wcpsvc logs on the vCenter Server repeatedly indicate that control plane VM bootstrapping is in progress, failing to retrieve crt and .node configuration status files.

  • Review of the kube-apiserver audit logs located on the Supervisor at /var/log/vmware/audit/kube-apiserver.log contains the following errors:

Unable to locate interface specified in filter: eth1
"command failed" err="jwt[0].issuer.certificateAuthority: Invalid value: \"<REDACTED_SECRE

 

Environment

VMware vCenter Server 8.0 update 3

vSphere Kubernetes Service 3.3.3

Cause

A Certificate Authority (CA) certificate specified in the oidc-ca-file possesses an invalid rfc822Name Name Constraint syntax. RFC 5280 mandates that rfc822Name constraints must specify either a complete electronic mail address or a structurally valid domain/subdomain string. The inclusion of a leading "@" symbol (e.g., @<REDACTED_HOSTNAME>) violates the parsing grammar rules implemented in the x509 certificate library, resulting in a validation failure that blocks control plane initialization.

Resolution

Remediate the invalid vCenter certificate infrastructure using one of the following methods:

  1. Regenerate the offending CA certificate, ensuring that all defined Name Constraints rigorously adhere to RFC 5280 guidelines by removing the illegal leading character (e.g., modify the constraint from @<HOSTNAME> to <HOSTNAME>), reference Broadcom KB 403973

  2. If the problematic root CA certificate is obsolete or unutilized within the active ecosystem, completely unpublish and delete the entry from the trusted root store. For explicit procedural instructions regarding root store modification, reference Broadcom KB 326288.

Additional Information

Replacing vCenter Machine SSL Certificate - Replacing vCenter Machine SSL Certificate with a Custom CA-Signed Certificate Using the vCenter GUI

Removing CA certificates from the trusted root store - https://knowledge.broadcom.com/external/article/326288/removing-ca-certificates-from-the-truste.html

 

Powered by Wolken Software