vSphere with Tanzu und NSX Advanced Load Balancer Integration mit Private CA

Back to Blog
VMware vSphere with Tanzu and NSX Advanced Load Balancer (ALB) on NSX Networking.

vSphere with Tanzu und NSX Advanced Load Balancer Integration mit Private CA

Ab vSphere 8.0 Update 2 ist es möglich, vSphere with Tanzu mit NSX als Networking Stack und NSX Advanced Load Balancer (ALB) als integrierten L4 Load Balancer bereitzustellen. Darüber hinaus kann der NSX Advanced Load Balancer auch als L7 Ingress (AKO) Controller verwendet werden und zusätzliche Enterprise-Features zur Verfügung zu stellen, wie bspw. Container- und App-Security mit WAF, real-time Application Performance Monitoring, Network and End Users Analytics/Insights uvm.

Dadurch ist es möglich, klassische L4/L7 Load Balancing Services bereitzustellen und parallel dazu auch Microservice-Anforderungen für Kubernetes Plattformen zu berücksichtigen. So lassen sich sämtliche NSX ALB Service Engine (Dataplane Komponenten, welche das effektive Load Balancing übernimmt) Instanzen, ob für Load Balanacing von virtuellen Maschinen oder Kuberentes basierte Workloads in einem zentralen UI verwalten.

Das Problem

Bei einem kürzlich durchgeführten Tanzu-Projekt, das auf vSphere 8.0 Update 2, NSX 4.1.2.1 und NSX ALB 22.1.5 basierte, stiessen wir auf ein Problem, das uns daran hinderte, den Supervisor Cluster zu initialisieren. Als wir versuchten, den Supervisor Cluster zu aktivieren, trat während der Workload Network Konfigurationsphase ein Timeout-Problem auf.

Als wir die NSX ALB-Konfiguration überprüften, stellten wir fest, dass kein einziges Objekt erstellt und auch keine entsprechenden Protokolle geschrieben wurden.

Daraufhin überprüften wir die NCP-Protokolle und fanden folgende Einträge:

[ncp GreenThread-125 W] nsx_ujo.ncp.nsx.policy.ako_bootstrap_service Unexpected exception from NSX manager when acquiring AVI auth token: Unexpected error from backend manager (['nsx-mgr-01:443', 'nsx-mgr-01a:443', 'nsx-mgr-01b:443', 'nsx-mgr-01c:443']) for PUT policy/api/v1/infra/alb-auth-token: Error: I/O error on GET request for https://192.168.100.33/api/user: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.; nested exception is javax.net.ssl.SSLHandshakeException: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.

[ncp GreenThread-125 W] nsx_ujo.ncp.nsx.policy.ako_bootstrap_service get_avi_auth_token failed, cause: Failed to get Avi auth token: Unexpected error from backend manager (['nsx-mgr-01:443', 'nsx-mgr-01a:443', 'nsx-mgr-01b:443', 'nsx-mgr-01c:443']) for PUT policy/api/v1/infra/alb-auth-token: Error: I/O error on GET request for https://192.168.100.33/api/user: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.; nested exception is javax.net.ssl.SSLHandshakeException: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain., args: (), kwargs: {}

[ncp GreenThread-125 I] nsx_ujo.common.controller AviSecretController worker 1 failed to sync Bootstrap due to retryable exception: Failed to get Avi auth token: Unexpected error from backend manager (['nsx-mgr-01:443', 'nsx-mgr-01a:443', 'nsx-mgr-01b:443', 'nsx-mgr-01c:443']) for PUT policy/api/v1/infra/alb-auth-token: Error: I/O error on GET request for https://192.168.100.33/api/user: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.; nested exception is javax.net.ssl.SSLHandshakeException: PKIX path building failed: java.security.cert.CertPathBuilderException: Unable to find certificate chain.

Es schien, als würde dies mit dem NSX Advanced Load Balancer Registrierungsprozess zusammenhängen, bei dem der NSX ALB Controller Cluster beim NSX Manager Cluster registriert (Link) wird.

Die Lösung

Tatsächlich ist es so, dass der JVM (Java Virtual Machine) Prozess auf den NSX Manager Nodes einen eigenen Certificate Authority Trust Store besitzt, in welchem nur Public CAs geführt werden. Wenn man nun dem NSX ALB ein Zertifikat von einer Private PKI/CA ausstellt, dann kommt kein Vertrauensverhältnis zustande, da diese Private CA nicht im JVM Trust Store vorhanden ist.

Um das Problem zu lösen, muss man die Private CAs in den JVM Trust Store importieren. Hierzu muss man folgende Befehle sequentiell auf jedem NSX Manager ausführen:

keytool -importcert -alias <private-Root-CA> -keystore /usr/java/jre/lib/security/cacerts -storepass changeit -file <path-to-root-ca-cert>
keytool -importcert -alias <private-Intermediate-CA> -keystore /usr/java/jre/lib/security/cacerts -storepass changeit -file <path-to-intermediate-ca-cert>
sudo cp <path-to-root-ca-cert> /usr/local/share/ca-certificates/
sudo cp <path-to-intermediate-ca-cert> /usr/local/share/ca-certificates/
sudo update-ca-certificates
service proton restart

Nach dem wir diese Anpassungen vorgenommen haben, konnten wir den Supervisor Cluster erfolgreich initiieren. Dazu mussten wir das aktuelle Deployment abbrechen (Disable Supervisor) und neu initiieren.

Anmerkung(en)

[Update] 05.02.2024: Mittlerweise wurde die Dokumentation entsprechend aktualisiert und verweist auf diese Besonderheit hinsichtlich JVM Trust Store und Private CA ausgestellten Zertifikaten.

Share this post

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Blog