Hoppa till innehåll
Dokumentation sslbrain sslbrain.com

VMware Avi / NSX ALB

Kopiera länk till sidan “VMware Avi / NSX ALB”

← Alla integrationer

Lastbalanserare

Förnyar certifikat på valda Avi virtual services och Controller-portalen via REST API.

Appliancen kör paketet och ansluter till VMware Avi / NSX ALB genom Avi Controller REST API över HTTPS på port 443. Ingen agent installeras på VMware Avi / NSX ALB.

Så går det till

  1. Appliancen ansluter till VMware Avi / NSX ALB genom Avi Controller REST API på port 443.
  2. Hittar version, certifikatobjekt och bindningar. Matchar serverat SHA-256-fingeravtryck mot exakt ett bundet certifikat. Du väljer en virtual service eller Controller-portalen. Om det misslyckas: Tvetydigt tillstånd ger en logg utan hemligheter och ingen ändring.
  3. Sparar bindningsbackup privat på appliance och skapar nya PEM-certifikat-, nyckel- och CA-objekt. Behåller gamla objekt och deras förnyelseprofiler. Väljer RSA- eller EC-bindning från det nya certifikatet och kontrollerar den över TLS 1.2/1.3; andra tjänster och den alternativa identiteten behålls.
  4. Kontrollerar readback och en ny TLS-anslutning med SNI: leaf, SAN och levererade mellancertifikat. Vid portalbyte återskapas API-sessionen med den gamla/nya exakta identiteten. Om det misslyckas: Vid fel återställs och kontrolleras tidigare bindning när operationen fortfarande äger den. En senare administratörsändring behålls och rapporteras; importerade objekt behålls.

Tekniska detaljer

Anslutning
Paketet körs på appliancen, som ansluter över HTTPS till Avi Controller REST API, port 443. Ingen agent installeras.
Tjänstens portar
443
Ni behöver
Dedikerad Controller-användare med certifikatåtkomst och läs-/skrivbehörighet till vald virtual service i vald tenant. Portalen kräver system configuration-åtkomst. Appliance måste nå API och vald TLS-lyssnare.
Plattform
Avi / NSX Advanced Load Balancer 22.1.3 och senare
Åtgärder
Discovery, Installation, Kontroll, Rollback
Paket
vmware-avi-api 1.0.0
Observera
  • Management-TLS verifieras med system-/CA-tillit eller MANAGEMENT_TLS_PIN_SHA256. Använd MANAGEMENT_TLS_CA_BUNDLE för en privat CA. Inloggningsuppgifter skickas bara på den verifierade HTTPS-anslutningen. Vid portalbyte returnerar agenten det nya management-fingeravtrycket; spara det som nytt pin. BACKUP_DIR innehåller privata recovery-journaler utan nycklar eller lösenord.
  • Välj TARGET_ID från discovery. VERIFY_HOST/VERIFY_PORT kan välja en nåbar NAT-/lyssnaradress; VERIFY_SNI är det konkreta DNS-certifikatnamnet, även för wildcard. När discovery bara visar en VIP-IP, välj VERIFY_SNI eller en DNS-adress i VERIFY_HOST; annars krävs en IP SAN. Agenten läser versionen: JSON PATCH från 31.2, full configuration PUT på äldre versioner. Undvik samtidiga administratörsändringar under aktivering.
  • Val av målet övertar automatiskt dess inbyggda förnyelse genom att byta till det nya certifikatobjektet. Den gamla profilen och dess objekt behålls för återställning. Vid ny utfärdarkedja på en GSLB site-persistence-tjänst måste befintlig pool-PKI redan lita på nya CA:er; agenten ändrar inga trust stores. Backend-/klientcertifikat och intern secure channel är separata mål och ändras inte.

Krav på certifikatet

Agenten accepterar RSA 2048/3072/4096 bitar och ECDSA P-256/P-384. Avis key-generation-scheman anger RSA 1024–8192 och EC P-256/P-384/P-521; det dokumenterar inte alla importstorlekar eller ett obegränsat maximum. Ytterligare versionsspecifika importgränser för dessa två mål anges inte.

22.1/30.1-guider kräver Subject Common Name (CN); agenten kräver CN före 30.2. Guider från 30.2 utelämnar kravet utan att garantera SAN-only-stöd. Det nya certifikatet ska täcka valt namn/IP i SAN. Obligatorisk clientAuth-EKU eller keyEncipherment-KU dokumenteras inte för dessa servermål; agenten kontrollerar TLS server-purpose.

Controller-certifikatet ska täcka cluster-IP eller FQDN i SAN. Från 30.1.1 dokumenteras ASCII/Punycode och inga underscores i SAN-namn. Generellt importstöd för wildcard/IP-SAN och maximalt antal SAN anges inte; för wildcard används ett konkret SNI-namn vid kontroll.

Agenten skickar separat PEM-leaf, matchande okrypterad privat nyckel och CA-objekt i HTTPS-body. Avi-schemat erbjuder PEM/PKCS#12 (PFX), men detta flöde använder inte DER/PFX/JKS. PFX-kryptering med legacy 3DES/RC2 kontra AES och hela importkombinationen anges inte och krävs inte av PEM-flödet.

Indata har leaf först och därefter mellancertifikat i utfärdarordning med valfri rot. Agenten skapar uttryckliga CA-referenser och kontrollerar serverad kedja; roten behöver inte serveras. Universell Avi-importordning/rotregel anges inte. 32.1.3 erbjuder skip_auto_chain för vissa Enterprise-licenser; agenten använder uttryckliga CA-referenser och kedjekontroll på alla versioner utan detta licensberoende fält.

Avi-objektnamn har högst 255 tecken från 20.1.6. Agenten genererar egna namn inom gränsen. Ytterligare namngrammatik och friendly name/alias-regler för PFX anges inte; PEM-flödet använder inga PFX/JKS-alias.

Minsta och längsta certifikatlivslängd anges inte för dessa importmål. Det nya certifikatet och dess kedja ska vara giltiga nu. API-fältet days_until_expire är ingen regel för utfärdandelivslängd.

Kom igång