application-gateway-faq.yml

### YamlMime:FAQ
metadata:
  title: Frequently asked questions about Azure Application Gateway
  description: Find answers to frequently asked questions about Azure Application Gateway.
  services: application-gateway
  author: greg-lindsay
  ms.service: application-gateway
  ms.topic: faq
  ms.date: 04/26/2022
  ms.author: greglin
  ms.custom: references_regions
title: Frequently asked questions about Application Gateway
summary: |
  [!INCLUDE [updated-for-az](../../includes/updated-for-az.md)]
  
  The following are common questions asked about Azure Application Gateway.
  

sections:
  - name: General
    questions:
      - question: What is Application Gateway?
        answer: Azure Application Gateway provides an application delivery controller (ADC) as a service. It offers various layer 7 load-balancing capabilities for your applications. This service is highly available, scalable, and fully managed by Azure.

      - question: What features does Application Gateway support?
        answer: |
          Application Gateway supports autoscaling, TLS offloading, and end-to-end TLS, a web application firewall (WAF), cookie-based session affinity, URL path-based routing, multisite hosting, and other features. For a full list of supported features, see [Introduction to Application Gateway](./overview.md).
          
      - question: How do Application Gateway and Azure Load Balancer differ?
        answer: Application Gateway is a layer 7 load balancer, which means it works only with web traffic (HTTP, HTTPS, WebSocket, and HTTP/2). It supports capabilities such as TLS termination, cookie-based session affinity, and round robin for load-balancing traffic. Load Balancer load-balances traffic at layer 4 (TCP or UDP).

      - question: What protocols does Application Gateway support?
        answer: Application Gateway supports HTTP, HTTPS, HTTP/2, and WebSocket.

      - question: How does Application Gateway support HTTP/2?
        answer: |
          See [HTTP/2 support](./configuration-listeners.md#http2-support).
          
      - question: What resources are supported as part of a backend pool?
        answer: |
          See [supported backend resources](./application-gateway-components.md#backend-pools).
          
      - question: In what regions is Application Gateway available?
        answer: |
          Application Gateway v1 (Standard and WAF) is available in all regions of global Azure. It's also available in [Azure China 21Vianet](https://www.azure.cn/) and [Azure Government](https://azure.microsoft.com/overview/clouds/government/).
          
          For Application Gateway v2 (Standard_v2 and WAF_v2) availability, see [supported regions for Application Gateway v2](./overview-v2.md#unsupported-regions)
          
      - question: Is this deployment dedicated for my subscription, or is it shared across customers?
        answer: Application Gateway is a dedicated deployment in your virtual network.

      - question: Does Application Gateway support HTTP-to-HTTPS redirection?
        answer: |
          Redirection is supported. See [Application Gateway redirect overview](./redirect-overview.md).
          
      - question: In what order are listeners processed?
        answer: |
          See the [order of listener processing](./configuration-listeners.md#order-of-processing-listeners).
          
      - question: Where do I find the Application Gateway IP and DNS?
        answer: |
          If you're using a public IP address as an endpoint, you'll find the IP and DNS information on the public IP address resource. Or find it in the portal, on the overview page for the application gateway. If you're using internal IP addresses, find the information on the overview page.
          
          For the v2 SKU, open the public IP resource and select **Configuration**. The **DNS name label (optional)** field is available to configure the DNS name.
          
      - question: What are the settings for Keep-Alive timeout and TCP idle timeout?
        answer: |
          *Keep-Alive timeout* governs how long the Application Gateway will wait for a client to send another HTTP request on a persistent connection before reusing it or closing it. *TCP idle timeout* governs how long a TCP connection is kept open in case of no activity. 
          
          The *Keep-Alive timeout* in the Application Gateway v1 SKU is 120 seconds and in the v2 SKU it's 75 seconds. The *TCP idle timeout* is a 4-minute default on the frontend virtual IP (VIP) of both v1 and v2 SKU of Application Gateway. You can configure the TCP idle timeout value on v1 and v2 Application Gateways to be anywhere between 4 minutes and 30 minutes. For both v1 and v2 Application Gateways, you'll need to navigate to the public IP of the Application Gateway and change the TCP idle timeout under the "Configuration" blade of the public IP on Portal. Changing the value of the private IP address is not supported. You can set the TCP idle timeout value of the public IP through PowerShell by running the following commands: 
          
          ```azurepowershell-interactive
          $publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
          $publicIP.IdleTimeoutInMinutes = "15"
          Set-AzPublicIpAddress -PublicIpAddress $publicIP
          ```
 
      - question: Can I rename my Application Gateway resource?
        answer: No. There is no way to rename an Application Gateway resource. You must create a new resource with a different name. 
        
      - question: Is there a way to restore an Application Gateway and its public IP if it has been deleted?
        answer: No. There is no way to restore an Application Gateway resource or its public IP once deleted. You must create a new resource.
        
      - question: Does the IP or DNS name change over the lifetime of the application gateway?
        answer: In Application Gateway V1 SKU, the VIP can change if you stop and start the application gateway. But the DNS name associated with the application gateway doesn't change over the lifetime of the gateway. Because the DNS name doesn't change, you should use a CNAME alias and point it to the DNS address of the application gateway. In Application Gateway V2 SKU, you can set the IP address as static, so IP and DNS name will not change over the lifetime of the application gateway. 

      - question: Does Application Gateway support static IP?
        answer: Yes, the Application Gateway v2 SKU supports static public IP addresses and static internal IPs. The v1 SKU supports static internal IPs.

      - question: Does Application Gateway support multiple public IPs on the gateway?
        answer: An application gateway supports only one public IP address.

      - question: How large should I make my subnet for Application Gateway?
        answer: |
          See [Application Gateway subnet size considerations](./configuration-infrastructure.md#size-of-the-subnet).
          
      - question: Can I deploy more than one Application Gateway resource to a single subnet?
        answer: |
          Yes. In addition to multiple instances of a given Application Gateway deployment, you can provision another unique Application Gateway resource to an existing subnet that contains a different Application Gateway resource.
          
          A single subnet can't support both v2 and v1 Application Gateway SKUs.
          
      - question: Does Application Gateway v2 support user-defined routes (UDR)?
        answer: |
          Yes, but only specific scenarios. For more information, see [Application Gateway infrastructure configuration](configuration-infrastructure.md#supported-user-defined-routes).
          
      - question: Does Application Gateway support x-forwarded-for headers?
        answer: |
          Yes. See [Modifications to a request](./how-application-gateway-works.md#modifications-to-the-request).
          
      - question: How long does it take to deploy an application gateway? Will my application gateway work while it's being updated?
        answer: |
          New Application Gateway v1 SKU deployments can take up to 20 minutes to provision. Changes to instance size or count aren't disruptive, and the gateway remains active during this time.
          
          Most deployments that use the v2 SKU take around 6 minutes to provision. However it can take longer depending on the type of deployment. For example, deployments across multiple Availability Zones with many instances can take more than 6 minutes. 
          
      - question: How does application gateway handle routine maintenance?
        answer: |
          Updates initiated to Application Gateway are applied one [update domain](../../articles/virtual-machines/availability-set-overview.md#how-do-availability-sets-work) at a time, during off business hours for the region the gateway is deployed in. As each update domain's instances are being updated, the remaining instances in other update domains will continue to serve traffic. Active connections are gracefully drained from the instance(s) being updated for up to 5 minutes to help establish connectivity to instances in a different update domain before the update begins. During update, Application Gateway will temporarily run at reduced max capacity, which is determined by the amount of instances configured. The update process will proceed to the next set of instances only if the current set of instances have been upgraded successfully.
          
      - question: Can I use Exchange Server as a backend with Application Gateway?
        answer: Application Gateway doesn't support email protocols such as SMTP, IMAP, and POP3. HTTP/HTTPS services such as OWA, ActiveSync, and AutoDiscovery traffic may flow through Application Gateway, however WAF exclusions may be required if using WAF sku.

      - question: Is there guidance available to migrate from the v1 SKU to the v2 SKU?
        answer: |
          Yes. For details see, [Migrate Azure Application Gateway and Web Application Firewall from v1 to v2](migrate-v1-v2.md).
          
      - question: Will the Application Gateway v1 SKU continue to be supported?
        answer: |
          Yes. The Application Gateway v1 SKU will continue to be supported. However, it is strongly recommended to move to v2 to take advantage of the feature updates in that SKU. For more information on the differences between v1 and v2 features, see [Autoscaling and Zone-redundant Application Gateway v2](application-gateway-autoscaling-zone-redundant.md). You can manually migrate Application Gateway v1 sku deployments to v2 by following our [v1-v2 migration document](migrate-v1-v2.md).
          
      - question: Does Application Gateway V2 support proxying requests with NTLM authentication?
        answer: No. Application Gateway V2 doesn't support proxying requests with NTLM authentication.
        
      - question: Why are some header values not present when requests are forwarded to my application?
        answer: Request header names can contain alphanumeric characters and hyphens. Request header names containing other characters will be discarded when a request is sent to the backend target. Response header names can contain any alphanumeric characters and specific symbols as defined in [RFC 7230](https://tools.ietf.org/html/rfc7230#page-27), with the exception of underscores (\_).

      - question: Does Application Gateway affinity cookie support SameSite attribute?
        answer: |
          Yes, the [Chromium browser](https://www.chromium.org/Home) [v80 update](https://chromiumdash.appspot.com/schedule) introduced a mandate on HTTP cookies without SameSite attribute to be treated as SameSite=Lax. This means that the Application Gateway affinity cookie won't be sent by the browser in a third-party context. 
          
          To support this scenario, Application Gateway injects another cookie called *ApplicationGatewayAffinityCORS* in addition to the existing *ApplicationGatewayAffinity* cookie.  These cookies are similar, but the *ApplicationGatewayAffinityCORS* cookie has two more attributes added to it: *SameSite=None; Secure*. These attributes maintain sticky sessions even for cross-origin requests. See the [cookie based affinity section](configuration-http-settings.md#cookie-based-affinity) for more information.
          
      - question: What is considered an active listener versus inactive listener?
        answer: |
          An active listener is a listener that is associated to a rule **and** sending traffic to a backend pool. Any listener that **only** redirects traffic is not an active listener. Listeners associated with redirect rules are not considered active. If the redirect rule is a path-based rule, then all the paths in that redirect rule must be redirecting traffic, else the listener is considered active. See [Azure subscription and service limits, quotas, and constraints](../azure-resource-manager/management/azure-subscription-service-limits.md#application-gateway-limits) for individual component limit details. 
      
  - name: Performance
    questions:
      - question: How does Application Gateway support high availability and scalability?
        answer: |
          The Application Gateway v1 SKU supports high-availability scenarios when you've deployed two or more instances. Azure distributes these instances across update and fault domains to ensure that instances don't all fail at the same time. The v1 SKU supports scalability by adding multiple instances of the same gateway to share the load.
          
          The v2 SKU automatically ensures that new instances are spread across fault domains and update domains. If you choose zone redundancy, the newest instances are also spread across availability zones to offer zonal failure resiliency.
          
      - question: How do I achieve a DR scenario across datacenters by using Application Gateway?
        answer: Use Traffic Manager to distribute traffic across multiple application gateways in different datacenters.

      - question: Does Application Gateway support connection draining?
        answer: |
          Yes. You can set up connection draining to change members within a backend pool without disruption. For more information, see [connection draining section of Application Gateway](features.md#connection-draining).
          
      - question: Does Application Gateway support autoscaling?
        answer: |
          Yes, the Application Gateway v2 SKU supports autoscaling. For more information, see [Autoscaling and Zone-redundant Application Gateway](application-gateway-autoscaling-zone-redundant.md).
          
      - question: Does manual or automatic scale up or scale down cause downtime?
        answer: No. Instances are distributed across upgrade domains and fault domains.
        
      - question: Can I change from Standard to WAF sku without disruption?
        answer: Yes.

      - question: Can I change instance size from medium to large without disruption?
        answer: Yes.
        
  - name: Configuration
    questions:
      - question: Is Application Gateway always deployed in a virtual network?
        answer: |
          Yes. Application Gateway is always deployed in a virtual network subnet. This subnet can contain only application gateways. For more information, see [virtual network and subnet requirements](./configuration-infrastructure.md#virtual-network-and-dedicated-subnet).
          
      - question: Can Application Gateway communicate with instances outside of its virtual network or outside of its subscription?
        answer: |
          As long as you have IP connectivity, Application Gateway can communicate with instances outside of the virtual network that it's in. Application Gateway can also communicate with instances outside of the subscription it's in. If you plan to use internal IPs as backend pool members, use [virtual network peering](../virtual-network/virtual-network-peering-overview.md) or [Azure VPN Gateway](../vpn-gateway/vpn-gateway-about-vpngateways.md).
          
      - question: Can I deploy anything else in the application gateway subnet?
        answer: No. But you can deploy other application gateways in the subnet.
        
      - question: Can I change the virtual network or subnet for an existing Application Gateway?
        answer: |
          You can move an Application Gateway across subnets within the same virtual network only. It is supported with V1 with public and private frontend, and V2 with public frontend only. It is also important to note that the Application Gateway should be in a *Stopped* state to perform this action. Keep in mind that stopping/starting V1 will change the public IP. This operation can only be done using Azure PowerShell and Azure CLI by running the following commands:
          
          **Azure PowerShell**

          ```azurepowershell-interactive
          $VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
          $Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
          $AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
          Stop-AzApplicationGateway -ApplicationGateway $AppGw
          $AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
          #If you have a private frontend IP configuration, uncomment and run the next line:
          #$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
          Set-AzApplicationGateway -ApplicationGateway $AppGw
          ```
          For more information, see [Set-AzApplicationGatewayIPConfiguration](/powershell/module/az.network/Set-AzApplicationGatewayIPConfiguration).
         
          **Azure CLI**
          
          ```azurecli-interactive
          az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
          az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>
          ``` 

      - question: Are network security groups supported on the application gateway subnet?
        answer: |
          See [Network security groups in the Application Gateway subnet](./configuration-infrastructure.md#network-security-groups).
          
      - question: Does the application gateway subnet support user-defined routes?
        answer: |
          See [User-defined routes supported in the Application Gateway subnet](./configuration-infrastructure.md#supported-user-defined-routes).
          
      - question: Are service endpoint policies supported in the Application Gateway subnet?
        answer: |
          No. [Service endpoint policies](../virtual-network/virtual-network-service-endpoint-policies-overview.md) for storage accounts are not supported in Application Gateway subnet and configuring it will block Azure infrastructure traffic.
          
      - question: What are the limits on Application Gateway? Can I increase these limits?
        answer: |
          See [Application Gateway limits](../azure-resource-manager/management/azure-subscription-service-limits.md#application-gateway-limits).
          
      - question: Can I simultaneously use Application Gateway for both external and internal traffic?
        answer: Yes. Application Gateway supports one internal IP and one external IP per application gateway.

      - question: Does Application Gateway support virtual network peering?
        answer: Yes. Virtual network peering helps load-balance traffic in other virtual networks.

      - question: Can I talk to on-premises servers when they're connected by ExpressRoute or VPN tunnels?
        answer: Yes, as long as traffic is allowed.

      - question: Can one backend pool serve many applications on different ports?
        answer: Microservice architecture is supported. To probe on different ports, you need to configure multiple HTTP settings.

      - question: Do custom probes support wildcards or regex on response data?
        answer: No. 

      - question: How are routing rules processed in Application Gateway?
        answer: |
          See [Order of processing rules](./configuration-request-routing-rules.md#order-of-processing-rules).
          
      - question: For custom probes, what does the Host field signify?
        answer: |
          The Host field specifies the name to send the probe to when you've configured multisite on Application Gateway. Otherwise use '127.0.0.1'. This value is different from the virtual machine host name. Its format is \<protocol\>://\<host\>:\<port\>\<path\>.
          
      - question: Can I allow Application Gateway access to only a few source IP addresses?
        answer: |
          Yes. See [restrict access to specific source IPs](./configuration-infrastructure.md#allow-access-to-a-few-source-ips).
          
      - question: Can I use the same port for both public-facing and private-facing listeners?
        answer: No.

      - question: Does Application Gateway support IPv6?
        answer: Application Gateway v2 does not currently support IPv6. It can operate in a dual stack VNet using only IPv4, but the gateway subnet must be IPv4-only. Application Gateway v1 does not support dual stack VNets. 

      - question: How do I use Application Gateway V2 with only private frontend IP address?
        answer: |
          Application Gateway V2 currently does not support only private IP mode. It supports the following combinations
          * Private IP and Public IP
          * Public IP only
          
          But if you'd like to use Application Gateway V2 with only private IP, you can follow the process below:
          1. Create an Application Gateway with both public and private frontend IP address
          2. Do not create any listeners for the public frontend IP address. Application Gateway will not listen to any traffic on the public IP address if no listeners are created for it.
          3. Create and attach a [Network Security Group](../virtual-network/network-security-groups-overview.md) for the Application Gateway subnet with the following configuration in the order of priority:
              
              a. Allow traffic from Source as **GatewayManager** service tag and Destination as **Any** and Destination port as **65200-65535**. This port range is required for Azure infrastructure communication. These ports are protected (locked down) by certificate authentication. External entities, including the Gateway user administrators, can't initiate changes on those endpoints without appropriate certificates in place
              
              b. Allow traffic from Source as **AzureLoadBalancer** service tag and Destination and destination port as **Any**
              
              c. Deny all inbound traffic from Source as **Internet** service tag and Destination and destination port as **Any**. Give this rule the *least priority* in the inbound rules
              
              d. Keep the default rules like allowing VirtualNetwork inbound so that the access on private IP address is not blocked
              
              e. Outbound internet connectivity can't be blocked. Otherwise, you will face issues with logging, metrics, etc.
          
          Sample NSG configuration for private IP only access:
          ![Application Gateway V2 NSG Configuration for private IP access only](./media/application-gateway-faq/appgw-privip-nsg.png)
          
      - question: How can I stop and start Azure Application Gateway?
        answer: |
          You can use Azure PowerShell or the Azure CLI to stop and start Azure Application Gateway. When you stop and start Application Gateway, [billing](https://azure.microsoft.com/pricing/details/application-gateway/) also stops and starts.
                             
          ```azurepowershell
          # Stop an existing Azure Application Gateway instance
          
          $appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
          Stop-AzApplicationGateway -ApplicationGateway $appGateway       
          ```
          
          ```azurepowershell
          # Start an existing Azure Application Gateway instance
          
          $appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
          Start-AzApplicationGateway -ApplicationGateway $appGateway           
          ```
          
          ```azurecli-interactive
          # Stop an existing Azure Application Gateway instance
          
          az network application-gateway stop -g MyResourceGroup -n MyAppGateway
          ```
          ```azurecli-interactive
          # Start an existing Azure Application Gateway instance
          
          az network application-gateway start -g MyResourceGroup -n MyAppGateway
          ```
          
  
  - name: Configuration - TLS
    questions:
      - question: What certificates does Application Gateway support?
        answer: Application Gateway supports self-signed certificates, certificate authority (CA) certificates, Extended Validation (EV) certificates, multi-domain (SAN) certificates, and wildcard certificates.

      - question: What cipher suites does Application Gateway support?
        answer: |
          Application Gateway supports the following cipher suites. 
          
          - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
          - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
          - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
          - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
          - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
          - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
          - TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
          - TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
          - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
          - TLS_DHE_RSA_WITH_AES_128_CBC_SHA
          - TLS_RSA_WITH_AES_256_GCM_SHA384
          - TLS_RSA_WITH_AES_128_GCM_SHA256
          - TLS_RSA_WITH_AES_256_CBC_SHA256
          - TLS_RSA_WITH_AES_128_CBC_SHA256
          - TLS_RSA_WITH_AES_256_CBC_SHA
          - TLS_RSA_WITH_AES_128_CBC_SHA
          - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
          - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
          - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
          - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
          - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
          - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
          - TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
          - TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
          - TLS_DHE_DSS_WITH_AES_256_CBC_SHA
          - TLS_DHE_DSS_WITH_AES_128_CBC_SHA
          - TLS_RSA_WITH_3DES_EDE_CBC_SHA
          - TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
          
          For information on how to customize TLS options, see [Configure TLS policy versions and cipher suites on Application Gateway](application-gateway-configure-ssl-policy-powershell.md).
          
      - question: Does Application Gateway support reencryption of traffic to the backend?
        answer: Yes. Application Gateway supports TLS offload and end-to-end TLS, which reencrypt traffic to the backend.

      - question: Can I configure TLS policy to control TLS protocol versions?
        answer: Yes. You can configure Application Gateway to deny TLS1.0, TLS1.1, and TLS1.2. By default, SSL 2.0 and 3.0 are already disabled and aren't configurable.

      - question: Can I configure cipher suites and policy order?
        answer: |
          Yes. In Application Gateway, you can [configure cipher suites](application-gateway-ssl-policy-overview.md). To define a custom policy, enable at least one of the following cipher suites. 
          
          * TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 
          * TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
          * TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
          * TLS_RSA_WITH_AES_128_GCM_SHA256
          * TLS_RSA_WITH_AES_256_CBC_SHA256
          * TLS_RSA_WITH_AES_128_CBC_SHA256
          
          Application Gateway uses SHA256 to for backend management.
          
      - question: How many TLS/SSL certificates does Application Gateway support?
        answer: Application Gateway supports up to 100 TLS/SSL certificates.

      - question: Does Application Gateway have support for OCSP and OCSP stapling?
        answer: Yes, Application Gateway supports certificates with OCSP extensions and OCSP stapling for server certificates.

      - question: How many authentication certificates for backend reencryption does Application Gateway support?
        answer: Application Gateway supports up to 100 authentication certificates.

      - question: Does Application Gateway natively integrate with Azure Key Vault?
        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: 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).
          
      - question: Can I use special characters in my .pfx file password?
        answer: No, use only alphanumeric characters in your .pfx file password.

      - question: My EV certificate is issued by DigiCert and my intermediate certificate has been revoked. How do I renew my certificate on Application Gateway?
        answer: |
          Certificate Authority (CA) Browser members recently published reports detailing multiple certificates issued by CA vendors that are used by our customers, Microsoft, and the greater technology community that were out of compliance with industry standards for publicly trusted CAs. The reports regarding the non-compliant CAs can be found here:  
          
          * [Bug 1649951](https://bugzilla.mozilla.org/show_bug.cgi?id=1649951)
          * [Bug 1650910](https://bugzilla.mozilla.org/show_bug.cgi?id=1650910)
          
          As per the industry’s compliance requirements, CA vendors began revoking non-compliant CAs and issuing compliant CAs which requires customers to have their certificates re-issued. Microsoft is partnering closely with these vendors to minimize the potential impact to Azure Services, **however your self-issued certificates or certificates used in “Bring Your Own Certificate” (BYOC) scenarios are still at risk of being unexpectedly revoked**.
          
          To check if certificates utilized by your application have been revoked reference [DigiCert’s Announcement](https://knowledge.digicert.com/alerts/DigiCert-ICA-Replacement) and the [Certificate Revocation Tracker](https://misissued.com/#revoked). If your certificates have been revoked, or will be revoked, you will need to request new certificates from the CA vendor utilized in your applications. To avoid your application’s availability being interrupted due to certificates being unexpectedly revoked, or to update a certificate which has been revoked, please refer to our Azure updates post for remediation links of various Azure services that support BYOC: https://azure.microsoft.com/updates/certificateauthorityrevocation/
          
          For Application Gateway specific information, see below -
          
          If you are using a certificate issued by one of the revoked ICAs, your application’s availability might be interrupted and depending on your application, you may receive a variety of error messages including but not limited to: 
          
          1. Invalid certificate/revoked certificate
          2. Connection timed out
          3. HTTP 502
          
          To avoid any interruption to your application due to this issue, or to re-issue a CA which has been revoked, you need to take the following actions: 
          
          1. Contact your certificate provider on how to re-issue your certificates
          2. Once reissued, update your certificates on the Azure Application Gateway/WAF with the complete [chain of trust](/windows/win32/seccrypto/certificate-chains) (leaf, intermediate, root certificate). Based on where you are using your certificate, either on the listener or the HTTP settings of the Application Gateway, follow the steps below to update the certificates and check the documentation links mentioned for more information.
          3. Update your backend application servers to use the re-issued certificate. Depending on the backend server that you are using, your certificate update steps may vary. Please check for the documentation from your vendor.
          
          To update the certificate in your listener:
          
          1. In the [Azure portal](https://portal.azure.com/), open your Application Gateway resource
          2. Open the listener settings that’s associated with your certificate
          3. Click “Renew or edit selected certificate”
          4. Upload your new PFX certificate with the password and click Save
          5. Access the website and verify if the site is working as expected
          For more information, check documentation [here](./renew-certificates.md).
          
          If you are referencing certificates from Azure KeyVault in your Application Gateway listener, we recommend the following the steps for a quick change –
          
          1. In the [Azure portal](https://portal.azure.com/), navigate to your Azure KeyVault settings which has been associated with the Application Gateway
          2. Add/import the reissued certificate in your store. See documentation [here](../key-vault/certificates/quick-create-portal.md) for more information on how-to.
          3. Once the certificate has been imported, navigate to your Application Gateway listener settings and under “Choose a certificate from Key Vault”, click on the “Certificate” drop down and choose the recently added certificate
          4. Click Save
          For more information on TLS termination on Application Gateway with Key Vault certificates, check documentation [here](./key-vault-certs.md).
          
          
          To update the certificate in your HTTP Settings:
          
          If you are using V1 SKU of the Application Gateway/WAF service, then you would have to upload the new certificate as your backend authentication certificate.
          1. In the [Azure portal](https://portal.azure.com/), open your Application Gateway resource
          2. Open the HTTP settings that’s associated with your certificate
          3. Click on “Add certificate” and upload the reissued certificate and click save
          4. You can remove the old certificate later by clicking on the “…” options button next to the old certificate and select delete and click save.
          For more information, check documentation [here](./end-to-end-ssl-portal.md#add-authenticationtrusted-root-certificates-of-back-end-servers).
          
          If you are using the V2 SKU of the Application Gateway/WAF service, you don’t have to upload the new certificate in the HTTP settings since V2 SKU uses “trusted root certificates” and no action needs to be taken here.
          
  - name: Configuration - ingress controller for AKS
    questions:
      - question: What is an Ingress Controller?
        answer: |
          Kubernetes allows creation of `deployment` and `service` resource to expose a group of pods internally in the cluster. To expose the same service externally, an [`Ingress`](https://kubernetes.io/docs/concepts/services-networking/ingress/) resource is defined which provides load balancing, TLS termination and name-based virtual hosting.
          To satisfy this `Ingress` resource, an Ingress Controller is required which listens for any changes to `Ingress` resources and configures the load balancer policies.
          
          The Application Gateway Ingress Controller (AGIC) allows [Azure Application Gateway](https://azure.microsoft.com/services/application-gateway/) to be used as the ingress for an [Azure Kubernetes Service](https://azure.microsoft.com/services/kubernetes-service/) also known as an AKS cluster.
          
      - question: Can a single ingress controller instance manage multiple Application Gateways?
        answer: Currently, one instance of Ingress Controller can only be associated to one Application Gateway.

      - question: Why is my AKS cluster with kubenet not working with AGIC?
        answer: |
          AGIC tries to automatically associate the route table resource to the Application Gateway subnet but may fail to do so due to lack of permissions from the AGIC. If AGIC is unable to associate the route table to the Application Gateway subnet, there will be an error in the AGIC logs saying so, in which case you'll have to manually associate the route table created by the AKS cluster to the Application Gateway's subnet. For more information, see [Supported user-defined routes](configuration-infrastructure.md#supported-user-defined-routes).
          
      - question: Can I connect my AKS cluster and Application Gateway in separate virtual networks? 
        answer: Yes, as long as the virtual networks are peered and they don't have overlapping address spaces. If you're running AKS with kubenet, then be sure to associate the route table generated by AKS to the Application Gateway subnet. 

      - question: What features are not supported on the AGIC add-on? 
        answer: |
          Please see the differences between AGIC deployed through Helm versus deployed as an AKS add-on [here](ingress-controller-overview.md#difference-between-helm-deployment-and-aks-add-on)
          
      - question: When should I use the add-on versus the Helm deployment? 
        answer: |
          Please see the differences between AGIC deployed through Helm versus deployed as an AKS add-on [here](ingress-controller-overview.md#difference-between-helm-deployment-and-aks-add-on), especially the tables documenting which scenario(s) are supported by AGIC deployed through Helm as opposed to an AKS add-on. In general, deploying through Helm will allow you to test out beta features and release candidates before an official release. 
          
      - question: Can I control which version of AGIC will be deployed with the add-on?
        answer: No, AGIC add-on is a managed service which means Microsoft will automatically update the add-on to the latest stable version.

  - name: Configuration - mutual authentication
    questions:
      - question: What is mutual authentication?
        answer: |
          Mutual authentication is two-way authentication between a client and a server. Mutual authentication with Application Gateway currently allows the gateway to verify the client sending the request, which is client authentication. Typically, the client is the only one that authenticates the Application Gateway. Because Application Gateway can now also authenticate the client, it becomes mutual authentication where Application Gateway and the client are mutually authenticating each other.

      - question: Is mutual authentication available between Application Gateway and its backend pools?
        answer: |
          No, mutual authentication is currently only between the frontend client and the Application Gateway. Backend mutual authentication is currently not supported.      

  
  - name: Diagnostics and logging
    questions:
      - question: What types of logs does Application Gateway provide?
        answer: |
          Application Gateway provides three logs: 
          
          * **ApplicationGatewayAccessLog**: The access log contains each request submitted to the application gateway frontend. The data includes the caller's IP, URL requested, response latency, return code, and bytes in and out. It contains one record per application gateway.
          * **ApplicationGatewayPerformanceLog**: The performance log captures performance information for each application gateway. Information includes the throughput in bytes, total requests served, failed request count, and healthy and unhealthy backend instance count.
          * **ApplicationGatewayFirewallLog**: For application gateways that you configure with WAF, the firewall log contains requests that are logged through either detection mode or prevention mode.
          
          All logs are collected every 60 seconds. For more information, see [Backend health, diagnostics logs, and metrics for Application Gateway](application-gateway-diagnostics.md).
          
      - question: How do I know if my backend pool members are healthy?
        answer: |
          Verify health by using the PowerShell cmdlet `Get-AzApplicationGatewayBackendHealth` or the portal. For more information, see [Application Gateway diagnostics](application-gateway-diagnostics.md).
          
      - question: What's the retention policy for the diagnostic logs?
        answer: |
          Diagnostic logs flow to the customer's storage account. Customers can set the retention policy based on their preference. Diagnostic logs can also be sent to an event hub or Azure Monitor logs. For more information, see [Application Gateway diagnostics](application-gateway-diagnostics.md).
          
      - question: How do I get audit logs for Application Gateway?
        answer: In the portal, on the menu blade of an application gateway, select **Activity Log** to access the audit log. 

      - question: Can I set alerts with Application Gateway?
        answer: |
          Yes. In Application Gateway, alerts are configured on metrics. For more information, see [Application Gateway metrics](./application-gateway-metrics.md) and [Receive alert notifications](../azure-monitor/alerts/alerts-overview.md).
          
      - question: How do I analyze traffic statistics for Application Gateway?
        answer: |
          You can view and analyze access logs in several ways. Use Azure Monitor logs, Excel, Power BI, and so on.
          
          You can also use a Resource Manager template that installs and runs the popular [GoAccess](https://goaccess.io/) log analyzer for Application Gateway access logs. GoAccess provides valuable HTTP traffic statistics such as unique visitors, requested files, hosts, operating systems, browsers, and HTTP status codes. For more information, in GitHub, see the [Readme file in the Resource Manager template folder](https://github.com/Azure/azure-quickstart-templates/tree/master/demos/application-gateway-logviewer-goaccess).
          
      - question: What could cause backend health to return an unknown status?
        answer: |
          Usually, you see an unknown status when access to the backend is blocked by a network security group (NSG), custom DNS, or user-defined routing (UDR) on the application gateway subnet. For more information, see [Backend health, diagnostics logging, and metrics for Application Gateway](application-gateway-diagnostics.md).
          
      - question: Are NSG flow logs supported on NSGs associated to Application Gateway v2 subnet?
        answer: Due to current platform limitations, if you have an NSG on the Application Gateway v2 (Standard_v2, WAF_v2) subnet and if you have enabled NSG flow logs on it, you will see nondeterministic behavior and this scenario is currently not supported.

      - question: Where does Application Gateway store customer data?
        answer: Application Gateway does not move or store customer data out of the region it's deployed in.

additionalContent: |
    ## Next steps
    To learn more about Application Gateway, see [What is Azure Application Gateway?](overview.md).