Skip to content

Managed Certificates

Managed certificates reduce certificate-handling work when the target hostname fits the current Azure Container Apps managed-certificate support rules.

Prerequisites

  • External ingress enabled
  • DNS access for validation records
  • A hostname that matches the currently documented managed-certificate rules
export RG="rg-aca-prod"
export APP_NAME="app-python-api-prod"
export HOSTNAME="api.contoso.com"

When to Use

  • When you want Azure to handle certificate issuance and renewal operations
  • When the domain type is supported by the current managed-certificate feature set
  • When you want a simpler public TLS runbook

Procedure

Add the hostname:

az containerapp hostname add \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --hostname "$HOSTNAME"

Bind the managed certificate:

az containerapp hostname bind \
  --name "$APP_NAME" \
  --resource-group "$RG" \
  --hostname "$HOSTNAME" \
  --validation-method CNAME

Validate the result:

curl --head "https://$HOSTNAME"
openssl s_client -connect "$HOSTNAME:443" -servername "$HOSTNAME"

Microsoft Learn documents that Container Apps managed certificates are issued through DigiCert, support both apex domains and subdomains, and are "automatically renewed without any action from you as long as your app continues to meet the requirements for managed certificates."

flowchart TD
    A[Add hostname] --> B[Create validation DNS record]
    B --> C[Azure validates ownership]
    C --> D[Managed certificate bound]
    D --> E[Serve HTTPS traffic]

Verification

  • Confirm the hostname is listed on the app.
  • Confirm HTTPS succeeds with the expected host header.
  • Confirm the served certificate subject matches the hostname.

Rollback / Troubleshooting

  • If issuance stalls, re-check the validation record and DNS propagation.
  • If the hostname type is unsupported, switch to the BYO certificate path.
  • If TLS still fails after binding, remove and re-add the hostname after correcting DNS.

See Also

Sources