NSX-T Load Balancer serves Default Certificate instead of updated Ingress Secret in TKGi environments.
search cancel

NSX-T Load Balancer serves Default Certificate instead of updated Ingress Secret in TKGi environments.

book

Article ID: 431904

calendar_today

Updated On:

Products

VMware Tanzu Kubernetes Grid Integrated Edition

Issue/Introduction

Symptoms

  • Updated a Kubernetes Secret with a new certificate/key.

  • The Ingress resource points to the correct new Secret.

  • Browsers or clients receive the NSX-T Default/Base Certificate instead of the one defined in the Ingress.

Environment

 

  • Platform: VMware TKGi (Tanzu Kubernetes Grid Integrated)

  • Networking: NSX-T with NCP (NSX Container Plugin)

  • Load Balancing: NSX Edge-based Ingress

 

Cause

The issue is caused by a Source of Truth conflict at the NSX Edge level.

While the Ingress resources in the primary namespace were updated correctly, a duplicate or legacy Ingress resource existed in a separate namespace referencing a Secret with the old certificate.

Because the NSX-T Load Balancer (NSX Edge) processes Ingress rules globally across all namespaces:

  1. The Edge encountered two different certificates (New vs. Old) claiming the same DNS hostname(s).

  2. To prevent a misconfiguration or security risk (serving an ambiguous certificate), the NSX-T Virtual Server fails safe.

  3. It defaults to serving its Base/Default Certificate, resulting in the SSL errors observed by the user.

Resolution

Identifying and deleting the legacy Secret (containing the old certificate) resource in the secondary namespace should solve the issue.


Once the conflicting "Old" certificate is removed from the cluster's configuration, the NCP will able to establish a single "Source of Truth." This will allow the NSX-T Load Balancer to find and serve single certificate.

Powered by Wolken Software