If an AppService is called directly via its IP, either the certificate is invalid or the page cannot be found. If the call is made via HTTPS, the automatic generated certificate only stores the DNS name and not the IP, therefore is the error message:
~$ curl -i https://188.8.131.52/ curl: (60) SSL: no alternative certificate subject name matches target host name '184.108.40.206'
If the call without HTTPS is allowed, the service responds is 404:
~$ curl -i http://220.127.116.11/ HTTP/1.1 404 Site Not Found Content-Length: 2667 Connection: close Content-Type: text/html
This is because it is a shared service where multiple websites operate under the same virtual IP. The correct forwarding is based on the correct
host value given in the header. If the call is made via IP and the
host value is set correct in the header, the call succeeds:
~$ curl -i -H "Host: tzuehlke20221224.azurewebsites.net" http://18.104.22.168/ HTTP/1.1 200 OK Content-Length: 4558 Content-Type: text/html Date: Mon, 26 Dec 2022 12:29:52 GMT Server: Kestrel ...
However, if the AppService is to be called via an NVA or other services, this service must support the rewriting of the
host header or other ways can be used to achieve this.
Variant 1: ASE
“The Azure App Service Environment v2 is an Azure App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale.” Because this is no longer a shared infrastructure, the call can also be made directly via IP address or without a host header value.
Variant 2: Application Gateway
The application gateway can rewrite the
host header in the backend settings. If the service in the backend is an Azure service, an encrypted connection to the backend can be used with
well known CA certificate. The
host value for the header can be taken directly from the backend or entered manually:
This means that a call to a backend can now be made via a custom domain (stored as a listener in the AppGW) or via the IP of the AppGW.
Variant 3: API Management
Azure API Management can encapsulate multiple APIs in the backend, control and monitor access to them, and support the entire API lifecycle. The Azure App Service can be stored as an API with the GET function in the APIM. The host header is automatically rewritten. All you have to do is add the App Service as a backend to an API:
The call can then be made via the URL of API Management or a custom domain. The API Management call as IP could be done with a Self-Hosted Gateway or Isolated API Management.
Variant 4: Custom Domain for the AppService
host header rewrite cannot be done, an alternative
host value can be included in the header directly on the first call. For example, if an NVA only supports forwarding to an IP, the NVA can be called up with an alternative URL that is also stored in the app service. For this purpose, a custom domain can be stored in the app service:
Subsequently, the target IP of the custom domain can be changed by pointing to another service (e.g. NVA or AppGW). This service can now forward to the App Service’s IP because the original host value of the header (custdom) is automatically passed:
The test via a configured Application Gateway succeeded:
~$ nslookup custdom.zuehlke.cloud ... Name: custdom.zuehlke.cloud Address: 22.214.171.124 :~$ curl -i http://custdom.zuehlke.cloud/ HTTP/1.1 200 OK Date: Mon, 26 Dec 2022 14:41:42 GMT Content-Type: text/html Content-Length: 4558 Connection: keep-alive Server: Kestrel ...
There are Azure services that do not support a host header rewrite. The following services are currently not support the feature:
- Azure Load Balancer
- NAT Gateways