ApplicationGateway mTLS passthrough blocks any subsequent updates

Hello @ Marcel Zeller,

Thanks for reaching out to Microsoft Q&A.

it looks like you’ve run into the “SslProfile must specify either SslPolicy or TrustedClientCertificates” error whenever you try to patch your App Gateway in passthrough mode.

You're not doing anything wrong. This is a known current limitation with mTLS passthrough mode on Application Gateway. The feature works perfectly when first deployed via the ARM template (as you did), but the Azure Portal, PowerShell, and CLI don't fully support the verifyClientAuthMode: "Passthrough" setting yet. That's why any update triggers the "SslProfile must specify either SslPolicy or TrustedClientCertificates" error. Adding either of those properties unfortunately switches the gateway out of true passthrough.

The intended (and fully supported) way to work with passthrough today is to manage the Application Gateway as infrastructure-as-code using ARM templates (or Bicep) with API version 2025-03-01. Any future changes scaling, rules, backend updates, etc. should be made by editing and redeploying the template in incremental mode. This keeps your passthrough configuration intact.

The Azure Portal, PowerShell, and CLI don't yet understand the verifyClientAuthMode: "Passthrough" setting on the SSL profile, so any update attempt from those tools triggers the validation error you're seeing: "SslProfile must specify either SslPolicy or TrustedClientCertificates."

Adding a trusted client certificate or SSL policy would switch it out of true passthrough, which is why those options break your current behavior.

The supported (and simplest) way to make changes going forward is to update the gateway using an ARM template (or Bicep). Here's how:

1. Export your current Application Gateway config from the portal (or via CLI: az resource export ...).
2. Keep the sslProfiles section exactly as it is today — it should look like this (no trustedClientCertificates and no sslPolicy):

      "properties": {   
      "clientAuthConfiguration": {                                 
      "VerifyClientCertIssuerDN": false,                 
      "VerifyClientRevocation": "None",                    
      "VerifyClientAuthMode": "Passthrough"               
      }
      }
   

   Make whatever other changes you need (rules, backends, SKU scale, etc.), ensure the top-level apiVersion is still 2025-03-01, then redeploy in Incremental mode.

This will succeed and keep your passthrough working perfectly.

ARM/Bicep is the official path for both creation and updates.

Reference Documents to use ARM templates:

https://learn.microsoft.com/en-us/azure/application-gateway/mutual-authentication-arm-template

Kindly let us know if the above helps or you need further assistance on this issue.

Please "Accept Answer" and "upvote" it. if the information helped you. This will help us and others in the community as well.

Hello Marcel Zeller

It seems you've encountered a known limitation with how the portal, PowerShell, and CLI interact with Application Gateway compared to the ARM API version, which does support passthrough mode. Here’s what’s happening:

This is a known limitation with mTLS passthrough mode on Application Gateway. The feature works correctly when deployed using the ARM template, as you did, but Azure Portal, PowerShell, and CLI do not fully support the verifyClientAuthMode: "Passthrough" setting yet. Because of this, any updates result in the "SslProfile must specify either SslPolicy or TrustedClientCertificates" error. Adding either property changes the gateway from true passthrough mode.

mTLS passthrough is only officially supported via ARM templates (or direct ARM REST calls) using API version 2025-03-01. – When you deploy with that API, you set and you don’t upload any TrustedClientCertificates or sslPolicy.

"sslProfile": {
  "name": "<yourProfile>",
  "verifyClientAuthMode": "Passthrough"
}

The Azure portal / az CLI / Azure PowerShell cmdlets still use an older API version under the covers, which enforces that every sslProfile must include either an SslPolicy or TrustedClientCertificates. That’s why any “update” you do from the portal/CLI/PS fails with SslProfile … must specify either SslPolicy or TrustedClientCertificates

Workarounds:

• Keep using ARM templates (apiVersion: 2025-03-01) to deploy and update your gateway. That way you can leave out TrustedClientCertificates entirely and updates won’t fail.
• If you absolutely need to do updates via the portal/CLI/PS, give the sslProfile a default SslPolicy and leave verifyClientAuthMode set to Passthrough. For example:

"sslProfile": {
  "name": "<yourProfile>",
  "verifyClientAuthMode": "Passthrough",
  "sslPolicy": {
    "policyType": "Predefined",
    "policyName": "AppGwSslPolicy20150501"
  }
}

This satisfies the portal/CLI schema without uploading any TrustedClientCertificates (so the gateway still won’t terminate or validate the client cert—it simply forwards it to your backend).

Check the below reference document for more understanding:

Deploy an Azure Application Gateway with mTLS passthrough listener

Mutual authentication with Application Gateway

Troubleshooting mutual authentication errors in Application Gateway

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "accept the answer" and "upvote" where the information provided will help you, this can be beneficial to other members of the community.

Passthrough mTLS on Application Gateway is currently supported only via the ARM API version 2025-03-01 and only through ARM-based deployment (ARM template, Bicep, REST). Portal, PowerShell, and CLI don’t yet understand the passthrough-specific properties on sslProfiles, which is why any update attempt from those surfaces fails validation with:

SslProfile <name>/<sslProfileName> must specify either SslPolicy or TrustedClientCertificates.

In passthrough mode:

• verifyClientAuthMode is set to Passthrough on the sslProfile.
• No trusted client CA certificates are required on the gateway.
• The client certificate is requested and then forwarded to the backend, which is responsible for validation.

Because the control-plane for Portal/PowerShell/CLI has not yet been updated to support the Passthrough mode semantics, it enforces the older rule that an sslProfile must have either:

• sslPolicy, or
• trustedClientCertificates.

That rule conflicts with the documented passthrough configuration, so any update from those tools fails. Adding trustedClientCertificates or changing the profile to satisfy the validation rule effectively switches away from pure passthrough behavior, which matches what is being observed.

Intended/Supported way to work with passthrough today:

1. Use ARM template (or REST/Bicep) with API version 2025-03-01 to create and update the Application Gateway.
2. Keep verifyClientAuthMode set to Passthrough in the sslProfile and do not configure trustedClientCertificates on that profile.
3. Avoid using Portal or older PowerShell/CLI commands to modify the gateway once passthrough is configured, because they will try to re-validate and overwrite the sslProfile according to older rules.

If updates to the gateway are required:

• Export the current ARM template (or resource JSON),
• Modify it as needed while preserving the passthrough sslProfile configuration and API version 2025-03-01,
• Redeploy using az deployment group create (or equivalent ARM/Bicep/REST deployment).

This behavior is a limitation of current tooling support rather than a misconfiguration of the gateway.

References:

• Deploy an Azure Application Gateway with mTLS passthrough listener
• Overview of mutual authentication with Application Gateway