Configuring Networking in Azure App Service
The course is part of these learning pathsSee 2 more
In this course, we’ll cover the most commonly used networking configurations in Azure App Service, including how to create a custom domain name for your app, how to enable TLS/SSL, and different ways of controlling inbound and outbound connections to and from your app.
- Create a custom domain name for your Azure App Service app
- Enable TLS/SSL so people can reach your Azure App Service app using HTTPS
- Control inbound and outbound connections to and from your Azure App Service app
- Anyone who needs to configure networking on Azure App Service
- Experience using Azure App Service (or take our Introduction to Azure App Service course)
- Experience with Azure networking (or take our Getting Started with Azure Virtual Networks course)
- Knowledge of DNS (Domain Name System)
After you’ve configured a custom domain for your app, it will only be accessible at a URL starting with “http”, which is an insecure protocol. These days, every website should be able to respond to requests over HTTPS, which is the secure version of HTTP. To set that up, you need to enable TLS/SSL, which takes a bit of work.
First, you need to make sure that the tier of your App Service Plan is at least Basic because the Free and Shared tiers don’t support TLS/SSL for custom domains.
Second, you need to have a TLS/SSL certificate file. This type of file contains a private key and a certificate with a public key. These are needed for a couple of reasons. First, the public/private key pair is used to encrypt and decrypt traffic between the website and the browser of anyone visiting the site. Second, the certificate verifies that the browser is interacting directly with the website.
This might seem like an unnecessary step, but it helps prevent something called a man-in-the-middle attack. This is where another computer is intercepting messages between two parties (the web server and the browser in this case) and listening in on the conversation. In some cases, it will even change the messages. However, if the web server starts an encrypted conversation by presenting a certificate that is verified by a trusted certificate authority, then the browser can be sure that it’s communicating directly with the webserver.
Third, you need to create a TLS binding to your custom domain.
Now let’s get into the details of how to do steps 2 and 3. So where do you get a certificate file? The easiest way is to use the free App Service managed certificate. It’s provided by Digicert, which is the certificate authority that verifies the authenticity of the certificate. This solution won’t work in all cases, but it works for most situations, and it’s free, so it’s hard to beat that. If you need to do something special, then you can import a certificate file that you obtained from somewhere else.
To create a free certificate, go into the TLS/SSL settings for your App Service app, then select Private Key Certificates, and click Create App Service Managed Certificate. Then tell it which custom domain you want to create the certificate for, and that’s it.
Once you have a private key certificate, whether it’s a free one or one that you imported from elsewhere, then you can bind TLS/SSL to your domain.
Other than specifying the custom domain and the certificate, you need to tell it whether to use SNI SSL or IP SSL. SNI SSL binds the certificate using the website’s hostname, while IP SSL binds the certificate to the website’s IP address. SNI SSL gives you more flexibility, and it’s easier to configure, so it’s usually the best choice. The only disadvantage is that it doesn’t work on really old browsers, and when I say “really old”, I mean it. All major browsers have provided support for SNI SSL since 2007.
Once you’ve bound your certificate to your custom domain, people will be able to access your app using HTTPS. However, they’ll still be able to access it using HTTP, which is not encrypted, so if you want to ensure that everyone will access your site over HTTPS, then you can select the “HTTPS only” option in your app’s TLS/SSL settings. There’s also a “Minimum TLS Version” option. By default, it’s set to 1.2, which is the recommended version, but you can set it to 1.0 or 1.1 if you want to support older browsers. It’s usually best to leave it set to 1.2, though.
As I mentioned earlier, one of the benefits of binding a certificate to a custom domain is that it lets a client device know that it’s communicating with a legitimate website and not a hacker. But the website has no way of knowing that’s it’s communicating with a legitimate client and not a hacker. If you require that level of security, then you can enable TLS mutual authentication. This is also known as client certificate authentication. It’s typically used only within an individual organization because it requires that all client devices have a client certificate.
To enable this, you need to go into the general configuration settings for your app, and set “Client certificate mode” to “Require”. You have to do more to make it work, though, because App Service doesn’t handle the client authentication. It just forwards the client certificate to your app. So, you need to add code to your app to handle the authentication. App Service forwards the client certificate as a base-64 encoded value in an X-ARR-ClientCert request header.
And that’s it for enabling TLS/SSL.
Guy launched his first training website in 1995 and he's been helping people learn IT technologies ever since. He has been a sysadmin, instructor, sales engineer, IT manager, and entrepreneur. In his most recent venture, he founded and led a cloud-based training infrastructure company that provided virtual labs for some of the largest software vendors in the world. Guy’s passion is making complex technology easy to understand. His activities outside of work have included riding an elephant and skydiving (although not at the same time).