The website of Nordlicht Reisen GmbH, a fictional travel agency, runs in App Service (lesson 3.7). Now it should be reachable at www.example.com, with a valid certificate, backed up regularly, open only to certain networks, and with a staging stage where new versions are checked before customers see them. The exam calls this: configure certificates and TLS, map a custom DNS name, set up backup, configure networking settings, and use deployment slots.
Prior knowledge: How TLS and certificates work is covered in K3, lesson 3.0.4 ("TLS and the chain of trust"). What Front Door and a web application firewall in front of an app do is covered in K3, lesson 3.3.4. Here you learn how to configure this on an app. Azure DNS and private endpoints are covered in lessons 4.5 and 4.4.
Certificates and TLS
For <app>.azurewebsites.net, Azure takes care of it itself: the default name is secured by a wildcard certificate. A custom domain needs a certificate of its own. Your plan must be at least the Basic tier.
| Option | Description |
|---|---|
| App Service Managed Certificate | free, fully managed, renews itself; issued by DigiCert |
| App Service Certificate | purchased (from GoDaddy, according to Microsoft), stored in your Key Vault, exportable |
| Import from Key Vault | you manage a PKCS12 certificate in the Key Vault (K3, lesson 3.3.2) |
| Upload a PFX | you already have a private certificate |
The managed certificate has limits: no wildcards, not exportable, not for private DNS zones, not in an App Service Environment, only letters, digits, hyphens, and periods, domain name up to 64 characters. Prerequisites: A subdomain needs a CNAME record that points directly to <app>.azurewebsites.net; an intermediate target blocks issuance and renewal. An apex domain (example.com) needs an A record pointing to the app's IP address, and the app must not have IP restrictions, because issuance and renewal require that the app be reachable from the internet. For some domains, a CAA record must allow DigiCert (0 issue digicert.com). The issuer and the key may change; for that reason, do not "pin" the certificate.
az webapp config ssl create --resource-group <group> --name <app> --hostname www.example.com
az webapp config ssl bind --resource-group <group> --name <app> --certificate-thumbprint <thumbprint> --ssl-type SNI
According to the reference, ssl create is in preview. In the portal, go to the app's Certificates page, open Managed certificates, and choose Add certificate, or open Custom domains, choose Add binding for the domain, and pick Create App Service Managed Certificate as the source. Only the binding assigns the certificate to the domain. There are two kinds:
| SNI SSL | IP-based SSL | |
|---|---|---|
| Number of bindings | any number, several certificates on one IP | only one; dedicated IP address |
| From tier | Basic | Standard |
| Follow-up work | none | switch the A record to the new IP |
| Cost | free | hourly fee per IP-based connection (some Standard tiers include one) |
HTTPS Only redirects HTTP to HTTPS (az webapp update --https-only true). You set the minimum TLS version with az webapp config set --min-tls-version 1.2. There are two separate settings, one for the app and one for the management site (SCM/Kudu); both should be 1.2 or higher. You set the SCM setting with az resource update … --set properties.scmMinTlsVersion=1.2. Microsoft gives May 31, 2027 as the deadline by which you should do this, because the platform removes TLS 1.0 and 1.1 then. Slots have their own settings.