6.5 App Service Certificates, TLS, Custom Domains, and Networking

Custom domains and DNS validation

Every App Service app receives a default hostname such as <app-name>.azurewebsites.net. Production apps usually need a custom hostname such as www.contoso.com or api.contoso.com. Before App Service accepts the hostname, Azure must verify that you control the domain. This is done through DNS records at the domain's DNS host.

Common record patterns are CNAME for subdomains and A records for apex domains. A www hostname often uses a CNAME that points to the Azure default hostname. An apex domain such as contoso.com usually needs an A record to the app's inbound IP address, plus validation records as required by the portal. TXT records are often used to prove ownership and prevent takeover risk.

Portal path: App Service > Custom domains > Add custom domain. The portal shows required DNS records and validation status. If validation fails, do not change the App Service plan first. Check public DNS propagation, record name, record type, target value, and whether the domain is managed in Azure DNS or an external registrar.

TLS and certificates

TLS for App Service requires a certificate and a binding to the custom hostname. App Service managed certificates are convenient for many simple custom domains, but they have limitations. Imported certificates are used when the organization already owns a certificate or needs a specific certificate authority, wildcard, or policy. App Service certificates can also be purchased and managed through Azure in supported scenarios.

Portal path: App Service > Certificates for certificate inventory and App Service > Custom domains for binding certificates to hostnames. You can enforce HTTPS-only and configure the minimum TLS version in TLS/SSL settings. If the requirement says users must not access the site over HTTP, enable HTTPS-only after a valid certificate binding exists.

CLI examples:

az webapp config hostname add \
  --resource-group rg-web \
  --webapp-name exam-web-prod \
  --hostname www.contoso.com

az webapp update \
  --resource-group rg-web \
  --name exam-web-prod \
  --https-only true

Exam questions may present a site that works at azurewebsites.net but fails on the custom domain. Separate the layers. DNS maps the name. App Service hostname binding authorizes the name on the app. The certificate secures HTTPS for the name. Access restrictions or private endpoints determine whether clients can reach it.

Inbound and outbound networking

App Service has several network features that are easy to confuse. Access restrictions control inbound access to the public endpoint by allowing or denying client IP ranges, service tags, or virtual network sources in supported configurations. Private endpoint provides private inbound access to the web app from a virtual network. VNet integration is primarily for outbound traffic from the app to resources in a virtual network.

VNet integration does not make the app privately reachable. This is one of the most important traps. It lets the app send outbound traffic into a VNet. If users need to access the app privately, use a private endpoint for inbound access. Conversely, a private endpoint for the app does not automatically grant the app outbound access to a private database; configure outbound integration and DNS as needed.

Private DNS and name resolution

Private endpoint scenarios often fail because the network path exists but DNS still resolves to a public endpoint. For App Service connecting to a private endpoint dependency, the app must be integrated with a VNet that can resolve the dependency's private DNS name. If a SQL server, storage account, or Key Vault has public network access disabled, the app must resolve and route to the private endpoint.

The same DNS concept applies to inbound private endpoint access to the web app. Private clients should resolve the web app hostname to the private endpoint IP where appropriate. In Azure, this is usually handled with private DNS zones linked to the VNet. In hybrid environments, DNS forwarding may be required.

Troubleshooting path for private access:

1. Confirm the correct feature: private endpoint for inbound, VNet integration for outbound.
2. Confirm subnet and region requirements for the chosen feature.
3. Confirm private DNS zone records and VNet links.
4. Confirm public network access or access restrictions are set intentionally.
5. Test name resolution from the client or workload network.
6. Check logs on the app and dependency.

Portal versus CLI

The portal is often the fastest way to add and validate custom domains because it shows exact DNS records. Use the portal for certificate binding when learning or troubleshooting. Use CLI, ARM, or Bicep when deploying repeatable environments, especially for access restrictions, VNet integration, and hostname configuration.

Portal paths to memorize: Custom domains, Certificates, TLS/SSL settings, Networking, Access restrictions, and Identity. Many exam tasks use those names directly. If a lab-style task asks where to make a change, those labels matter.

Exam traps

Do not choose a certificate as the first step when the domain has not been validated or bound. Do not choose VNet integration when the requirement is private inbound access to the web app. Do not choose private endpoint when the only requirement is that the app call a database over a VNet; that requirement points first to outbound VNet integration for the app and private endpoint or service endpoint behavior for the dependency.

Do not assume that TLS fixes DNS. A valid certificate cannot help clients reach the wrong IP. Do not assume DNS validation fixes HTTPS. A custom domain can be validated but still lack a TLS binding. Work layer by layer: DNS ownership, hostname binding, certificate binding, HTTPS policy, inbound controls, outbound connectivity, and DNS resolution for private dependencies.