Container App custom domain on internal environment — TLS handshake returns no peer certificate

Hi @Simon Horn

Thank you for reaching out to Microsoft Q&A.

The behavior you are observing where a TLS handshake to the custom domain returns “no peer certificate available” while the default CAE FQDN works correctly is typically not related to the certificate itself but rather to how Azure Container Apps ingress (Envoy-based edge proxy) performs routing and TLS termination. In Container Apps, TLS is always terminated at the ingress level, and routing is entirely based on the hostname/SNI (Server Name Indication) provided in the TLS handshake. Since all applications within an internal Container Apps Environment share a single internal IP, the ingress relies on the hostname to determine which certificate to present. If the incoming request does not match a configured hostname binding (or the binding is not effectively applied at the ingress layer), Envoy does not select a certificate and closes the connection, resulting in the “no peer certificate” response. Even though the custom domain and certificate binding may show as “Succeeded” in the control plane, the data plane (ingress) may not recognize or serve it due to SNI mismatch, DNS issues, or propagation problems.

Refer below points to resolve this issue or this is the workaround

Verify SNI is correctly sent in TLS handshake

Ensure that your test includes the hostname using SNI; otherwise, ingress cannot match the request and will not present a certificate.

openssl s_client -connect <IP>:443 -servername <your-custom-domain>

If the certificate appears only when using -servername, then the issue is confirmed to be related to SNI/hostname mismatch.

Validate DNS resolution inside the V-Net

Confirm that your custom domain resolves correctly within the VNet and points to the same internal IP as the Container Apps Environment. Misconfigured private DNS zones or incorrect A/CNAME records can cause ingress to not match the hostname.

Compare default FQDN and custom domain behavior

Run TLS checks for both the default environment FQDN and your custom domain. If the default FQDN returns a valid certificate but the custom domain does not, it indicates that the ingress is not recognizing the custom domain binding even if it shows as successful.

Reapply or rebind the custom domain and certificate

Force a refresh of the binding to ensure propagation to the ingress layer:

az containerapp ingress custom-domain bind \
  --name <app-name> \
  --resource-group <resource-group> \
  --hostname <custom-domain> \
  --certificate <certificate-name>

Test with a managed certificate (isolation step)

Temporarily switch to an Azure-managed certificate. If this works, it helps isolate whether the issue is related to Key Vault certificate integration or binding propagation.

Check for propagation or platform-side issue (internal CAE)

If all configurations (SNI, DNS, binding) are correct and the issue persists, it is likely that the ingress (Envoy) has not picked up the configuration despite the control plane showing success. In such cases, this may require escalation to the backend team with resource IDs for further investigation.