This chapter covers App Service Managed Certificates, a free and automated TLS/SSL certificate option for custom domains in Azure App Service. On the AZ-204 exam, security topics constitute approximately 15–20% of questions, with managed certificates being a key sub-topic under objective 3.2 (Secure data and applications). Understanding when to use managed certificates versus other certificate options (App Service Certificate, Bring Your Own Certificate) is critical for cost optimization and security compliance. This chapter provides a deep dive into the mechanics, configuration, limitations, and exam traps associated with managed certificates.
Jump to a section
Imagine you run a busy office building with 100 tenants, each needing a monthly parking permit that must be renewed every 30 days. You could hire a full-time clerk to manually collect forms, verify identities, and issue new permits each month—that's like buying and manually renewing certificates from a CA. Alternatively, you could install an automated kiosk in the lobby that tenants swipe their ID card through. The kiosk checks a central database to confirm the tenant still occupies their unit, then prints a new permit instantly. The kiosk automatically re-checks each tenant's eligibility 7 days before expiration and issues a renewal if still valid. If a tenant moves out, the kiosk refuses renewal. This is exactly how App Service Managed Certificates work: Azure automatically handles renewal by verifying domain ownership (via DNS or app service identity) and re-issuing the certificate before expiration, without any manual intervention. The 'tenant ID card' is the domain verification token, and the 'central database' is the App Service's domain binding configuration. Just as the kiosk can't issue a permit for a tenant that has vacated, Azure can't renew a certificate if the domain is no longer bound to the app or the DNS record is removed.
What are App Service Managed Certificates?
App Service Managed Certificates are free TLS/SSL certificates provided by Microsoft for custom domains in Azure App Service. They are issued by a trusted certificate authority (DigiCert, as of 2025) and are automatically renewed as long as the domain remains bound to the app and the required DNS records exist. They are designed to simplify certificate management for basic TLS scenarios, eliminating the need to purchase, upload, or manually renew certificates.
How They Work Internally
When you create a managed certificate for a custom domain (e.g., app.contoso.com) in an App Service app, Azure performs the following steps:
1. Domain Validation: Azure verifies that you own the domain. This is done either by:
- DNS Validation: You add a TXT record with a specific value (e.g., asuid.app.contoso.com pointing to a validation token) to your DNS zone. Azure checks for this record.
- App Service Identity Validation: If the custom domain is already bound to the App Service app, Azure can validate ownership automatically because the app itself is a trusted entity.
Certificate Issuance: Once validated, Azure requests a certificate from DigiCert. The certificate is bound to the App Service app and includes the custom domain name in the Subject Alternative Names (SANs).
Automatic Renewal: Starting 60 days before expiration, Azure attempts to renew the certificate automatically. The renewal process re-validates domain ownership using the same method as initial issuance. If validation succeeds, a new certificate is issued and bound to the app. If validation fails (e.g., DNS record removed), the certificate is not renewed and will expire.
Binding: The certificate is automatically bound to the custom domain's TLS/SSL settings (SNI-based). You can also choose to bind it to the IP address if needed, but managed certificates only support SNI bindings.
Key Components, Values, Defaults, and Timers
Certificate Type: Managed certificate (free, auto-renewed).
Issuer: DigiCert (Microsoft's partner CA).
Validity Period: 1 year from issuance.
Renewal Attempt Window: Starts 60 days before expiration.
Renewal Frequency: Every 60 days (if validation fails, it retries periodically).
Supported Domains: Only custom domains added to the App Service app. Wildcard domains (e.g., *.contoso.com) are NOT supported. Naked domains (e.g., contoso.com) are supported.
Binding Type: SNI only (no IP-based SSL for managed certificates).
Limitations:
Only for App Service apps (Web Apps, API Apps, Mobile Apps, Function Apps in App Service plan).
Not supported in App Service Environment (ASE) v1/v2; ASE v3 supports them.
Not supported for Azure Functions running in Consumption plan (only App Service plan).
Maximum of 10 managed certificates per App Service plan (soft limit, can be increased via support ticket).
Cannot be exported (private key is not accessible).
Cannot be used with Azure Front Door, Application Gateway, or other Azure services that require a PFX file.
Configuration and Verification Commands
To create a managed certificate using Azure CLI:
# Add a custom domain to the webapp (if not already done)
az webapp config hostname add --resource-group <group> --webapp-name <app> --hostname <customdomain>
# Create a managed certificate
az webapp config ssl create --resource-group <group> --webapp-name <app> --hostname <customdomain> --name <certificate-name>To verify the certificate is created and bound:
az webapp config ssl list --resource-group <group> --webapp-name <app>To bind the certificate (if not automatically bound):
az webapp config ssl bind --resource-group <group> --webapp-name <app> --certificate-thumbprint <thumbprint> --ssl-type SNIInteraction with Related Technologies
Azure DNS: Managed certificates rely on DNS validation. If you use Azure DNS, you can configure validation records automatically. If using an external DNS provider, you must manually add/update records for renewal to succeed.
App Service Authentication/Authorization: Managed certificates do not affect the authentication layer; they only provide TLS for inbound traffic.
Azure Key Vault: Managed certificates are not stored in Key Vault. If you need to export the certificate or use it with other services, you must use an App Service Certificate (imported from Key Vault) or bring your own.
Azure Front Door / Application Gateway: These services require a PFX certificate. Managed certificates cannot be exported, so you must use a different certificate type if you need to terminate TLS at the edge.
Exam-Relevant Details
Cost: Managed certificates are FREE. This is a common exam point — candidates often think they must pay for any SSL certificate.
Renewal: Automatic, but requires domain validation to succeed. If the DNS record is missing at renewal time, the certificate will expire, causing TLS errors.
Limitations: No wildcard, no export, SNI only. The exam may present a scenario requiring wildcard or IP-based SSL and ask you to choose the correct certificate type.
ASE: In App Service Environment (ASE) v1/v2, managed certificates are not supported. Use App Service Certificate or BYOC. ASE v3 supports managed certificates.
Function Apps: Only supported when running in an App Service plan (not Consumption plan).
Common Pitfalls
Assuming managed certificates support wildcard domains: They do NOT. For wildcard, use App Service Certificate (paid) or bring your own.
Thinking managed certificates can be exported: They are non-exportable. If you need to install the same certificate elsewhere, you must use a different option.
Believing renewal is guaranteed: Renewal depends on domain validation. If you change DNS records or remove the domain binding, renewal fails.
Step-by-Step Configuration (Azure Portal)
Navigate to your App Service app in the Azure portal.
Under Settings, select TLS/SSL settings.
Click Private Key Certificates (.pfx) tab.
Click Create App Service Managed Certificate.
Select the custom domain from the dropdown (must already be added to the app).
Click Create.
After creation, the certificate appears in the list. Click Bind to associate it with the domain (or it may auto-bind).
Select the domain and SNI SSL type, then click Add Binding.
Verification
Check the certificate thumbprint using az webapp config ssl list.
Browse to https://yourdomain.com and view the certificate details in the browser.
The certificate should be issued to your domain, with DigiCert as the issuer.
Add custom domain to App Service
Before creating a managed certificate, the custom domain must be added to the App Service app. This is done via the Azure portal under 'Custom domains' or using CLI: `az webapp config hostname add`. The domain must have a DNS A record (pointing to the app's IP) or a CNAME record (pointing to the app's default hostname, e.g., `myapp.azurewebsites.net`). Azure verifies ownership by checking that the DNS record exists. Without this step, the domain is not associated with the app and the managed certificate cannot be created.
Create managed certificate
In the Azure portal, go to TLS/SSL settings > Private Key Certificates > Create App Service Managed Certificate. Select the custom domain from the dropdown. Azure initiates domain validation: it checks for a TXT record `asuid.<domain>` with a specific token, or uses app identity validation if the domain is already bound. If validation succeeds, Azure requests a certificate from DigiCert. The certificate is generated and stored within the App Service infrastructure. The creation process typically takes a few minutes.
Bind certificate to domain
After creation, the certificate must be bound to the custom domain's TLS/SSL binding. By default, the certificate is automatically bound to the SNI-based binding for the domain. If not, you can manually bind by selecting the certificate and clicking 'Bind'. Choose the domain, SNI SSL type (the only option for managed certificates), and save. The binding updates the App Service's frontend to present the managed certificate when clients connect via HTTPS to the custom domain.
Automatic renewal process
Starting 60 days before the certificate's expiration, Azure attempts to renew the certificate automatically. It re-validates domain ownership using the same method as initial creation. If the DNS records (TXT or app identity) are still present and valid, Azure requests a new certificate from DigiCert. The new certificate is bound to the app, replacing the old one. If validation fails, Azure retries periodically. If renewal fails until expiration, the certificate expires and TLS connections will show errors.
Monitor certificate status
You can monitor the status of managed certificates in the Azure portal under TLS/SSL settings. The certificate list shows expiration dates and the last renewal attempt. Use Azure Monitor alerts to notify you if a certificate is about to expire or if renewal fails. CLI command `az webapp config ssl list` shows thumbprints and expiration. Regular monitoring is recommended because automatic renewal can fail if DNS records are removed or if the domain binding is broken.
Enterprise Scenario 1: SaaS Application with Multiple Tenant-Specific Domains
A SaaS company hosts a multi-tenant application on Azure App Service. Each tenant gets a custom subdomain (e.g., tenant1.contoso.com, tenant2.contoso.com). The company uses a wildcard certificate *.contoso.com purchased from a third-party CA. However, they want to reduce costs and simplify management. They switch to managed certificates by adding each tenant's subdomain as a custom domain and creating a managed certificate for each. This eliminates the need to purchase and renew the wildcard certificate. The challenge is the 10-certificate limit per App Service plan. With hundreds of tenants, they must either use multiple App Service plans or request a limit increase. They also ensure that DNS validation records are maintained for each subdomain. In production, they automate certificate creation using Azure CLI scripts triggered by new tenant onboarding. Misconfiguration occurs when a tenant's DNS record is accidentally deleted, causing certificate renewal to fail and TLS errors for that tenant. They implement Azure Monitor alerts to detect renewal failures.
Enterprise Scenario 2: E-Commerce Platform with Naked Domain and Subdomains
An e-commerce platform uses contoso.com (naked domain) and www.contoso.com. They want TLS for both. They add both domains to the App Service app. They create a managed certificate for contoso.com and another for www.contoso.com. The platform also has a payment subdomain pay.contoso.com that requires a certificate. They add that domain and create a third managed certificate. The certificates are automatically renewed. However, the platform also needs a certificate for internal services (e.g., api.internal.contoso.com) that is not exposed to the internet. Managed certificates cannot be used because the domain is not bound to a public App Service app. They use a self-signed certificate for internal traffic. The exam might test that managed certificates are only for custom domains bound to the app, not for internal-only domains.
Scenario 3: Migration from App Service Certificate to Managed Certificate
A company has been using an App Service Certificate (paid, imported from Key Vault) for app.contoso.com. They want to save costs. They check that app.contoso.com is a custom domain bound to the app. They create a managed certificate for the domain. They then unbind the old App Service Certificate and bind the managed certificate. The managed certificate automatically renews. They verify that the site works over HTTPS. They keep the old App Service Certificate as a backup. Common mistake: they forget to remove the old binding, causing both certificates to be bound (only one is active). The exam may ask which certificate type is free and auto-renewed.
AZ-204 Exam Focus on Managed Certificates
This topic falls under objective 3.2: Secure data and applications. Specifically, it relates to implementing secure access for applications by configuring TLS/SSL certificates. The exam expects you to:
Differentiate between Managed Certificates, App Service Certificates, and Bring Your Own Certificate (BYOC).
Know the limitations: no wildcard, no export, SNI only, free, auto-renewed.
Understand the renewal dependency on domain validation.
Recognize scenarios where managed certificates are appropriate vs. when another option is needed.
Common Wrong Answers and Why Candidates Choose Them
Choosing App Service Certificate (paid) for a simple custom domain when a managed certificate would suffice. Candidates often assume any certificate costs money. They don't realize managed certificates are free. The exam will try to trick you by offering a paid option that works but is unnecessary.
Selecting a wildcard certificate when the scenario only requires specific subdomains. Candidates think wildcard is more flexible, but managed certificates support multiple specific domains (each as a separate certificate). However, managed certificates do not support wildcards, so if the scenario explicitly requires a wildcard (e.g., *.contoso.com), you must choose App Service Certificate or BYOC.
Thinking managed certificates can be exported and used with Azure Front Door. Managed certificates are non-exportable. The exam may present a scenario where you need a PFX for Front Door. Candidates who choose managed certificate are wrong; they should choose App Service Certificate (exportable) or BYOC.
Assuming automatic renewal is guaranteed. Candidates believe Azure handles everything. In reality, renewal requires domain validation. If DNS records change or domain binding is removed, renewal fails. The exam might ask: 'What happens if the DNS TXT record is deleted?' The answer: the certificate will not be renewed and will expire.
Specific Numbers, Values, and Terms
Validity: 1 year
Renewal attempt: 60 days before expiration
Limit: 10 managed certificates per App Service plan (soft limit)
Issuer: DigiCert
Binding type: SNI only
Supported: App Service (Web, API, Mobile, Function in App Service plan), ASE v3
Not supported: ASE v1/v2, Functions Consumption plan, wildcard domains, export
Edge Cases and Exceptions
App Service Environment (ASE): ASE v1 and v2 do not support managed certificates. ASE v3 does. The exam may ask about this.
Function Apps: Only supported when running in an App Service plan (Dedicated or Premium). Consumption plan does not support managed certificates.
Custom domains added via Azure DNS: If you use Azure DNS zones, Azure can automatically configure the TXT validation record. With external DNS, you must manually manage the record.
Multiple domains on same app: Each domain needs its own managed certificate (or you can use a wildcard from another option).
How to Eliminate Wrong Answers
If the question asks for a free certificate that auto-renews, choose managed certificate.
If the question mentions wildcard, export, or IP-based SSL, eliminate managed certificate.
If the scenario involves ASE v1/v2, managed certificate is not an option.
If the scenario involves Azure Front Door or Application Gateway needing a PFX, managed certificate cannot be used.
If the scenario mentions internal-only domain not bound to the app, managed certificate is not applicable.
App Service Managed Certificates are free and automatically renewed for custom domains bound to the app.
Managed certificates do NOT support wildcard domains, export, or IP-based SSL.
Renewal requires domain validation; if DNS records are removed, the certificate will expire.
Managed certificates are only available for App Service apps in App Service plans (not Functions Consumption plan).
ASE v1/v2 do not support managed certificates; ASE v3 does.
Maximum of 10 managed certificates per App Service plan (soft limit).
Use Azure CLI: `az webapp config ssl create` to create a managed certificate.
These come up on the exam all the time. Here's how to tell them apart.
App Service Managed Certificate
Free of charge
Automatic renewal (requires domain validation)
Non-exportable private key
SNI binding only
Limited to 10 per App Service plan (soft limit)
App Service Certificate (from Key Vault)
Paid (purchased through Azure)
Manual renewal or auto-renewal with Key Vault (additional cost)
Exportable (PFX with private key)
Supports both SNI and IP-based SSL
No per-plan limit (subject to Key Vault limits)
Mistake
Managed certificates support wildcard domains like *.contoso.com.
Correct
Managed certificates do not support wildcard domains. They only support specific fully qualified domain names (FQDNs). For wildcard, you must use an App Service Certificate (paid) or bring your own certificate.
Mistake
Managed certificates are automatically renewed without any prerequisites.
Correct
Automatic renewal requires that the domain validation records (DNS TXT record or app identity) remain in place. If the records are removed or the domain binding is deleted, renewal fails and the certificate will expire.
Mistake
Managed certificates can be exported and used with other Azure services like Azure Front Door.
Correct
Managed certificates are non-exportable. The private key is not accessible. To use a certificate with Azure Front Door or Application Gateway, you need an exportable PFX, which requires an App Service Certificate or a bring-your-own certificate.
Mistake
Managed certificates are available for all App Service plans including Functions Consumption plan.
Correct
Managed certificates are only supported for App Service apps running in App Service plans (Dedicated, Premium) and for Azure Functions in App Service plans. They are not supported for Azure Functions running in the Consumption plan.
Mistake
Managed certificates can be used for IP-based SSL bindings.
Correct
Managed certificates only support SNI-based SSL bindings. IP-based SSL is not supported. If you need IP-based SSL, you must use an App Service Certificate or a bring-your-own certificate.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, managed certificates do not support wildcard domains. They only support specific fully qualified domain names (e.g., app.contoso.com). If you need a wildcard certificate, you must purchase an App Service Certificate or bring your own certificate from a third-party CA.
You cannot manually renew a managed certificate. Azure automatically attempts renewal starting 60 days before expiration. If renewal fails, you can try to fix the domain validation (e.g., ensure DNS records are correct) and Azure will retry. If the certificate expires, you must delete it and create a new one.
No, managed certificates are non-exportable. The private key is not accessible. For Azure Front Door, you need to upload a PFX certificate. You can use an App Service Certificate (exportable) or bring your own certificate.
If you remove the custom domain from the App Service app, the managed certificate will still exist but will not be bound. However, automatic renewal will fail because the domain is no longer associated with the app. The certificate will eventually expire. You should delete the orphaned certificate to avoid confusion.
No, managed certificates are only supported for Azure Functions running in an App Service plan (Dedicated or Premium). Functions in the Consumption plan do not support custom domains with managed certificates. You would need to use a different certificate option or switch to an App Service plan.
The default limit is 10 managed certificates per App Service plan. This is a soft limit that can be increased by opening a support ticket. If you need more than 10, consider using multiple App Service plans or using a wildcard certificate from another option.
No, managed certificates only support SNI-based SSL bindings. IP-based SSL is not supported. If you need IP-based SSL, you must use an App Service Certificate (paid) or bring your own certificate.
You've just covered Managed Certificates in App Service — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?