[Network] az network application-gateway rule create drops validateCertChainAndExpiry from http-settings

[alquipas]

Describe the bug

Mention that running az network application-gateway rule create (or redirect-config create) inadvertently drops the validateCertChainAndExpiry and validateSNI properties from all existing backendHttpSettingsCollection items on the gateway.

Related command

az network application-gateway rule create
az network application-gateway redirect-config create
az network application-gateway address-pool create
az network application-gateway probe create
az network application-gateway http-listener create

Errors

State that this causes immediate production HTTPS validation failures (502 Bad Gateway) for existing backend pools every time a new listener or rule is appended to a shared gateway.

Issue script & Debug output

N/A

Expected behavior

When running Application Gateway commands that mutate the gateway (such as az network application-gateway rule create, probe create, address-pool create, or http-listener create), the command should download the current configuration from Azure, make its specific modification, and send the entire configuration back to Azure without altering or dropping any previously configured properties on unrelated elements.

Specifically, if an existing backendHttpSettingsCollection item already has validateCertChainAndExpiry: false and validateSNI: false configured (as introduced in PR #32332), these properties must be preserved during the internal Read-Modify-Write cycle triggered by other application-gateway sub-commands.

Environment Summary

az --version
azure-cli 2.83.0

core 2.83.0
telemetry 1.1.0

Extensions:
automation 1.0.0b1
resource-graph 2.1.1
ssh 2.0.6

Dependencies:
msal 1.35.0b1
azure-mgmt-resource 23.3.0

Python location '/opt/azure-cli/bin/python'
Config directory '/root/.azure'
Extensions directory '/root/.azure/cliextensions'

Python (Linux) 3.14.3 (main, Feb 13 2026, 15:31:44) [GCC 15.2.1 20260209]

Legal docs and information: aka.ms/AzureCliLegal

Your CLI is up-to-date.

Additional context

Point out that because these flags were added via PR #32332 inside the http-settings command, the rule creation commands are failing to retain those new properties during their internal Read-Modify-Write cycle.

[azure-client-tools-bot-prd]

Hi @alquipas,

2.83.0 is not the latest Azure CLI(2.84.0).

If you haven't already attempted to do so, please upgrade to the latest Azure CLI version by following https://learn.microsoft.com/en-us/cli/azure/update-azure-cli.

[yonzhan]

Thank you for opening this issue, we will look into it.

[necusjz]

in fact, update command is designed for modifying exiting resources and create command will alyways create a new resource.

btw, seems both of these commands sending requests via similar urls, like "/subscriptions/{}/resourcegroups/{}/providers/microsoft.network/applicationgateways/{}".

[alquipas]

in fact, update command is designed for modifying exiting resources and create command will alyways create a new resource.

btw, seems both of these commands sending requests via similar urls, like "/subscriptions/{}/resourcegroups/{}/providers/microsoft.network/applicationgateways/{}".

Hi! To clarify, we have a massive, shared Application Gateway that hosts dozens of separate websites for our organization.

We are not trying to update or recreate existing backend HTTP settings. We are using commands like az network application-gateway rule create, az network application-gateway probe create, and az network application-gateway http-listener create strictly to add brand new components to the Application Gateway for a brand new website.

The bug is that when we execute a create command to attach a new, unrelated component (like a new rule or listener), the Azure CLI fetches the entire Application Gateway payload, modifies it locally, and pushes the entire monolithic payload back to the Azure API. During that internal Read-Modify-Write cycle, the CLI parser fails to retain the validateCertChainAndExpiry properties that were already safely configured on the other, pre-existing backend HTTP settings belonging to our other websites.

In short: Creating a new rule for Publication B shouldn't secretly delete properties out of the existing HTTP settings for Publication A. This causes immediate 502 Bad Gateway outages for our existing production sites every time we deploy a new site to the shared gateway.