Categories
Uncategorized

Using certs in code & trusting private CAs on App Service Linux

Summary

In a previous post I wrote about loading to the trusted root store on Windows Web Apps inside ASE, in order to trust privately issued certs. This is required if you connect over SSL to internal endpoints using privately issue certs, or make connections between sites in that ASE and use a private CA cert for the HTTPS binding.

Here I’ll share some comments that should help achieve a similar thing on Linux sites.

The reason for this post is to co-locate and explain a few important points about this setup which are a bit unclear.

Categories
Uncategorized

Azure Front Door (AFD) & App Gateway + App Service (Web App) unexpected issues and common solutions

Overview:

Documenting several common solutions for various Azure Front Door/App Gateway + App Service scenarios.

Why:

Proper configuration of any WAF or frontend proxy in front of App Service is an essential web infrastructure task for users. Even large organizations have trouble with this. Accurately understanding the scenario and possible solutions directly impacts the user’s ability to be successful using these Azure products.

Scenario:

This issue can surface in various ways. One of the most common issues is an unexpected redirect to and disclosure of the internal Azurewebsites.net hostname.

Client request passing through any frontend load balancer (AFD / AppGW / Cloudflare / WAF / etc) receives HTTP 301/302 redirect with Location response header revealing the backend Web App’s internal hostname (azurewebsites.net). This can commonly occur on trailing slash, post-auth redirect, or any URL the app code constructs based on request Host header.

Categories
Uncategorized

How to monitor and audit App Service Configuration and File changes

Overview

The ability to track and audit changes to websites is a common requirement among enterprises. This audit trail helps to identify who made changes and when, either accidentally or maliciously. When running an application on a local server there are many options to achieve this, however when running in Azure App Service we must rely on the features that the platform offers because there is no access to the machine itself.

How to

We will split this discussion into two parts, first to discuss configuration/setting changes and second for file system changes.

Categories
Uncategorized

Troubleshooting App Service failed VNET integration and outbound connectivity issues

Overview:

A significant part of a website’s functionality often involves outbound connectivity to dependencies like database, API, etc. Azure App Services have default outbound connectivity to the public Internet using its pool of outbound IPs and a capability to integrate with a VNET to achieve connectivity into a private network, including on-prem.

Two options for VNET integration in multi-tenant App Service currently exist:

I will not discuss these options in great detail here, but instead focus on how to troubleshoot general outbound connectivity issues to both public and private endpoints.

Categories
Uncategorized

Service Endpoints for Microsoft.Web: Secure access between App Gateway and Web Apps

A recent addition to Service Endpoints support is Microsoft.Web. Exactly as Service Endpoints for Azure Storage and Azure SQL allowed private access from a subnet to those PaaS services, Microsoft.Web Service Endpoints finally allows simple secure access to a backend App Service.

There are two parts to this setup:

  • Service Endpoints for Microsoft.Web must be enabled on the Application Gateway’s subnet
  • This subnet must be whitelisted in the Access Restrictions configuration for the backend Web App
Categories
Uncategorized

“Use for App Service” and Application Gateway Unexpected Consequences: azurewebsites.net redirect URL, odd App Behavior, failed Authentication, and broken ARR Affinity

The default behavior for an Application Gateway with App Service instance in the backend pool is that the Host header is overridden to match the Web App’s default hostname: *.azurewebsites.net. This is caused by the “Use for App Service” and “Pick host name from backend address” configuration options on the Application Gateway. These requests arrive at the App Service frontend and route to the destination based upon matching Host header.

While these settings make initial configuration easier, they do have a few consequences:

  1. Backend URL exposed when there is a redirect or URL that is built in application logic
  2. Application behavior issues when the client’s hostname or HTTP protocol do not match what arrives at the backend Web App
  3. Failed authentication when the auth provider sees the backend Host header, rather than the custom domain accessed by the user
  4. ARR Affinity is broken to the backend instances, because the Host header is mismatched
Categories
Uncategorized

App Service with Application Gateway v2: High Security in Azure PaaS

Azure App Services (Web Apps) are publicly exposed to the Internet by default, accessible with their *.azurewebsites.net URL. This means that anyone in the world can access your site simply by knowing its URL, including hackers and spammers.

We can secure our site by using an Application Gateway as a frontend. Azure App Gateway is an HTTP load balancer that allows you to manage traffic to your web apps. App Gateway operates at layer 7 (application layer) and can scan incoming requests using OWASP common vulnerabilities rule set and/or route based on URL syntax. The App Gateway offers many other features including DDoS protection: https://docs.microsoft.com/en-us/azure/application-gateway/overview.

Application Gateway v2 is currently in public preview with upcoming general availability. Organizations and individuals concerned with security/compliance in the cloud can leverage these services for an isolated environment where their backend Web App is entirely secured.

Here’s what it looks like:

Categories
Uncategorized

Connect between Apps in the same ASE: Adding internal CA certs to the trusted root store for Web Apps hosted in ASE

By default applications running in an App Service will only have the normal public CAs in the trusted root store. This means that SSL connections against endpoints with a privately issued certificate will fail as untrusted. One common error message in this scenario is “SSL Certificate problem: unable to get local issuer certificate”.

A common scenario for this might be hosting 2 App Services inside an ILB ASE, one frontend and one backend, and making HTTPS calls from one -> to the other. Another scenario would be connecting from the Web App to an on-prem API secured with a self-signed or privately issued certificate.

The official Azure documentation is here: https://docs.microsoft.com/en-us/azure/app-service/environment/certificates#private-client-certificate.

The first step is to ensure that the target hostname is resolvable from the Web App, if it is hosted only in internal DNS. This step is possible for all App Services. Installing certs to the trusted root store is only currently possible using the more expensive App Service Environment (ASE).

Categories
Uncategorized

Supporting IPv6 in Azure App Service using an Azure Front Door frontend

Many developers would like their website to have support for IPv6 connectivity. Unfortunately IPv6 is not yet widely supported for most Azure services, including App Service, which includes Web Apps/Function Apps/Bot Service/etc.

The good news is that this is possible to achieve using Azure Front Door as a frontend, which does support IPv6. The Azure Front Door will then reach the Web App over IPv4.