Managed Certificate fails handshake

Question

Managed Certificate fails handshake

Bradley 0

I have an app service with multiple custom domains, each with its own SSL binding and cert. One of them has failed 2 different times over the last 2 days. When you access the domain you get an SSL "handshake" error. The solution has been to delete the binding and managed certificate and reestablish both. I am trying to figure out what is causing this. It appears the certificate is become corrupt.

Venkatesan S 10,260 Reputation points Microsoft External Staff Moderator

2026-08-07T23:26:27.3+00:00
Hi @Bradley ,

Thanks for reaching out in Microsoft Q&A forum,

Since the TLS handshake error is affecting only one custom domain, while the other domains on the same App Service continue to work, this does not necessarily mean that the certificate itself is corrupted. Because deleting and recreating the certificate and SSL binding restores connectivity, the issue may instead be related to the certificate binding, synchronization, or how the certificate is being presented for that specific hostname.

If the issue occurs again, please collect the following information before deleting or recreating anything:

Check the certificate under App Service >TLS/SSL settings and confirm that it is valid, has not expired, and includes the affected hostname. Please note the certificate thumbprint, issuer, subject, and expiration date.

Under Custom domains, confirm that the affected hostname is still validated and is associated with the expected certificate.

Confirm that the binding uses SNI SSL and check whether there are any conflicting or duplicate IP-based SSL bindings. Microsoft recommends reviewing these binding types carefully when multiple custom domains and certificates are configured on the same App Service.

Verify the DNS records for the affected hostname and confirm that they resolve to the correct App Service endpoint. Please also check for any conflicting A and CNAME records or intermediate services such as Front Door, a CDN, WAF, or Application Gateway.

Review Diagnose and solve problems and the Activity Log around the time of the failure for any certificate, hostname, binding, or platform-related events.

It would also be useful to check the certificate that is actually being presented by the endpoint. For example, you can run:

openssl s_client \ -connect affected.example.com:443 \ -servername affected.example.com \ -showcerts </dev/null

Please compare the result with a working domain on the same App Service and record the certificate subject, issuer, expiration dates, fingerprint, and certificate chain. This will help determine whether the endpoint is presenting the expected certificate, an older certificate, the default Azure certificate, or no certificate for the hostname.

If the certificate was recently renewed or reissued, please check whether a Synchronize or Rekey and Sync option is available before deleting it

Based on the current behavior, the issue appears more likely to be a hostname-specific certificate binding or synchronization problem than corruption of the certificate itself. Capturing the configuration and certificate details while the issue is active will help distinguish between a certificate problem, a DNS or routing issue, and an App Service platform-side binding problem.

For reference:

Secure a custom domain with an SSL certificate in Azure App Service

Add a custom domain to Azure App Service

Troubleshoot domain and TLS/SSL certificate issues

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
kagiyama yutaka 4,835 Reputation points

2026-08-08T03:28:58.8133333+00:00

Could you share the cert type, renewal timing, and the cert actually served on the endpoint (openssl output). With the current info I can’t tell if this is a binding drop or a sync issue.

2 answers

Your answer

kagiyama yutaka 4,835 Reputation points

2026-08-08T03:28:58.8133333+00:00

Could you share the cert type, renewal timing, and the cert actually served on the endpoint (openssl output). With the current info I can’t tell if this is a binding drop or a sync issue.

Answer 1

kagiyama yutaka 4,835

I think the managed certificate itself isn’t failing. A TLS handshake error in App Service appears only when the TLS/SSL binding isn’t active, and re‑attaching the cert makes the domain work again. I asked for the renewal timing and the cert actually served on the endpoint, because those are the facts needed to check why the binding stopped working.

0 comments

Answer 2

A repeated TLS handshake failure on one custom domain in Azure App Service usually points to a binding or certificate presentation problem, not a “corrupt” certificate file.

Most likely causes in this scenario:

The certificate is no longer effectively bound to that hostname If the custom domain has no valid certificate binding, App Service can serve the default certificate or fail HTTPS for that hostname.
The wrong certificate is being served With multiple custom domains and certificates on the same app, mixing SNI SSL and IP-based SSL can cause certificate mismatch or handshake problems. Azure recommends SNI SSL for most scenarios.
A binding conflict exists If the same certificate is used with IP-based SSL elsewhere, Azure can hit binding conflicts such as: Cannot set certificate for existing VIP because another VIP already uses that certificate.
The renewed certificate did not sync correctly If a certificate renewed but the app still serves the old one, the documented fix is to go to the App Service Certificate resource and select Synchronize. If needed, use Rekey and Sync.
Key Vault access or sync issues If renewal happened but the web app still serves the old certificate, verify Key Vault access policies and then sync the certificate.

What to check next:

In the Azure portal, open the web app and go to TLS/SSL settings.
Verify that the failing hostname still has a binding to the intended certificate.
Confirm the binding type is SNI SSL unless legacy client support requires IP-based SSL.
If the app mixes SNI and IP-based bindings for different certificates, simplify the configuration. This can cause the wrong certificate to be presented.
If the certificate was recently renewed, open the App Service Certificate resource and run Synchronize. If needed, try Rekey and Sync.
If the certificate is stored through Key Vault integration, verify Key Vault access policies and then sync again.
Test the hostname after rebinding. The expected result is that the site loads over HTTPS without certificate warnings.

CLI checks:

az webapp config hostname list --resource-group <RG> --name <AppName>
az webapp config ssl list --resource-group <RG> --name <AppName>

These confirm that the hostname is assigned to the app and that the expected certificate is available to the app.

If the issue keeps recurring after rebinding, that aligns with a binding-loss or sync problem rather than a one-time configuration mistake. In that case, the supported next step is to open an Azure support ticket for investigation, especially if the binding appears to disappear or stop working without intentional changes.