Supervisor Cluster Stuck in "Configuring" State Due to Missing SAN on Avi SSL Certificate
Article ID: 453256
Updated On:
Products
Issue/Introduction
- The vSphere Supervisor Cluster becomes stuck in a Configuring state and fails to complete deployment or reconciliation.
- The vSphere Client reports an explicit error under the Supervisor Load Balancer status:
Configured Load Balancer fronting the kubernetes API ServerConfiguration error (since <Timestamp>)The control plane VM was unable to validate the load balancer's certificate. The certificate is invalid.
- The Avi Kubernetes Operator (AKO) pods are stuck in a CrashLoopBackOff state when inspected within the cluster:
kubectl get pods -n vmware-system-ako
- Reviewing the AKO pod logs reveals explicit TLS validation or x509 parsing errors indicating that the certificate cannot be validated because it lacks required Subject Alternative Names (SAN):
ERROR cache/avi_ctrl_clients.go:72 AVI controller initialization failedFATAL ako-main/main.go:243 AVI client initialization failed.Failed to invoke API. Error: Post "https://<Avi-Controller-Endpoint>/login": tls: failed to verify certificate: x509: cannot validate certificate because it doesn't contain any IP SANs
Environment
VMware vSphere Kubernetes Service
VMware Avi Load Balancer
Cause
This issue occurs following an SSL/TLS certificate update or renewal on the Avi Controller when the active certificate does not contain the proper Subject Alternative Name (SAN) entry required by the AKO service.
Depending on how the AKO connection is established and the specific errors returned in the logs, the SAN requirement may vary:
- If AKO connects directly via an IP address, Golang's x509 stack strictly enforces the presence of an IP Subject Alternative Name (IP SAN) matching that IP address.
- If AKO connects via a hostname or FQDN, a valid DNS Subject Alternative Name (DNS SAN) matching that endpoint must be present.
If the renewed certificate omits the required IP or DNS SAN entry, the TLS handshake is systematically rejected, resulting in AKO crash loops and a stalled Supervisor configuration.
Resolution
Step 1: Analyze AKO Logs & Verify Certificate SANs
- Inspect the failing AKO controller logs to identify whether the connection target is an IP address or FQDN and what SAN type is missing:
kubectl logs -n vmware-system-ako -l app.kubernetes.io/name=ako
- Run an OpenSSL command against your Avi Controller endpoint to inspect the active certificate extensions:
openssl s_client -connect <Avi-Controller-IP-or-FQDN>:443 -servername <Avi-Controller-IP-or-FQDN> </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A 2 "Subject Alternative Name"
- Verify whether the output includes the appropriate IP Address or DNS entry under the Subject Alternative Name
Step 2: Re-issue or Update Certificate in Avi UI
- Log into your Avi Controller UI.
- Navigate to Templates > Security > SSL/TLS Certificates.
- Edit or re-issue the certificate assigned to the Controller Portal.
- Update the Subject Alternative Name (SAN) fields based on your log findings:
- If connecting via IP, add the Controller's IP address under IP Address SAN type.
- If connecting via FQDN, add the fully qualified domain name under DNS SAN type.
- Save the certificate.
- Navigate to Administration > Controller Settings > Access Settings and assign this newly updated certificate as the active Portal SSL/TLS Certificate.
Step 3: Update Supervisor & Restart AKO
- Log into the vSphere Client.
- Navigate to your Supervisor Cluster > Configure > Network > Load Balancer.
- Update the Server Certificate field with the updated PEM certificate bundle.
- Access your control plane environment and restart the AKO deployment to force a clean re-authentication:
kubectl rollout restart deployment vmware-system-ako-ako-controller-manager -n vmware-system-ako
- Confirm that the AKO pods return to a healthy Running state and the Supervisor cluster successfully clears its configuration error state.
Additional Information
Feedback
