| title | description | tags | ms.topic | ms.date | ms.reviewer | ms.custom |
|---|---|---|---|---|---|---|
Secure a custom DNS with a TLS/SSL binding |
Secure HTTPS access to your custom domain by creating a TLS/SSL binding with a certificate. Improve your website's security by enforcing HTTPS or TLS 1.2. |
buy-ssl-certificates |
tutorial |
05/13/2021 |
yutlin |
seodec18 |
This article shows you how to secure the custom domain in your App Service app or function app by creating a certificate binding. When you're finished, you can access your App Service app at the https:// endpoint for your custom DNS name (for example, https://www.contoso.com).
Securing a custom domain with a certificate involves two steps:
- Add a private certificate to App Service that satisfies all the private certificate requirements.
- Create a TLS binding to the corresponding custom domain. This second step is covered by this article.
In this tutorial, you learn how to:
[!div class="checklist"]
- Upgrade your app's pricing tier
- Secure a custom domain with a certificate
- Enforce HTTPS
- Enforce TLS 1.1/1.2
- Automate TLS management with scripts
To follow this how-to guide:
- Create an App Service app
- Map a domain name to your app or buy and configure it in Azure
- Add a private certificate to your app
Note
The easiest way to add a private certificate is to create a free App Service managed certificate.
[!INCLUDE Prepare your web app]
Do the following steps:
In the Azure portal, from the left menu, select App Services > <app-name>.
From the left navigation of your app, start the TLS/SSL Binding dialog by:
- Selecting Custom domains > Add binding
- Selecting TLS/SSL settings > Add TLS/SSL binding
In Custom Domain, select the custom domain you want to add a binding for.
If your app already has a certificate for the selected custom domain, go to Create binding directly. Otherwise, keep going.
If your app has no certificate for the selected custom domain, then you have two options:
- Upload PFX Certificate - Follow the workflow at Upload a private certificate, then select this option here.
- Import App Service Certificate - Follow the workflow at Import an App Service certificate, then select this option here.
Note
You can also Create a free certificate or Import a Key Vault certificate, but you must do it separately and then return to the TLS/SSL Binding dialog.
Use the following table to help you configure the TLS binding in the TLS/SSL Binding dialog, then click Add Binding.
| Setting | Description |
|---|---|
| Custom domain | The domain name to add the TLS/SSL binding for. |
| Private Certificate Thumbprint | The certificate to bind. |
| TLS/SSL Type |
|
Once the operation is complete, the custom domain's TLS/SSL state is changed to Secure.
Note
A Secure state in the Custom domains means that it is secured with a certificate, but App Service doesn't check if the certificate is self-signed or expired, for example, which can also cause browsers to show an error or warning.
If you don't use IP SSL in your app, skip to Test HTTPS for your custom domain.
There are two changes you need to make, potentially:
-
By default, your app uses a shared public IP address. When you bind a certificate with IP SSL, App Service creates a new, dedicated IP address for your app. If you mapped an A record to your app, update your domain registry with this new, dedicated IP address.
Your app's Custom domain page is updated with the new, dedicated IP address. Copy this IP address, then remap the A record to this new IP address.
-
If you have an SNI SSL binding to
<app-name>.azurewebsites.net, remap any CNAME mapping to point tosni.<app-name>.azurewebsites.netinstead (add thesniprefix).
In various browsers, browse to https://<your.custom.domain> to verify that it serves up your app.
:::image type="content" source="./media/configure-ssl-bindings/app-with-custom-ssl.png" alt-text="Screenshot showing an example of browsing to your custom domain with the contoso.com URL highlighted.":::
Your application code can inspect the protocol via the "x-appservice-proto" header. The header will have a value of http or https.
Note
If your app gives you certificate validation errors, you're probably using a self-signed certificate.
If that's not the case, you may have left out intermediate certificates when you export your certificate to the PFX file.
Your inbound IP address can change when you delete a binding, even if that binding is IP SSL. This is especially important when you renew a certificate that's already in an IP SSL binding. To avoid a change in your app's IP address, follow these steps in order:
- Upload the new certificate.
- Bind the new certificate to the custom domain you want without deleting the old one. This action replaces the binding instead of removing the old one.
- Delete the old certificate.
By default, anyone can still access your app using HTTP. You can redirect all HTTP requests to the HTTPS port.
In your app page, in the left navigation, select TLS/SSL settings. Then, in HTTPS Only, select On.
When the operation is complete, navigate to any of the HTTP URLs that point to your app. For example:
http://<app_name>.azurewebsites.nethttp://contoso.comhttp://www.contoso.com
Your app allows TLS 1.2 by default, which is the recommended TLS level by industry standards, such as PCI DSS. To enforce different TLS versions, follow these steps:
In your app page, in the left navigation, select TLS/SSL settings. Then, in TLS version, select the minimum TLS version you want. This setting controls the inbound calls only.
When the operation is complete, your app rejects all connections with lower TLS versions.
In App Service, TLS termination happens at the network load balancers, so all HTTPS requests reach your app as unencrypted HTTP requests. If your app logic needs to check if the user requests are encrypted or not, inspect the X-Forwarded-Proto header.
Language specific configuration guides, such as the Linux Node.js configuration guide, shows you how to detect an HTTPS session in your application code.
[!code-azureclimain]
[!code-powershellmain]