Important Changes to Azure Container Apps Managed Certificates

[cachai2]

Overview

As part of an upcoming industry-wide change, DigiCert, the Certificate Authority (CA) for Azure Container Apps Managed Certificates, is required to migrate to a new validation platform to meet multi-perspective issuance corroboration (MPIC) requirements.

While most certificates will not be impacted by this change, private container app configurations and setups may prevent certificate issuance or renewal starting August 15, 2025.

How will I be affected by the changes?

• For most customers: No disruption. Certificate issuance and renewals will continue as expected for eligible container app configurations.

• For impacted scenarios: Certificate requests will fail (no certificate issued) starting August 15, 2025, if your container app configuration is not supported. Existing certificates will remain valid until their expiration (up to six months after last renewal).

Impacted Scenario

You will be affected by this change if you are using managed certificates and your container app is not publicly accessible.

• Public accessibility to your app is required. If your app is only accessible privately (e.g., requiring a client certificate for access, having an internal only environment, using private endpoints or IP restrictions), you will not be able to create or renew a managed certificate.

• Other container app configurations or setup methods not explicitly listed here that restrict public access, such as firewalls, authentication gateways, or any custom access policies, can also impact eligibility for managed certificate issuance or renewal.

• Action: Ensure your app is accessible from the public internet. However, if you need to limit access to your app, then you must bring your own certificate.

How to Identify Impacted Resources?

This ARG query retrieves a list of private container apps which may be impacted by this change (e.g. apps with ingress disabled, are internal only environments, are using private endpoints, or if IP restrictions are configured). It then filters for container apps which are using managed certificates. Please note, this query does not provide complete coverage of impacted scenarios as there may be additional configurations impacting public access to your app that are not included here, so a thorough review of your environment is recommended if using managed certificates. You can copy this query, paste it into Azure Resource Graph Explorer, and then click "Run query" to view the results for your environment.

Query

// Find Container Apps using custom domains and managed certificates 
resources 
| where tolower(type) has "microsoft.app/containerapps" 
| extend ingress = properties.configuration.ingress 
| where isnotempty(ingress) 
| extend customDomains = ingress.customDomains 
| where isnotempty(customDomains) 
| mv-expand customDomain = customDomains 
// Extract domain and certificate details 
| extend  
    domainName = tostring(customDomain.name), 
    certificateId = tostring(customDomain.certificateId), 
    managedEnvId = tostring(properties.managedEnvironmentId), 
    ipRestrictions = ingress.ipSecurityRestrictions, 
    ingressJson = tostring(ingress) 
// Extract Managed Environment identifiers (subscription, resource group, name) 
| extend  
    envSubId = tostring(split(managedEnvId, '/')[2]), 
    envResourceGroup = tostring(split(managedEnvId, '/')[4]), 
    envName = tostring(split(managedEnvId, '/')[8]) 
// Filter custom domains with custom certs (exclude default *.azurecontainerapps.io) 
| where tolower(domainName) !endswith ".azurecontainerapps.io" and isnotempty(certificateId) 
// Join with Managed Certificates to get validation method 
| join kind=inner ( 
    resources 
    | where tolower(type) has "microsoft.app/managedenvironments/managedcertificates" 
    | project  
        certificateId = id, 
        certName = name, 
        domainValidationMethod = properties.validationMethod, 
        certLocation = location 
) on certificateId 
// Join with Managed Environments to get public network access settings 
| join kind=leftouter ( 
    resources 
    | where tolower(type) has "microsoft.app/managedenvironments" 
    | extend  
        envSubId = subscriptionId,  
        envResourceGroup = resourceGroup,  
        envName = name 
    | project  
        envSubId, envResourceGroup, envName, 
        publicNetworkAccess = tostring(properties.publicNetworkAccess) 
) on  
     $left.envSubId ==  $right.envSubId and  
     $left.envResourceGroup == $right.envResourceGroup and  
     $left.envName == $right.envName 
// Evaluate Ingress flags 
| extend  
    hasIpRestrictions = isnotempty(ipRestrictions) and array_length(ipRestrictions) > 0, 
    isPrivateIngress = ingressJson contains '"external":false', 
    isEnvPublicBlocked = publicNetworkAccess == "Disabled" 
// Show only apps that have IP restrictions, private ingress, or blocked public access 
| where hasIpRestrictions == 1 or isPrivateIngress == 1 or isEnvPublicBlocked == 1 
// Final output: show Container Apps 
| project  
    containerAppId = id, 
    environmentId = strcat("/subscriptions/", envSubId, "/resourceGroups", envResourceGroup, "/providers/Microsoft.App/managedEnvironments/", envName), 
    containerAppName = name, containerResourceGroup=resourceGroup, envName, envResourceGroup, envSubId, domainName, certName, 
    certLocation, domainValidationMethod, publicNetworkAccess, hasIpRestrictions, isPrivateIngress, isEnvPublicBlocked 
| order by certName asc 

  

  

Questions

Please let us know on this thread if you have any additional questions or concerns. Thank you!

[DavidPriceNBS]

Unless I'm misunderstanding this feels like a pretty big breaking change, I'd have assumed most people - like myself - are locking their container apps behind something like an Azure Application Gateway and having private only from there?

So am I correct in understanding it will not longer be possible to have a setup like below where you achieve HTTPs between

Public Facing Application Gateway -> Private CAE LB

By creating a Private DNS Zone with the name e.g (debugname-183axdfa.uksouth.azurecontainerapps.io) and creating * and @ values pointing to the Private IP?

Edit - On reread it looks like this might just affect custom certificates for specific container apps instead of the CAE, but still not 100% sure on whether this will break internal CAE environments using the Azure managed certificate at the LB

[bhanuprakash-1]

Unless I'm misunderstanding this feels like a pretty big breaking change, I'd have assumed most people - like myself - are locking their container apps behind something like an Azure Application Gateway and having private only from there?

So am I correct in understanding it will not longer be possible to have a setup like below where you achieve HTTPs between

Public Facing Application Gateway -> Private CAE LB

By creating a Private DNS Zone with the name e.g (debugname-183axdfa.uksouth.azurecontainerapps.io) and creating * and @ values pointing to the Private IP?

Edit - On reread it looks like this might just affect custom certificates for specific container apps instead of the CAE, but still not 100% sure on whether this will break internal CAE environments using the Azure managed certificate at the LB

Hi @DavidPriceNBS, if you haven't configured custom domains + managed certificates for any of your container apps, you are not effected.

Only those container apps, which have all the below conditions, are effected and needs action:

1. Uses custom domains feature in container apps: https://learn.microsoft.com/en-us/azure/container-apps/custom-domains-managed-certificates?tabs=general&pivots=azure-portal
2. Uses managed certificates for that custom domain
3. The container Apps or the managed environments of these Apps are not publicly exposed.

[DavidPriceNBS]

Ah okay, I thought this was going to affect scenarios where the CAE isn't public and I'm using the Azure Managed Certificate by creating a Private DNS Zone for the CAE and creating @ and * records pointing to the CAE LB.

Funnily enough to avoid this, I've now created a custom Private Domain Zone and a Custom DNS Suffix for the CAE and reference my own wildcard self-signed certificate from Azure Key Vault - will this in fact be the scenario affected now?

I'm getting points 1 + 3 but don't fully understand "Uses managed certificates for that custom domain" - I thought you could either

1. Use the Azure CAE DNS name and the Azure Managed Certificate
2. Use a Custom DNS Zone and reference a Key Vault Certificate

Edit - I think maybe because I've only ever deployed internal only CAE I've never seen the option for a managed certificate and this could be the confusion I've had around this and that its been hidden as an option

[asnell-frtservices]

This is extremely disappointing. One of the reasons to use Azure in general and ACA specifically is that we don't want to manage certificate issuance and renewals, and we also want to ensure end-to-end encryption. We certainly don't want to expose any nonproduction environments, and some production environments, to the entirety of the internet.

[bhanuprakash-1]

Hi @DavidPriceNBS

By "Uses managed certificates for that custom domain" = selecting the option Managed Certificate when adding custom domain to your container App (shown at 3 in the below image). The Container App shown in the image below is using Container Apps managed certificates and it needs to be publicly accessible. Hope it makes it clear :)

You can also check if you are using Container Apps Managed Certificates by checking at Container Apps Environment --> certificates --> Managed Certificates (show in image below)

[bhanuprakash-1]

Hi @asnell-frtservices, totally valid concern. Unfortunately, in the Domain Control Validation (DCV) process during new cert creation/cert renewal, CA's are deprecating CNAME based validation because of compliance reasons(??) and for the HTTP based validation to work, http://{custom-domain-name}/.well-known/pki-validation/fileauth.txt needs to be publicly accessible by the CA.

Although ACA continues to manage certificate issuance and renewals, the public access is required starting August 15, 2025, for the renewals to happen successfully :!

[DavidPriceNBS]

Hi @DavidPriceNBS

By "Uses managed certificates for that custom domain" = selecting the option Managed Certificate when adding custom domain to your container App (shown at 3 in the below image). The Container App shown in the image below is using Container Apps managed certificates and it needs to be publicly accessible. Hope it makes it clear :)

You can also check if you are using Container Apps Managed Certificates by checking at Container Apps Environment --> certificates --> Managed Certificates (show in image below)

Yeah this makes sense now thanks, I was thinking about wildcard certificates used at the CAE level not CA specific domains, thanks for clearing it up!

[n0rbie]

Are you not able to provide the IP ranges required for certificate validation, rather than requiring us to lower security and allow full public access?!

[prodrammer]

Is there an alternative solution that would (optionally) expose the paths required for validation while keeping everything else private? Is there something I am missing as to why this would be a poor workaround? Couldn't Azure Apps infra answer requests from the CA with little to no impact on the customers?

[MarcelMichau]

Does this change impact Container Apps with custom domains + managed certificates + publicly exposed but have built-in authentication and authorization (EasyAuth) enabled?

Reading this line seems like it does:

Other container app configurations or setup methods not explicitly listed here that restrict public access, such as firewalls, authentication gateways, or any custom access policies, can also impact eligibility for managed certificate issuance or renewal.

[angrygreenfrogs]

Hi guys,

There's another important distinction here that I'm not clear on, with the definition of "publicly accessible".

Example - I have a container app setup like this:

Ingress: Enabled
Ingress traffic: Accepting traffic from anywhere
IP Restrictions: Allow traffic from IPs configured below, deny all other traffic
(and some IP restrictions setup)

This results in the app responding with a message like "RBAC: access denied", but that's still a valid HTTPS response.

This configuration does not actually block public traffic at a HTTPS network level.

The web server responds with a valid HTTPS response, while using the relevant certificate. You can make that query from anywhere, so the web server is "publicly available", even while the underlying app is not.

However, the docs and the impacted resources query from @cachai2 above seem to imply that even this type of IP restriction would be in scope?

But I don't think that matches with the requirement just being that the CA can query the certificate.. that would still work in this case..