Can I use a Managed Certificate for an apex (root) domain like contoso.com?

No, Managed Certificates require CNAME-based domain validation, which isn't possible for an apex domain (DNS doesn't allow a CNAME at the zone apex), so an apex domain must use an A record pointing at the App Service's IP and a certificate sourced another way, typically a KeyVaultCertificate with your own issued certificate. Attempting to request a Managed Certificate for an apex domain fails, this is a hard platform constraint tied to how domain validation works, not a configuration option to enable.

What's the verificationTxt record actually for, separate from the CNAME/A record?

It's a domain ownership verification step (using an asuid-prefixed TXT record) that proves you control the domain before App Service will accept the custom domain binding, this is separate from and in addition to the CNAME or A record that actually routes traffic to your app. Both need to be correctly configured, the TXT record for ownership verification and the CNAME/A record for actual traffic routing.

Does a KeyVaultCertificate auto-renew the way a ManagedCertificate does?

Not automatically in the same hands-off way, a KeyVaultCertificate references a certificate you're responsible for renewing (whether that renewal itself is automated via Key Vault's own certificate lifetime actions, as covered by the Key Vault certificate policy tool, or manual), App Service just consumes whatever certificate currently exists at that Key Vault reference. If the underlying Key Vault certificate expires without being renewed, the App Service binding using it breaks, App Service itself doesn't renew it for you the way it does for Managed Certificates.

Azure App Service Custom Domain Builder

ComputeAzure

Build App Service custom domain configs with managed certificates, Key Vault certificates, DNS validation, and TLS settings.

Azure App Service Configuration

Build App Service custom domain configs with managed certificates, Key Vault certificates, DNS validation records, and TLS settings.

Required Fields

appServiceNameresourceGroupcustomDomainscustomDomains[0].hostNamecustomDomains[0].certificate.typecustomDomains[0].dnsConfiguration.recordType

{
  "appServiceName": "app-contoso-api-prod",
  "resourceGroup": "rg-app-prod",
  "location": "eastus2",
  "customDomains": [
    {
      "hostName": "api.contoso.com",
      "hostNameType": "Verified",
      "sslState": "SniEnabled",
      "certificate": {
        "type": "ManagedCertificate",
        "minimumTlsVersion": "1.2"
      },
      "dnsConfiguration": {
        "recordType": "CNAME",
        "recordName": "api",
        "recordValue": "app-contoso-api-prod.azurewebsites.net",
        "verificationTxt": {
          "recordName": "asuid.api",
          "recordValue": "A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2"
        }
      }
    },
    {
      "hostName": "contoso.com",
      "hostNameType": "Verified",
      "sslState": "SniEnabled",
      "certificate": {
        "type": "ManagedCertificate",
        "minimumTlsVersion": "1.2"
      },
      "dnsConfiguration": {
        "recordType": "A",
        "recordName": "@",
        "recordValue": "20.62.134.100",
        "verificationTxt": {
          "recordName": "asuid",
          "recordValue": "A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2C3D4E5F6A1B2"
        }
      }
    },
    {
      "hostName": "staging-api.contoso.com",
      "hostNameType": "Verified",
      "sslState": "SniEnabled",
      "certificate": {
        "type": "KeyVaultCertificate",
        "keyVaultId": "/subscriptions/a1b2c3d4/resourceGroups/rg-security/providers/Microsoft.KeyVault/vaults/kv-contoso-prod",
        "keyVaultSecretName": "wildcard-contoso-com",
        "minimumTlsVersion": "1.2"
      },
      "dnsConfiguration": {
        "recordType": "CNAME",
        "recordName": "staging-api",
        "recordValue": "app-contoso-api-prod-staging.azurewebsites.net"
      }
    }
  ],
  "httpsRedirect": true,
  "clientCertificateMode": "Optional"
}

Generated Output

Output will appear here...

About This Tool

Build App Service custom domain bindings mixing certificate sourcing strategies per domain, ManagedCertificate (Azure-issued and auto-renewed, but CNAME-only, not usable for an apex/root domain) versus KeyVaultCertificate (your own certificate referenced from Key Vault, usable for any record type including apex A records). This distinction is the most consequential decision in this configuration: the example correctly uses a CNAME-based ManagedCertificate for the api.contoso.com subdomain but must fall back to an A-record-based approach for the apex contoso.com domain, since a managed certificate specifically requires the CNAME validation path that an apex domain's A record can't provide, picking ManagedCertificate for an apex domain fails certificate issuance, not silently, but in a way that's confusing if you don't already know this constraint exists.

When to Use This Tool

•Using ManagedCertificate for any subdomain (api.contoso.com) that can use a CNAME record, getting free, auto-renewed TLS with zero certificate lifecycle management, versus needing a KeyVaultCertificate for the apex domain (contoso.com) which can only use an A record.
•Referencing a wildcard certificate already stored in Key Vault (wildcard-contoso-com) for a staging subdomain, so the same wildcard cert covers multiple environments' subdomains without issuing a separate certificate per environment.
•Setting minimumTlsVersion to 1.2 explicitly across all custom domain bindings, rather than relying on a platform default that might be more permissive than your security policy requires.
•Configuring the verificationTxt record (asuid prefix) as part of domain ownership verification, a required DNS step before App Service will accept the custom domain binding at all, distinct from the CNAME/A record that actually routes traffic.

Pro Tips

TIP

Never attempt a ManagedCertificate for an apex domain, it's a hard platform constraint that fails at certificate issuance, plan apex domains for KeyVaultCertificate (or another certificate source) from the start rather than discovering the CNAME requirement mid-setup.

TIP

The TXT-based domain verification step is separate from the traffic-routing CNAME/A record, and it's easy to configure one but forget the other, both are required for the custom domain binding to succeed.

TIP

A KeyVaultCertificate-backed binding depends entirely on that certificate being kept current in Key Vault, pair it with the Key Vault certificate policy's own auto-renewal and expiry-notification lifetimeActions, don't assume App Service handles renewal the way it does for its own Managed Certificates.

How It Works Under the Hood

The builder validates that appServiceName, resourceGroup, customDomains, and the first domain's hostName/certificate.type/dnsConfiguration.recordType all resolve before accepting the JSON as a valid custom domain binding configuration; it can't verify the DNS records are actually published and propagated, or that an apex domain hasn't been mistakenly paired with a ManagedCertificate type, that specific mismatch is only caught by the live API at certificate provisioning time.

Frequently Asked Questions

Can I use a Managed Certificate for an apex (root) domain like contoso.com?: No, Managed Certificates require CNAME-based domain validation, which isn't possible for an apex domain (DNS doesn't allow a CNAME at the zone apex), so an apex domain must use an A record pointing at the App Service's IP and a certificate sourced another way, typically a KeyVaultCertificate with your own issued certificate. Attempting to request a Managed Certificate for an apex domain fails, this is a hard platform constraint tied to how domain validation works, not a configuration option to enable.
What's the verificationTxt record actually for, separate from the CNAME/A record?: It's a domain ownership verification step (using an asuid-prefixed TXT record) that proves you control the domain before App Service will accept the custom domain binding, this is separate from and in addition to the CNAME or A record that actually routes traffic to your app. Both need to be correctly configured, the TXT record for ownership verification and the CNAME/A record for actual traffic routing.
Does a KeyVaultCertificate auto-renew the way a ManagedCertificate does?: Not automatically in the same hands-off way, a KeyVaultCertificate references a certificate you're responsible for renewing (whether that renewal itself is automated via Key Vault's own certificate lifetime actions, as covered by the Key Vault certificate policy tool, or manual), App Service just consumes whatever certificate currently exists at that Key Vault reference. If the underlying Key Vault certificate expires without being renewed, the App Service binding using it breaks, App Service itself doesn't renew it for you the way it does for Managed Certificates.

Related Learning Guides

Azure VM Series Guide22 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.