I am going a bit nuts here, as I can't get it to work properly.
Environment:
App Gateway v2 (WAF)
App Service with custom domain
End 2 End SSL
Goals:
Manage external SSL Certificate on App Gateway only
Self-signed SSL on App Service
End2End SSL
Setup:
BackendPool set to App Service (*.azurewebsites.net)
FronendIP configured externally
Custom Probe with external Hostname set, Https
SSL Listener with FrontendIp/Port(443), host name and external valid certificate
Imported the self-signed certificate (cer) into the Trusted Root Authorities in App Gateway (powershell)
Http Settings -> Https, Port 443, timeout 30, custom probe, host name set to external address, TrustedRootCertificate assigned (powershell)
Basic Rule with SSL listener, Backend pool, Http Setting applied (powershell!)
Now this is probably the bit that throws me off, because:
Powershell says backend http settings are applied
The portal says so too on the "overview" page of the Rule
When editing the rule however, the "Http setting" field is empty, and there is a red exclamation mark:
"There are no http settings with pick host name from backend address
set. Create a new http setting with pick host name from backend
address set and then try again."
However, I don't want this setting, because that would access the back-end as "*.azurewebsites.net", right? I need the backend to be accessed by the external hostname (*.mydomain.com).
Symptoms:
Backend health in Portal "Healthy"
Accessing the external hostname -> 502 Bad Gateway
I had this working by using "pick host name from backend" and using the azure hostname (*.azurewebsites.net) for internal access, unfortunately our application really needs the external name (and for context: when finished, there will be multiple external names pointing to the same application, and the application changes behavior depending on which hostname is used)
More notes:
The App Service is configured with SSL, the self-signed certificate is only assigned to the custom hostname with "SNI"
This turns out to be a side-effect of "V2" being in "Preview" (as of 2018-12-13). The "Preview" label is not immediately apparent. The Azure Portal does not mention anything about it being in Preview, and all the Documentation talks about "Autoscaling" being in Preview.
Turns out, "V2" is meant with the "Autoscaling" feature, so the whole "V2" thing is in Preview.
We have re-done the exact same setup with the "V1" app gateway type, and it works as expected.
I wish they would clearly label preview things in the Portal, too...
When editing the rule however, the "Http setting" field is empty, and
there is a red exclamation mark:
Similar scenario in Github here. It seems WAF_v2 won't accept .cer files when setting HTTPS Settings. When you whitelist the CER cert with Http settings using PowerShell, it is not reflected in the portal. A possible reason is that application Gateway does not support Authentication Certificates for the WAF_v2 tier. You can read the known-issues-and-limitations in Application Gateway with WAF_v2 and End to end SSL with the v2 SKU.
If the certificate is self-signed, or signed by unknown
intermediaries, then to enable end to end SSL in v2 SKU a trusted root
certificate must be defined. Application Gateway will only communicate
with backends whose Server certificate’s root certificate matches one
of the list of trusted root certificates in the backend http setting
associated with the pool.
In addition to root certificate match, Application Gateway also
validates if the Host setting specified in the backend http setting
matches that of the common name (CN) presented by the backend server’s
SSL certificate. When trying to establish an SSL connection to the
backend, Application Gateway sets the Server Name Indication (SNI)
extension to the Host specified in the backend http setting.
If pick hostname from backend address is chosen instead of the Host
field in the backend http setting, then the SNI header is always set
to the backend pool FQDN and the CN on the backend server SSL
certificate must match its FQDN. Backend pool members with IPs are not
supported in this scenario.
About the 502 Bad Gateway error, the backend health is healthy on your side. If there is not a firewall blocking request or response from your backends, I may suggest checking the error on your web server side and make sure the backend is responding to the request sent by Application gateway within 30 seconds(Default value).
You could get more references from troubleshooting steps and diagnostic logs, and metrics for Application Gateway and here.
Hope this will help.
Related
I am trying to move our API Management instance behind the application gateway. I created a private dnszone on which the API management ETC is listening. I created Self Signed certificates for this private DNS zone0.
Uploaded the root certificate to the certificates tabs under security, as well as under the HTTP(s) settings tab of the application gateway. however my custom healt probe and health check keep mentioning that the CN Name does not match that one of the backend.
I have to mention that hostname of the listener is a different hostname (our public domain name) than the hostname i used on the private DNS Zone. Is this a problem?
You have to add the same custom domain used by application gateway to the api management service.
Api management is multi site service so it does not respond to the custom host names that are not defined under its custom domains because simply it does not know to which component/site it has to route the incoming request, also the the same extracted .CER certificate of the pfx certificate uploaded to api management should be added to the backend http settings for whitelisting purposes if you chose end to end ssl encryption, if you add a different certificate you will get a certificate mismatch error.
We have configured Listeners and add the rules and upload the SSL certificate on Azure portal
But the server is not hitting the URL. Suggest me if there any settings i missed to configure to enable the listeners based routing settings
When you access a host name via the App gateway, the DNS resolves that host name to the public IP address of the App gateway (which should be configured as a CNAME in your DNS or local host files) and then the app gateway uses that host header to find the associated listener. Once it finds the correct listener, it checks the associated rule and use the configured http settings to direct the traffic to the configured backend service.
Without the CNAME mapping in your DNS, the application gateway will not be aware of the host name/domain name that you are using to access the site.
If you have not created a CNAME mapping to your Application gateway's IP in your DNS, you can also make use of host files in your local machine for the name resolution as part of testing.
Reference : https://learn.microsoft.com/en-us/azure/application-gateway/create-multiple-sites-portal#edit-your-hosts-file-for-name-resolution
We have been working on a flow of upstream services on Azure. The following is the architecture:
User -> DNS -> Azure CDN -> Azure Traffic Manager -> Frontend Load Balancer (Firewall NVA) -> Azure Application Gateway -> Backend Pool (VM-Webserver)
The above flow was designed for a client and we are provisioning the same. The entire end to end flow works with HTTP requests.
But for HTTPS with SSL, the flow works only till traffic manager, as soon as we add CDN in the flow, it gives error, 'Request cannot be served', when checked in browser, it shows 502 bad gateway in developer tools
What we have seen so far:
The end to end flow is working seamless for HTTP requests For
HTTPs/SSL requests following configs have been done:
a) CDN : We have a profile with Custom Domain and HTTPS and Certificate enabled over it.The profile has both 80,443 enabled
b) Traffic manager : Endpoint set to port 443
c) Application Gateway : Plan to use end to end SSL encryption
i) Listener is on 443 port and has a pfx certificate
ii) HTTP setting with HTTPS and has a cer certificate from the original webserver
We have tried different combinations of configuration with CDN and traffic manager but doesn't seem to be working. I need this flow to be working end to end for HTTPS requests. This is for a prod migration to Azure.
Sorry for not following up and reverting on this.
As for the above issue and requirements, it was resolved.
Following were the steps taken:
CDN was configured with Origin type was select as Custom Origin - Original Hostname was given as traffic manager URL For Eg. abc.trafficmanager.net. Origin Host Header was left as blank
For Traffic manager profile changed the endpoint as Azure endpoint selected Target resource type as Public IP Address and added the public IP address of Load Balancer
For Application Gateway, it had to be made sure that we used PROPER CA CERTIFIED CERTIFICATE for end to end SSL encryption, we were trying it with self signed one hence did not work. We purchased one and used it, CDN responded as expected
Another important observation was that, for Application gateway in the HTTP settings (i.e. backend settings), the same CER certificate can be used for multiple websites for backend server certificate whitelisting.
The certificate (cer) that you wish to use, set it as the default certificate on your server, say for a particular website named abcxyz.com. Then the certificate of abcxyz.com can be used for whitelisting the backend for all the websites on that server
In short, app gateway backend only checks if the certificate (cer) is valid, it has nothing to do with the hostname or the certificate is of which domain, if the certificate matches and is valid, it is whitelisted
So folks, with all the detailed study and trails with logical reasoning, we were able to get the same exact flow as mentioned above working for both HTTP and HTTPs, with SSL encryption as well as SSL offloading for application gateway.
Thank you once again for all the support and suggestions !!
Say, I have two app service (HTTPS only is enabled):
https://myapp1.azurewebsites.net
https://myapp2.azurewebsites.net
I can call both app service endpoints using HTTPS successfully.
Then I created a traffic manager and add above two endpoints to traffic manager, say:
myapps.trafficmanager.net
After the traffic manager is created and endpoint added, the trafficmanger host name myapps.trafficmanager.net is also automatically added into custom domains of two app services. But without SSL binding to traffic manager host name.
Then if I call traffic manager endpoint using HTTPS: https://myapps.trafficmanager.net, I will got untrusted SSL cert error/warning. That is expected.
Since traffic manager just works on DNS level, the real request is actually send to the app service endpoint which has correct SSL cert binding. My question is:
From security point of view, is it safe to call the non-cert binding traffic manager endpopint using HTTPS in my code (say, using .NET HttpClient) but just ignore the cert error?
I recently set one of these up as well and fought with it for a bit. The short answer is that it is probably safe, but it sounds like you may be using the Traffic Manager incorrectly. You shouldn't be using the URL in the Traffic Manager as your end point if you want to use SSL. Instead configure your vanity domain name, mycoolsite.com to point to myapps.trafficmanager.net, using a DNS CNAME record.
If you want to use SSL and a single URL you should configure the custom URL and install an SSL cert at the service level. It should be same custom URL on both app services. This must be configured at in the app service, not in Traffic Manager.
I had to read this a few times to understand how it works under the hood, but it was helpful.
So in summary, to set it up properly, the steps would be:
Configure custom/vanity domain on both app services
Install the SSL cert on both app services
Setup and configure the Traffic Manager
Point the custom/vanity URL to the traffic manager using a DNS CNAME record
There is no need to bind a cert with traffic manager since the server certificate is not validated when using traffic manager health probes via HTTPS. Moreover, the traffic manager works at the DNS level. The clients connect directly to the selected endpoint, not through Traffic Manager.
In this case, you could use HTTPS for endpoints and use health probe via HTTPS. Even you could not bind a cert with traffic manager, you could make sure that the monitoring port is configured correctly in Traffic Manager (e.g. 443 instead of 80) and also your monitoring path points to a valid page for your service.
Another SO answer explains this more details. If you still want to make this warning disappearing, you can get a free SSL from letsencrypt.org and add that to your custom domain with the *.trafficmanager.net.
Scenario:
Configured Azure Application Gateway to route traffic to different Azure Web Apps to leverage the Web Application Firewall (WAF).
Initial configuration worked fine except that the final URL in the browser is the {mysite}.azurewebsites.net. I want this to be the custom domain name {subdomain}.{mysite}.com. This was configured by having the backend pool bound to an app service. Changing it to FQDN is not working. Screen shots below.
CNAME is already pointing to the gateway.
Desired result
When someone hits {subdomain}.{mysite}.com (which is already configured to point to the gateway) I should get {subdomain}.{mysite}.com not {mysite}.azurewebsites.net
Current setup:
The gateway is configured with a multi-site listener with its rule pointing to a backend pool and also bound to the http setting.
Listener is listening on {subdomain}.{mysite}.com
Backend pool config
Probe config
Http setting config
The following links provide some partial answers/configurations but none of them worked for me.
Application Gateway - 502 error
https://learn.microsoft.com/en-us/azure/application-gateway/troubleshoot-app-service-redirection-app-service-url
https://learn.microsoft.com/en-us/azure/application-gateway/create-web-app
UPDATE
Here are a list of steps used to configure an azure app service with a custom domain behind the Azure Application Gateway and WAF (Web Application Firewall) using the azure portal UI.
Configure a Backend pool with target pointing to your App Service.
Configure Health Probe with the following settings
Protocol: HTTP or HTTPS
Host: {appservice}.azurewebsites.net
Path: /
Configure Http setting
Use App Service unchecked.
Use custom probe checked.
Pick host name from backend address unchecked (you might have to check this to configure the rule and then uncheck it).
Configure listener
HostName: {subdomain}.{domain}.com (your domain)
Configure basic rule
Bind it to the appropriate http setting, backend pool and listener
Caveat: If there are no http settings with Pick host name from backend checked, you might need to change it, attach it, and then remove that flag again.
Probably, you get a 502 error because you change to FQDN subdomain.mysite.com in the targets of backend pool. However, In this scenario, you have not changed the custom domains in your web app service, you only could access the web site via the default domain mysite.azurewebsites.net. I suggest changing back to the App service in the targets.
Initial configuration worked fine except that the final URL in the
browser is the {mysite}.azurewebsites.net.
Please check if you have an HTTPS Only setting ON in the Custom domains of web app service. This will redirect all Http to Https. For me, usually, it will cause the final URL in the browser is the mysite.azurewebsites.net.
Update
If you have no HTTPS Only on, this issue may happen due to the following main reasons:
You have redirection configured on your App Service. Redirection can be as simple as adding a trailing slash to the request.
You have Azure AD authentication which causes the redirection.
You have enabled “Pick Host Name from Backend Address” switch in the HTTP settings of Application Gateway.
You don’t have your custom domain registered with your App Service.
This issue can be resolved by not having a redirection on the Application side, however, if that’s not possible, you can follow this solution to resolve it.
Register the domain subdomain.mysite.com to the custom domain list of the App Service. For more information, see Map an existing custom DNS name to Azure App Service.
Once that is done, your App Service is ready to accept the hostname subdomain.mysite.com. Now change your CNAME entry in DNS to point it back to Application Gateway’s FQDN. For example, appgw.eastus.cloudapp.azure.com.
Uncheck the checkbox Pick Hostname from Backend HTTP Settings in probe settings. In the hostname field of the probe, enter your App Service's FQDN mysite.azurewebsites.net as the probe requests sent from Application Gateway will carry this in the host header.
Uncheck the checkbox Pick Hostname from Backend Address in your Application Gateway’s HTTP settings.
Associate the custom probe back to the backend HTTP settings and verify the backend health if it is healthy.
Once this is done, Application Gateway should now forward the same hostname subdomain.mysite.com to the App Service and the redirection will happen on the same hostname.