Skip to content
Docs sslbrain sslbrain.com

VMware Avi / NSX ALB

Copy link to the page “VMware Avi / NSX ALB”

← All integrations

Load balancer

Renews certificates on selected Avi virtual services and the Controller portal through REST API.

The appliance runs the package and connects to VMware Avi / NSX ALB through Avi Controller REST API over HTTPS on port 443. No agent is installed on VMware Avi / NSX ALB.

What happens

  1. The appliance connects to VMware Avi / NSX ALB through Avi Controller REST API on port 443.
  2. Discovers version, certificate objects and bindings. Matches the served SHA-256 fingerprint to exactly one bound certificate. You select a virtual service or the Controller portal. If it fails: Ambiguous state produces a log without secrets and no change.
  3. Saves a private binding backup on the appliance and creates new PEM certificate, key and CA objects. Retains old objects and their renewal profiles. Selects the RSA or EC binding from the new certificate and verifies it over TLS 1.2/1.3; other services and the alternate identity remain.
  4. Checks readback and a fresh TLS connection with SNI: leaf, SAN and supplied intermediates. Portal handover reopens the API session using the exact old/new identities. If it fails: On failure, restores and checks the previous binding while the operation still owns it. Preserves and reports a later administrator change; imported objects are retained.

Technical details

Connection
The package runs on the appliance, which connects over HTTPS to Avi Controller REST API, port 443. No agent is installed.
Service ports
443
You need
Dedicated Controller user with certificate access and read/write permissions for the selected virtual service in its tenant. Portal targets require system configuration access. The appliance must reach the API and selected TLS listener.
Platform
Avi / NSX Advanced Load Balancer 22.1.3 and later
Actions
Discovery, Installation, Verification, Rollback
Packages
vmware-avi-api 1.0.0
Note
  • Management TLS uses system/CA trust or MANAGEMENT_TLS_PIN_SHA256. Use MANAGEMENT_TLS_CA_BUNDLE for a private CA. Credentials are sent only on the verified HTTPS connection. Portal handover returns the new management fingerprint; save it as the new pin. BACKUP_DIR holds private recovery journals without keys or passwords.
  • Select TARGET_ID from discovery. VERIFY_HOST/VERIFY_PORT can select a reachable NAT/listener address; VERIFY_SNI is the concrete DNS certificate name, including for a wildcard. When discovery supplies only a VIP IP, select VERIFY_SNI or a DNS VERIFY_HOST; otherwise an IP SAN is required. The agent reads the version: JSON PATCH from 31.2, full configuration PUT on earlier versions. Avoid concurrent administrator changes during activation.
  • Selecting the target automatically takes over its native renewal by switching to the new certificate object. The previous profile and its object remain available for rollback. For a new issuer chain on a GSLB site-persistence service, existing pool PKI must already trust the new CAs; the agent does not change trust stores. Backend/client certificates and the internal secure channel are separate targets and remain unchanged.

Certificate requirements

The agent accepts RSA 2048/3072/4096 bits and ECDSA P-256/P-384. Avi key-generation schemas list RSA 1024–8192 and EC P-256/P-384/P-521; this does not establish all import sizes or an unlimited maximum. Further version-specific import bounds for these two targets are unspecified.

22.1/30.1 guides require Subject Common Name (CN); the agent requires CN before 30.2. Guides from 30.2 omit the requirement without guaranteeing SAN-only support. The replacement must cover the selected name/IP in SAN. Mandatory clientAuth EKU or keyEncipherment KU is not documented for these server targets; the agent checks TLS server purpose.

The Controller certificate must cover the cluster IP or FQDN in SAN. From 30.1.1, ASCII/Punycode and no underscores in SAN names are documented. General wildcard/IP-SAN import support and maximum SAN count are unspecified; wildcard verification uses a concrete SNI name.

The agent sends a separate PEM leaf, matching unencrypted private key and CA objects in the HTTPS body. The Avi schema offers PEM/PKCS#12 (PFX), but this flow does not use DER/PFX/JKS. PFX legacy 3DES/RC2 versus AES encryption and the complete import combination are unspecified and unnecessary for the PEM flow.

Input has the leaf first, then intermediates in issuer order with an optional root. The agent creates explicit CA references and checks the served chain; the root need not be served. A universal Avi import ordering/root rule is unspecified. 32.1.3 offers skip_auto_chain for particular Enterprise licenses; the agent uses explicit CA references and chain checks on every version without that license-dependent field.

Avi object names have at most 255 characters from 20.1.6. The agent generates names within that bound. Further name grammar and PFX friendly name/alias rules are unspecified; the PEM flow uses no PFX/JKS aliases.

Minimum and maximum certificate lifetime are unspecified for these import targets. The replacement and its chain must be valid now. The API days_until_expire field is not an issuance-lifetime rule.

Get started