Setting up Application Gateway with an App Service that uses Azure Active Directory Authentication
First published on MSDN on Nov 21, 2017 This blog post is going to guide you through setting up an Azure Application Gateway in front of an Azure App Service that uses Azure Active Directory authentication and a custom domain.
Azure Application Gateway: 502 error due to backend certificate not whitelisted in the AppGW
If you are using Azure Application Gateway as Layer 7 WAF for End to End SSL connectivity , you might have come across Certificate related issues most of the times. In this article I am going to talk about one most common issue "backend certificate not whitelisted" If you check the backend health of the application gateway you will see the error like this "The root certificate of the server certificate used by the backend does not match the trusted root certificate added to the application gateway. Ensure that you add the correct root certificate to whitelist the backend" The error says that Root cert is not whitelisted on the AppGW , but you might have a valid Third party certificate on the backend , and more over if you try to access the backend directly bypassing the Application Gateway you will not see any issues related to certificate in the browser. If your certificate is working on browser directly hitting the app and not with AppGW then what is the exact problem? To Answer we need to understand what happens in any SSL/TLS negotiation. During SSL negotiation , Client sends "Client Hello" and Server Responds with "Server Hello" with its Certificate to the Client. Now Clients will check the Server certificate and confirm if the certificate is issued by Trusted root or not. For the server certificate to be trusted we need the Root certificate in Trusted Root Cert Store , usually if you are having certs issued by Godaddy,Digicert,Vergion like Third party Vendors you don’t have to do anything because they are automatically trusted by your client/browser. If your cert is issued by Internal Root CA , you would have export the root cert and import it the Trust Root Store in the Client. This is the exact thing what we do when import .CER file in the HTTP Settings of the Application Gateway. In Azure docs, it is clearly documented that you don’t have to import Auth certificate in HTTP settings of the backend if your backend application has Global trusted certificate. You should do this only if the backend has cert which is issued by internal CA I hope we are clear till now on why we import Authenticate cert in the HTTP settings of the AppGW and when we use the option "Use Well Known CA" But the actual problem arises if you are using a Third party Cert or Internal CA Cert which has Intermediate CA and then Leaf certificate Most of the orgs for security reasons use Root Cert----> Intermediate Cert ------> Leaf Cert , even Microsoft follows the same for bing , check the screenshot below Now lets discuss what exactly is the confusion here if we have multiple Chain Cert When you have single chain certificate , then there will be no confusion with appgw , if your root CA is Global trusted just select "Use Trusted Root CA" option in HTTPsettings If you root CA is Internal CA , then import that Top root cert in .cer format and upload it in the HTTP settings Below is what happens during SSL negotiation when you have single chain cert and root in the AppGW. Server will send its Certificate and because AppGW will already have its Root Cert, it verifies the backend server certificate and finds that it was issued by the Root cert which it is Trusting and they it starts connecting on HTTPs further for probing. But when we have multiple chain certificate and if your backend application/server sends only the leaf the certificate , AppGW will not be able to trust the cert up to the top level domain root. when the backend server cert hits AppGW after Server Hello , AppGW tries to check who issued the certificate and it finds that it was issued by Intermediate certificate but then it does not have information about Intermediate cert, like who issued the cert and what is the root certificate of that intermediate certificate. This causes SSL/TLS negoatiation failure and AppGW marks the backend as unhealthy because it is not able to initiate the probe. Now you may ask why it works when you browse the backend directly through browser. Most of the browsers are thick clients , so it may work in the new browsers but reverse proxies like Application Gateway wont behave like our browsers they only trust the certificates if the backend sends the complete chain. here is what happens in in Multiple chain certificate. AppGW is a PaaS instance , by default you wont get access to the Applicaiton Gateway. Now how do we find if my application/backendserver is sending the complete chain to AppGW? You can find this by running openssl from either windows client or Linux client which is present in the same network/subnet of the backend application. We should get one Linux machine which is in the same subnet/VNET of the backend application and run the following commands. what we are doing is actually trying to simulate the Linux box as AppGW as if that machine is trying probe to the backend server as AppGW. here is the sample command you need to run, from the machine that can connect to the backend server/application. OpenSSL s_client -connect 10.0.0.4:443 -servername www.example.com -showcerts If the output doesn't show the complete chain of the certificate being returned, export the certificate again with the complete chain, including the root certificate. Configure that certificate on your backend server. For details on this Openssl command you can refer to Troubleshoot backend health issues in Azure Application Gateway | Microsoft Docs , Look for the sub topic "Trusted root certificate mismatch"QUIC based HTTP/3 with Application Gateway: Feature information Private Preview
Azure Application Gateway now supports HTTP/3 QUIC. As part of private preview, Application Gateway users can create HTTP/3 enabled Listeners which can support either of HTTP/1.1 or HTTP/2 along with HTTP/3. Note: HTTP/3, if enabled on one listener, will be available on that listener only. If some of your clients do not support HTTP/3, there’s no panic. They will still be able to communicate with HTTP/3 enabled listeners using previous HTTP versions. Why should HTTP/3 with Application Gateway be used? HTTP/3 is the latest version of the Hypertext Transfer Protocol built on the top of QUIC which operates over UDP. It represents a significant leap forward in terms of user experience, efficiency, and security. Here are some compelling reasons why migrating to HTTP/3 could greatly benefit your organization: Faster Web Page Loading (~200ms advantage): If you run a website or web application, implementing HTTP/3 can lead to faster page load times and improved user experiences. HTTP/3's reduced connection establishment latency and multiplexing capabilities help deliver resources more efficiently. Table below shows latency numbers of different HTTP versions. HTTPS (TCP+TLS) QUIC 1-RTT QUIC 0-RTT* First time connection 300ms 100ms 100ms Repeat Connection 200ms 50ms 0ms *0-RTT comes with its share of security risks and is not part of the private preview Enhanced Web Application Performance: Applications that make use of multiple resources, like images, scripts, and stylesheets, can benefit from HTTP/3's multiplexing and concurrent stream support. Mobile Applications: If you develop mobile apps, integrating HTTP/3 can enhance data transfer speed and responsiveness, which is especially important on mobile networks where latency can be higher. Reducing HOL Blocking: HTTP/3's use of QUIC helps mitigate head-of-line blocking, where the delay of one resource can block the delivery of others. This is especially advantageous for applications that require efficient resource loading. Security: HTTP/3's integration with QUIC provides improved security features by design, reducing the risk of certain types of attacks compared to previous versions of HTTP. Presently, 26.5% of the internet traffic is on HTTP/3 and there has been a steady increase in the adoption compared to HTTP/2 which has seen a decreasing trend (by ~10% in the last 12 months) owing to some of its demerits (explained in the sections later). How should HTTP/3 with Application Gateway be enabled? Prerequisite: You have an existing Application Gateway resource on standard_v2 SKU only. Please reach out to us @ quicforappgw@microsoft.com with the Resource URI on which you want the HTTP/3 feature enabled and we'll take you along with the next steps. What all HTTP/3 features are supported in private preview? HTTP/3 will be supported only in the front leg of the connection and backends will continue to be HTTP1.1. Application Gateway will support client-initiated connection migration (explained below) Application Gateway will support PMTU discovery. Application Gateway can advertise support for HTTP/3 via alt-svc header as part of HTTP1/2 response. (Image below explains the flow) What is HTTP/3 & QUIC? TCP (Transmission Control Protocol) (RFC793) has been the most widely used transport layer protocol since its inception. But, with the advent of more real time applications, the evolution of the edge, and an ever increasing need to reduce latency and congestion, using TCP is becoming untenable. UDP (User Datagram Protocol) (RFC768) was always seen as an alternative to TCP especially in instances where connectionless-less-reliable transmission was okey-dokey! But UDP suffered with the implementation of congestion control. TLS (Transport Layer Security) (RFC8446) adds another layer over TCP after the 3-way handshake for TLS negotiation to establish session key and session data encryption. Though the combination provides reliability and security, increased connection establishment has made application developers smirk than smile. QUIC (Quick UDP Internet Connections) (RFC9000) attempts to bridge these UDP gaps by inducing the TCP niceties and attempts to reduce the TCP ossification in the network. Put in brief, TCP encapsulated and encrypted in a UDP payload is QUIC. It appears like a bidirectional concealed UDP packet sequence to the external network. To the endpoints, it provides an advantage over TCP by deliberately concealing the transport parameters from the network and by shifting the responsibility of the flow control and the encryption service to the application layer from the transport layer. Pre-HTTP/3 protocols: HTTP/1.1 and HTTP/2 are done over TCP. HTTP/1.x versions have slow response times and never satisfy faster-load-times hungry webpages. HTTP/1.1, being a textual protocol, does a below average job in resource prioritization by transmitting the request and response headers as plain text. Without multiplexing capabilities, network requests are served in an ordered and blocking manner. With this approach, HTTP/1.1 suffers from HTTP Head of Line (HOL) blocking where the client waits for the previous requests to be serviced before sending another resulting in the subsequent blocked requests on a single TCP connection. Imagine a webpage needing multiple resources to load (Images, CSS, HTML files, Js files etc) the complete page! To overcome all these HTTP/1.1 limitations, HTTP/2 was brought in. It introduced header field compression by binary framing layer and creating a stream for communication reducing the amount of data in the header. Concurrent exchanges on the same connection by interleaving request and response messages and efficient coding of HTTP header fields. Prioritization of requests allowed more important requests complete quicker thus improving performance. HTTP/2 protocol communication involved binary encoded frames that carried data mapped to messages (request/response) in a stream which contained identifiers and priority information multiplexed in a single TCP connection. Figure-1 shows the flow of protocol communication in HTTP/2. All these enhancements mean lesser no. of TCP connections, longer-lived connections, less competition with other flows leading to better network utilization. By allowing multiple HTTP requests over a single TCP connection, HTTP/2 resolved HTTP HOL blocking issue but created the TCP HOL blocking issue. In the event of a network blip like network congestion, unavailability of network or change of a cell in a mobile network which might lead to loss of a packet throwing a TCP connection into a tizzy as it ensures that the order of packets transmitted and received are same. A loss of one packet will mean everything stops until the lost packet is retransmitted. In the case of multiple requests multiplexed onto a single TCP connection, all the requests are blocked although the “lost packet” in real impacts only one request. With increasing no. of mobile friendly apps, increase in the usage of cellular networks, and, in countries with not so good networks and high chances of network blips, such an issue can cause interruption to services. Enter QUIC based HTTP/3: HTTP/3 is based on QUIC. It is designed to be faster than TCP with lower latency, lesser overhead during connection establishment and quicker data transfer over the established connection. QUIC is based on UDP and offers 0-RTT and 1-RTT handshakes compared to 3-way handshakes of TCP. This is possible as it supports additional streams. HTTP/3 retains all the niceties of HTTP/2 like server push mechanism, multiplexing of requests over single connection via streams, resource prioritization. It ensures the issue of TCP HOL blocking is resolved. “Lost packets” along the way will not interrupt the data transfer. QUIC sees to it that transferring other data is uninterrupted while the issue of the “lost packet” is being resolved. QUIC based HTTP/3 features and use-cases: Faster connection establishment The regular 3-way handshake gives way to the 1-RTT and 0-RTT handshakes based on QUIC which will lead to a drop in the connection establishment by 66%-95%. The 1-RTT and the 0-RTT connection establishment helps in the improvement of page load times in web browsing immensely. Instant messaging applications, voice assistants, transactional systems (financial transactions, online purchases) benefit from quick connection establishment. In these scenarios, 1-RTT connection establishment can make a noticeable difference in reducing initial delays and enhancing overall user satisfaction. Financial institutions will find a wide range of benefits due the low latency with their mobile apps, online banking portals, provide customers with real-time notifications, effective API integration and many such use cases. Independent HTTP Streams (no TCP HOL Blocking) TCP HOL blocking occurs when a single delayed or lost packet holds up the delivery of subsequent packets, impacting overall communication efficiency. Avoiding TCP HOL blocking can offer significant advantages in real-life scenarios where minimizing latency, improving responsiveness, and optimizing data transmission are crucial. Removing unnecessary bottlenecks and making communication smoother results in happy customers. Web browsing without HOL blocking will help in fetching multiple resources in the page leading to quicker page loading times and thus providing the users with a rich browsing experience. Without HOL blocking, messages in an instant messaging application are delivered promptly without being held up providing the end user a fluid experience. IoT devices that transmit sensor data and updates will be able to deliver all the necessary data without being delayed by a single lost or slow packet, ensuring timely and accurate reporting. Avoiding HOL blocking in financial transactions ensures that data related to transactions is transmitted without unnecessary delays, contributing to real-time processing and confirmations without which CSAT is impacted vastly. Connection Migration Customers are always on the move. Especially with the ever-improving cellular networks, they are seldom stuck to a single network or a cell in the network. This nature of being on the move constantly will mean constant registration with the network and establishing connections frequently and deriving data from different servers. In the traditional HTTP and TCP method, this would lead to several drops in the connectivity. But that is a thing of the past with QUIC and HTTP/3. The QUIC-HTTP/3 combine provides users with a Connection Migration feature. During the QUIC connection establishment, the server provides the client with a set of Connection IDs (CID) as part of the QUIC header. Using this CID, the client can retain an existing connection despite moving networks and attaining new IP addresses. With the help of the connection migration, uninterrupted web browsing would be possible for users. IoT devices’ that need to maintain continuous communication will find the connection migration extremely useful. Users moving from private to public WiFi networks at malls, airports and other public places will be provided with seamless app experience. How to sign up? https://forms.office.com/r/iGeYgrmydAWeb Application Firewall (WAF) rate limit rule for Azure Application Gateway
Hello, Currently, I can create a WAF rate limit rule only on Azure Front Door but I can't create it on the Application Gateway (e.g. see https://serverfault.com/questions/961678/rate-limit-using-azure-application-gateway). Will the WAF rate limit rule on the Application Gateway ever be available in the future? If yes, when? Thanks in advance.Setting up Application Gateway with an App Service that uses Azure Active Directory Authentication and URL Authorization Rules
First published on MSDN on Nov 21, 2017 This blog post is an optional extension of my previous post about properly configuring an Azure App Service using authentication behind an Azure Application Gateway.
