Skip to content
Docs sslbrain sslbrain.com

Azure Application Gateway

Copy link to the page “Azure Application Gateway”

← All integrations

Load balancer · Cloud service

Renews certificates on selected Azure Application Gateway listeners via PFX or Key Vault, with TLS checks and rollback.

The appliance runs the package and connects to Azure Application Gateway through Azure Resource Manager / Key Vault over HTTPS on port 443. No agent is installed on Azure Application Gateway.

What happens

  1. The appliance connects to Azure Application Gateway through Azure Resource Manager / Key Vault on port 443.
  2. Set AZURE_RESOURCE_ID and select application-gateway-listener as AZURE_TARGET_ROLE. Discovery reads listeners, frontend addresses and current certificate references. Set AZURE_TARGET_NAME when there are multiple listeners.
  3. The certificate is installed as a separate PFX certificate or a pinned Key Vault reference. Only the selected listener is bound to the new certificate; the previous reference is retained. If it fails: On failure, rollback attempts to restore the previously served certificate on the selected target. Restoration failure is reported with backup_dir for recovery.
  4. The appliance checks that the target serves the new leaf and full intermediate chain, with the correct hostname and validity.

Technical details

Connection
The package runs on the appliance, which connects over HTTPS to Azure Resource Manager / Key Vault, port 443. No agent is installed.
You need
Service principal with tenant ID, client ID and secret, plus ARM read/write and operation-status access on the selected gateway. The appliance must reach Azure OAuth/ARM over HTTPS and the listener TLS port. Key Vault requires certificate import and secret get/list for automation, plus the gateway user-assigned managed identity with secret get and network access to the vault.
Platform
v1/v2 with direct PFX; Key Vault on v2. Existing HTTPS and Layer 4 TLS listeners are selected through discovery.
Actions
Discovery, Installation, Verification, Rollback
Packages
azure-appgateway-api 1.0.0
Note
  • AZURE_CERTIFICATE_MODE selects direct or key-vault; otherwise the current storage mode is retained. Set a Key Vault reference with AZURE_KEY_VAULT_SECRET_ID. New material on an existing vault path creates a separate certificate object without rotating shared references.
  • Set a concrete AZURE_VERIFY_SNI for a wildcard or a listener without a hostname. AZURE_VERIFY_HOST and AZURE_VERIFY_PORT select the TLS address reachable by the appliance. Coordinate other gateway configuration changes because Azure is updated through a full GET/PUT. Azure can refresh other versionless Key Vault references during a gateway update.
  • Management HTTPS uses system CA trust. MANAGEMENT_TLS_CA_BUNDLE_BASE64, MANAGEMENT_TLS_PIN_SHA256 and MANAGEMENT_TLS_INSECURE are optional settings. One pin must match OAuth, ARM and Key Vault peers at once; use CA trust for different certificates. Served-certificate trust is selected separately with AZURE_VERIFY_CA_BUNDLE.
  • AZURE_OPERATION_TIMEOUT defaults to 1800 seconds and AZURE_VERIFY_TIMEOUT to 300 seconds; both can be increased to 86400. Verification covers the selected TLS probes. Deploy stores backup_dir under the appliance data-volume HOME for verify and rollback; retain that directory for your rollback period. New certificate objects are retained; plan cleanup after your rollback retention period.
  • An independent verify uses the retained backup_dir and attempts to restore the previously selected binding if the TLS probe fails at the deadline, even when ARM still shows the new binding.

Get started