Merge pull request #235955 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: huypub

articles/active-directory/fundamentals/multi-tenant-user-management-introduction.md

@@ -119,7 +119,7 @@ Organizations initially focus on requirements that they want in place for immedi
 - **Single Sign On:** Enable users to access resources across the organization without the need to enter more credentials.
 ### Patterns for account creation 
 
-Microsoft mechanisms for creating and managing the lifecycle of your external user accounts follow three common patterns. You can use these patterns to help define and implement your requirements. Choose the pattern that best aligns with your scenario and then focus on the pattern details.
+Microsoft mechanisms for creating and managing the lifecycle of your external user accounts follow three common patterns. You can use these patterns to help define and implement your requirements. Choose the pattern that best aligns with your scenario and then focus on the pattern details.  
 
 | Mechanism |  Description | Best when |
 | - | - | - |

articles/application-gateway/application-gateway-troubleshooting-502.md

@@ -190,6 +190,38 @@ If all the instances of BackendAddressPool are unhealthy, then the application g
 
 Ensure that the instances are healthy and the application is properly configured. Check if the backend instances can respond to a ping from another VM in the same VNet. If configured with a public end point, ensure a browser request to the web application is serviceable.
 
+## Upstream SSL certificate does not match
+
+### Cause
+
+The TLS certificate installed in the backend server(s), does not match the hostname received in the Host request header. 
+
+In scenarios where End-to-end TLS is enabled, a configuration that is achieved by editing the appropiate "Backend HTTP Settings", and changing there the configuration of the "Backend protocol" setting to HTTPS, it is mandatory to ensure that the CNAME of the TLS certificate installed in the backend servers matches the hostname coming to the backend in the HTTP host header request.
+
+As a reminder, the effect of enabling on the "Backend HTTP Settings" the option of protocol HTTPS rather than HTTP, will be that the second part of the communication that happens between the instances of the Application Gateway and the backend servers will be encrypted with TLS.
+
+Due to the fact that by default Application Gateway sends the same HTTP host header to the backend as it receives from the client, you will need to ensure that the TLS certificate installed on the backend server, is issued with a CNAME that matches the host name received by that backend server in the HTTP host header.
+Remember that, unless specified otherwise, this hostname would be the same as the one received from the client.
+
+For example:
+
+Imagine that you have an Application Gateway to serve the https requests for domain www.contoso.com
+You could have the domain contoso.com delegated to an Azure DNS Public Zone, and a A DNS record in that zone pointing www.contoso.com to the public IP of the specific Application Gateway that is going to serve the requests.
+
+On that Application Gateway you should have a listener for the host www.contoso.com with a rule that has the "Backed HTTP Setting" forced to use protocol HTTPS (ensuring End-to-end TLS). That same rule could have configured a backend pool with two VMs running IIS as Web servers.
+
+As we know enabling HTTPS in the "Backed HTTP Setting" of the rule will make the second part of the communication that happens between the Application Gateway instances and the servers in the backend to use TLS.
+
+If the backend servers do not have a TLS certificate issued for the CNAME www.contoso.com or *.contoso.com, the request will fail with **Server Error: 502 - Web server received an invalid response while acting as a gateway or proxy server** because the upstream SSL certificate (the certificate installed in the backend servers) will not match the hostname in the host header, and hence the TLS negotiation will fail. 
+
+
+www.contoso.com --> APP GW front end IP --> Listener with a rule that configures "Backend HTTP Settings" to use protocol HTTP  --> Backend Pool --> Web server (needs to have a TLS certificate installed for www.contoso.com) 
+
+## Solution
+
+it is required that the CNAME of the TLS certificate installed in the backend server, matches the host name configured in the HTTP backend settings, otherwise the second part of the End-to-end communication that happens between the instances of the Application Gateway and the backend, will fail with "Upstream SSL certificate does not match", and will throw back a **Server Error: 502 - Web server received an invalid response while acting as a gateway or proxy server**
+
+
 ## Next steps
 
 If the preceding steps don't resolve the issue, open a [support ticket](https://azure.microsoft.com/support/options/).