Merge branch 'MicrosoftDocs:main' into toc-final

Author: aatsang

articles/active-directory-b2c/add-password-reset-policy.md

@@ -12,7 +12,7 @@ ms.subservice: b2c
 zone_pivot_groups: b2c-policy-type
 ms.custom: sfi-image-nochange
 
-#Customer Intent: As an Azure AD B2C administrator, I want to set up a password reset flow for local accounts, so that users can reset their passwords if they forget them.
+# Customer Intent: As an Azure AD B2C administrator, I want to set up a password reset flow for local accounts, so that users can reset their passwords if they forget them.
 ---
 
 # Set up a password reset flow in Azure Active Directory B2C
@@ -43,7 +43,7 @@ The default name of the **Change email** button in *selfAsserted.html* is **chan
 [!INCLUDE [active-directory-b2c-customization-prerequisites](../../includes/active-directory-b2c-customization-prerequisites.md)]
 
 
-- The B2C Users need to have an authentication method specified for self-service password reset. Select the B2C User, in the left menu under **Manage**, select **Authentication methods**. Ensure **Authentication contact info** is set. B2C users created via a Sign-up flow has this set by default. For users created via Azure Portal or by Graph API, you need to set **Authentication contact info** for SSPR to work. 
+- The B2C users need to have an authentication method specified for self-service password reset. Select the B2C User, in the left menu under **Manage**, select **Authentication methods**. Ensure **Authentication contact info** is set. B2C users created via a Sign-up flow has this set by default. For users created via Azure Portal or by Graph API, you need to set **Authentication contact info** for SSPR to work. 
 
 
 ## Self-service password reset (recommended)
@@ -52,7 +52,7 @@ The new password reset experience is now part of the sign-up or sign-in policy.
 
 ::: zone pivot="b2c-user-flow"
 
-The self-service password reset experience can be configured for the Sign in (Recommended) or Sign up and sign in (Recommended) user flows. If you don't have one of these user flows setup, create a [sign-up or sign-in](add-sign-up-and-sign-in-policy.md) user flow.
+The self-service password reset experience can be configured for the Sign in (Recommended) or Sign up and sign in (Recommended) user flows. If you don't have one of these user flows set up, create a [sign-up or sign-in](add-sign-up-and-sign-in-policy.md) user flow.
 
 To set up self-service password reset for the sign-up or sign-in user flow:
 

articles/application-gateway/application-gateway-faq.yml

@@ -443,6 +443,10 @@ sections:
         answer: |
           Yes, the Application Gateway v2 SKU supports Key Vault. For more information, see [TLS termination with Key Vault certificates](key-vault-certs.md).
 
+      - question: Why can't I select an Azure key vault from a different subscription in the Azure portal when configuring a TLS listener certificate on Application Gateway?
+        answer: |
+          The Azure portal currently allows selecting key vaults only from the same subscription as Application Gateway. This is a known portal limitation. However, Application Gateway does support using a key vault from a different subscription (within the same Microsoft Entra ID tenant) by configuring the certificate through the Azure CLI or PowerShell by using the key vault secret ID, provided the Application Gateway managed identity has the required permissions on the key vault.
+
       - question: How do I configure HTTPS listeners for .com and .NET sites?
         answer: |
           For multiple domain-based (host-based) routing, you can create multisite listeners, set up listeners that use HTTPS as the protocol, and associate the listeners with the routing rules. For more information, see [Hosting multiple sites by using Application Gateway](./multiple-site-overview.md).

articles/application-gateway/ingress-controller-annotations.md

@@ -38,8 +38,7 @@ For AGIC to observe an ingress resource, the resource *must be annotated* with `
 | [appgw.ingress.kubernetes.io/use-private-ip](#use-private-ip) | `bool` | `false` ||
 | [appgw.ingress.kubernetes.io/override-frontend-port](#override-frontend-port) | `bool` | `false` ||
 | [appgw.ingress.kubernetes.io/cookie-based-affinity](#cookie-based-affinity) | `bool` | `false` ||
-| [appgw.ingress.kubernetes.io/request-timeout]
-(#request-timeout) | `int32` (seconds) | `30` ||
+| [appgw.ingress.kubernetes.io/request-timeout](#request-timeout) | `int32` (seconds) | `30` ||
 | [appgw.ingress.kubernetes.io/use-private-ip](#use-private-ip) | `bool` | `false` ||
 | [appgw.ingress.kubernetes.io/backend-protocol](#backend-protocol) | `string` | `http` | `http`, `https` |
 | [appgw.ingress.kubernetes.io/hostname-extension](#hostname-extension) | `string` | `nil` ||

articles/application-gateway/media/mutual-authentication-portal/mutual-passthrough-portal.png

@@ -4,7 +4,7 @@ description: This article is an overview of mutual authentication on Application
 services: application-gateway
 author: mbender-ms
 ms.service: azure-application-gateway
-ms.date: 1/23/2026
+ms.date: 11/18/2025
 ms.topic: concept-article
 ms.author: mbender
 
@@ -15,17 +15,20 @@ ms.author: mbender
 Mutual authentication, or client authentication, allows for the Application Gateway to authenticate the client sending requests. Usually, only the client is authenticating the Application Gateway; mutual authentication allows for both the client and the Application Gateway to authenticate each other. 
 
 > [!NOTE]
-> We recommend using TLS 1.2 with mutual authentication as TLS 1.2 will be mandated in the future.
+> We recommend using TLS 1.2 with mutual authentication as TLS 1.2 will be mandated in the future. 
 
 ## Mutual authentication
 
-Application Gateway supports certificate-based mutual authentication where you can upload a trusted client CA certificate to the Application Gateway, and the gateway uses that certificate to authenticate the client sending a request to the gateway. With the rise in IoT use cases and increased security requirements across industries, mutual authentication provides a way for you to manage and control which clients can talk to your Application Gateway. 
+Application Gateway supports certificate-based mutual authentication where you can upload a trusted client CA certificate(s) to the Application Gateway, and the gateway uses that certificate to authenticate the client sending a request to the gateway. With the rise in IoT use cases and increased security requirements across industries, mutual authentication provides a way for you to manage and control which clients can talk to your Application Gateway. 
 
 Application Gateway provides following two options to validate client certificates:
 
 
 ## Mutual TLS passthrough mode 
-In mutual TLS passthrough mode, Application Gateway requests a client certificate during the TLS handshake but doesn't terminate the connection if the certificate is missing or invalid. The connection to the backend proceeds regardless of the certificate's presence or validity. If a certificate is provided, Application Gateway can forward it to the backend if required by the application. The backend service is responsible for validating the client certificate. Refer to server variables if you want to configure certificate forwarding. There's no need to upload any CA certificate when it is on Passthrough mode. To set up passthrough, follow the steps in [Configure Application Gateway with mutual authentication using ARM Template](./mutual-authentication-arm-template.md). To set up passthrough in Portal, follow the steps in [Configure mutual authentication with Application Gateway through portal](./mutual-authentication-portal.md).
+In mutual TLS passthrough mode, Application Gateway requests a client certificate during the TLS handshake but doesn't terminate the connection if the certificate is missing or invalid. The connection to the backend proceeds regardless of the certificate's presence or validity. If a certificate is provided, Application Gateway can forward it to the backend if required by the application. The backend service is responsible for validating the client certificate. Refer to server variables if you want to configure certificate forwarding. There's no need to upload any CA certificate when it is on Passthrough mode. To set up passthrough, follow the steps in [Configure Application Gateway with mutual authentication using ARM Template](./mutual-authentication-arm-template.md).
+ 
+> [!NOTE]
+> Currently, this feature is supported only through Azure Resource Manager deployment using API version 2025-03-01.
 
 
 ## Mutual TLS strict mode
@@ -40,13 +43,13 @@ For example, if your client certificate contains a root CA certificate, multiple
 If you're uploading a certificate chain with root CA and intermediate CA certificates, the certificate chain must be uploaded as a PEM or CER file to the gateway.
 
 > [!IMPORTANT]
-> Make sure you upload the entire trusted client CA certificate chain to the Application Gateway when using mutual authentication.
+> Make sure you upload the entire trusted client CA certificate chain to the Application Gateway when using mutual authentication. 
 
 Each SSL profile can support up to 100 trusted client CA certificate chains. A single Application Gateway can support a total of 200 trusted client CA certificate chains.
 
-> [!NOTE]
+> [!NOTE] 
 > * Mutual authentication is only available on Standard_v2 and WAF_v2 SKUs.
-> * Configuration of Mutual authentication for [TLS protocol listeners (preview)](tcp-tls-proxy-overview.md) is currently available through REST API, PowerShell, and CLI.
+> * Configuration of Mutual authentication for [TLS protocol listeners (preview)](tcp-tls-proxy-overview.md) is currently available through REST API, PowerShell, and CLI. 
 
 ### Certificates supported for mutual TLS strict mode authentication
 
@@ -62,32 +65,32 @@ Application Gateway supports certificates issued from both public and privately
 
 ### Verify client certificate DN
 
-You can verify the client certificate's immediate issuer and only allow the Application Gateway to trust that issuer. This option is off by default but you can enable this through Portal, PowerShell, or Azure CLI. 
+You have the option to verify the client certificate's immediate issuer and only allow the Application Gateway to trust that issuer. This option is off by default but you can enable this through Portal, PowerShell, or Azure CLI. 
 
 If you choose to enable the Application Gateway to verify the client certificate's immediate issuer, here's how to determine what client certificate issuer DN will be extracted from the certificates uploaded. 
 * **Scenario 1:** Certificate chain includes: root certificate - intermediate certificate - leaf certificate 
-    * *Intermediate certificate's* subject name is what Application Gateway extracts as the client certificate issuer DN and will be verified against. 
+    * *Intermediate certificate's* subject name is what Application Gateway will extract as the client certificate issuer DN and will be verified against. 
 * **Scenario 2:** Certificate chain includes: root certificate - intermediate1 certificate - intermediate2 certificate - leaf certificate
     * *Intermediate2 certificate's* subject name is what's extracted as the client certificate issuer DN and will be verified against. 
 * **Scenario 3:** Certificate chain includes: root certificate - leaf certificate 
     * *Root certificate's* subject name is extracted as client certificate issuer DN.
 * **Scenario 4:** Multiple certificate chains of the same length in the same file. Chain 1 includes: root certificate - intermediate1 certificate - leaf certificate. Chain 2 includes: root certificate - intermediate2 certificate - leaf certificate. 
-    * *Intermediate1 certificate's* subject name is extracted as client certificate issuer DN. 
+    * *Intermediate1 certificate's* subject name is extracted as client certificate issuer DN.  
 * **Scenario 5:** Multiple certificate chains of different lengths in the same file. Chain 1 includes: root certificate - intermediate1 certificate - leaf certificate. Chain 2 includes root certificate - intermediate2 certificate - intermediate3 certificate - leaf certificate. 
     * *Intermediate3 certificate's* subject name is extracted as client certificate issuer DN. 
 
 > [!IMPORTANT]
-> We recommend only uploading one certificate chain per file. This is especially important if you enable verify client certificate DN. By uploading multiple certificate chains in one file, you end up in scenario four or five and can run into issues later down the line when the client certificate presented doesn't match the client certificate issuer DN Application Gateway extracted from the chains.
+> We recommend only uploading one certificate chain per file. This is especially important if you enable verify client certificate DN. By uploading multiple certificate chains in one file, you'll end up in scenario four or five and may run into issues later down the line when the client certificate presented doesn't match the client certificate issuer DN Application Gateway extracted from the chains. 
 
 For more information on how to extract trusted client CA certificate chains, see [how to extract trusted client CA certificate chains](./mutual-authentication-certificate-management.md).
 
 ## Server variables 
 
-With mutual TLS authentication, there are other server variables that you can use to pass information about the client certificate to the backend servers behind the Application Gateway. For more information about which server variables are available and how to use them, check out [server variables](/azure/application-gateway/rewrite-http-headers-url#mutual-authentication-server-variables).
+With mutual TLS authentication, there are additional server variables that you can use to pass information about the client certificate to the backend servers behind the Application Gateway. For more information about which server variables are available and how to use them, check out [server variables](./rewrite-http-headers-url.md#mutual-authentication-server-variables).
 
 ## Certificate revocation
 
-When a client initiates a connection to an Application Gateway configured with mutual TLS authentication, not only can the certificate chain and issuer's distinguished name be validated, but revocation status of the client certificate can be checked with OCSP (Online Certificate Status Protocol). During validation, the certificate presented by the client will be looked up via the defined OCSP responder defined in its Authority Information Access (AIA) extension. In the event the client certificate has been revoked, the application gateway responds to the client with an HTTP 400 status code and reason. If the certificate is valid, the request continues to be processed by application gateway and forwarded on to the defined backend pool.
+When a client initiates a connection to an Application Gateway configured with mutual TLS authentication, not only can the certificate chain and issuer's distinguished name be validated, but revocation status of the client certificate can be checked with OCSP (Online Certificate Status Protocol). During validation, the certificate presented by the client will be looked up via the defined OCSP responder defined in its Authority Information Access (AIA) extension. In the event the client certificate has been revoked, the application gateway responds to the client with an HTTP 400 status code and reason.  If the certificate is valid, the request will continue to be processed by application gateway and forwarded on to the defined backend pool.
 
 Client certificate revocation can be enabled via REST API, ARM template, Bicep, CLI, or PowerShell.
 
@@ -127,17 +130,18 @@ Azure portal support is currently not available.
 
 ---
 
-To verify OCSP revocation status has been evaluated for the client request, [access logs](monitor-application-gateway-reference.md#access-log-category) contain a property called "sslClientVerify," with the status of the OCSP response.
+To verify OCSP revocation status has been evaluated for the client request, [access logs](monitor-application-gateway-reference.md#access-log-category) will contain a property called "sslClientVerify", with the status of the OCSP response.
 
 It's critical that the OCSP responder is highly available and network connectivity between Application Gateway and the responder is possible. In the event Application Gateway is unable to resolve the fully qualified domain name (FQDN) of the defined responder or network connectivity is blocked to/from the responder, certificate revocation status fails and Application Gateway will return a 400 HTTP response to the requesting client.
 
 > [!NOTE]
-> OCSP checks are validated via local cache based on the nextUpdate time defined by a previous OCSP response. If the OCSP cache hasn't been populated from a previous request, the first response can fail. Upon retry of the client, the response should be found in the cache and the request will be processed as expected.
+> OCSP checks are validated via local cache based on the nextUpdate time defined by a previous OCSP response. If the OCSP cache hasn't been populated from a previous request, the first response may fail. Upon retry of the client, the response should be found in the cache and the request will be processed as expected. 
 
 ## Notes
 - Revocation check via CRL isn't supported
 - Client revocation check was introduced in API version 2022-05-01
 
 ## Next steps
 
-After learning about mutual authentication, go to [Configure Application Gateway with mutual authentication in PowerShell](./mutual-authentication-powershell.md) to create an Application Gateway using mutual authentication.
+After learning about mutual authentication, go to [Configure Application Gateway with mutual authentication in PowerShell](./mutual-authentication-powershell.md) to create an Application Gateway using mutual authentication. 
+