Error_SSL_Protocol_error

Hi @Frank Quintana ,

The ERR_SSL_PROTOCOL_ERROR indicates that the HTTPS/TLS connection to the application is not being established successfully. Since you are using an Azure App Service on the Free (F1) tier, the first thing we recommend checking is whether you are accessing the application through the default Azure App Service URL or through a custom domain.

If you are using the default App Service URL, such as:

https://<app-name>.azurewebsites.net

Azure automatically secures the azurewebsites.net domain with a default certificate, so no additional SSL certificate configuration is required.

However, if you are using a custom domain, such as https://api.example.com, custom TLS/SSL bindings are not supported on the Free (F1) tier. In this scenario, the App Service needs to be scaled up to a supported tier, such as Basic (B1) or higher, before configuring a TLS/SSL certificate for the custom domain.

We recommend the following:

1. Try accessing the application using the default https://<app-name>.azurewebsites.net URL.
2. If the default URL works but the custom domain returns ERR_SSL_PROTOCOL_ERROR, check the custom-domain DNS configuration and TLS/SSL certificate binding.
3. If HTTPS is required on the custom domain, consider scaling the App Service plan to Basic (B1) or higher and configure an App Service Managed Certificate or another supported certificate.
4. For a mobile application, we recommend using a properly configured HTTPS endpoint rather than bypassing SSL certificate validation on the client.

You can find the official Microsoft documentation here:

• Troubleshoot Azure App Service certificates - Azure | Microsoft Learn
• Install a TLS/SSL Certificate for Your App - Azure App Service | Microsoft Learn

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.

Thanks for the response. To clarify — I'm accessing the app through the default Azure URL only: https://nexusplan-api-fq-heb0aafbfze3cxcq.israelcentral-01.azurewebsites.net. No custom domain is configured, so custom TLS binding shouldn't apply here.

The issue persists even on this default URL, and notably the independent Kudu/SCM management endpoint (https://nexusplan-api-fq-heb0aafbfze3cxcq.scm.israelcentral-01.azurewebsites.net) fails with the identical ERR_SSL_PROTOCOL_ERROR, tested from both a Windows PC and an Android device on separate networks.

Relevant context: this began immediately after my Azure subscription was disabled for non-payment and I reactivated it. Since reactivating:

• App Service status shows Running
• Resource Health shows Available, no issues reported
• The App Service plan (F1) shows Instance Count: 0
• A full Stop → wait → Start cycle did not resolve it

Given the default hostname's managed certificate is failing identically on two separate endpoints under this one App Service, this looks like it may be tied to the subscription disable/re-enable cycle rather than a domain or TLS-binding configuration issue on my end. Could you check the backend TLS termination / instance provisioning state for this specific resource (nexusplan-api-fq in resource group NexusPlanRG)?

Thanks for the response. To clarify — I'm accessing the app through the default Azure URL only: https://nexusplan-api-fq-heb0aafbfze3cxcq.israelcentral-01.azurewebsites.net. No custom domain is configured, so custom TLS binding shouldn't apply here.

The issue persists even on this default URL, and notably the independent Kudu/SCM management endpoint (https://nexusplan-api-fq-heb0aafbfze3cxcq.scm.israelcentral-01.azurewebsites.net) fails with the identical ERR_SSL_PROTOCOL_ERROR, tested from both a Windows PC and an Android device on separate networks.

Relevant context: this began immediately after my Azure subscription was disabled for non-payment and I reactivated it. Since reactivating:

• App Service status shows Running
• Resource Health shows Available, no issues reported
• The App Service plan (F1) shows Instance Count: 0
• A full Stop → wait → Start cycle did not resolve it

Given the default hostname's managed certificate is failing identically on two separate endpoints under this one App Service, this looks like it may be tied to the subscription disable/re-enable cycle rather than a domain or TLS-binding configuration issue on my end. Could you check the backend TLS termination / instance provisioning state for this specific resource (nexusplan-api-fq in resource group NexusPlanRG)?

Hi @Frank Quintana ,

Thank you for the clarification and for providing the additional details.

Based on your latest information, I agree that the previous troubleshooting around custom domains and custom SSL bindings does not apply in this scenario. Since you are accessing the App Service through the default azurewebsites.net hostname and the issue is also reproducible through the independent SCM/Kudu endpoint, this points away from a custom-domain or individual certificate binding configuration.

The fact that the issue started immediately after the subscription was disabled and subsequently reactivated is also an important observation. Additionally, although the App Service is showing as Running and Resource Health reports Available, the App Service Plan currently showing Instance Count: 0 is worth investigating, as the application requires an active worker instance for the frontend and SCM endpoints to operate correctly.

At this stage, I recommend the following checks:

• Verify whether the App Service Plan continues to show 0 instances after the Stop > Start operation.
• Check Diagnose and solve problems for any availability, platform, or instance-provisioning related findings.
• Review the App Service Activity Log around the time the subscription was disabled and reactivated for any failed or incomplete operations related to the App Service Plan or App Service.
• Confirm that there are no subscription-level restrictions, quota issues, or deployment/provisioning errors following the subscription reactivation.
• If possible, check whether creating/restarting another test App Service under the same subscription exhibits the same behavior. This can help determine whether the issue is isolated to this resource or related to the subscription state.

Because both the application endpoint and SCM endpoint are exhibiting the same ERR_SSL_PROTOCOL_ERROR from multiple networks/devices, I would not recommend continuing to delete and recreate certificates at this point. The default App Service hostname uses Microsoft-managed TLS, so repeatedly recreating a custom certificate would not address the underlying issue.

If the App Service Plan continues to report 0 instances while the App Service remains in the Running state, please capture screenshots of the App Service Plan overview, App Service overview, Resource Health, and the relevant Activity Log entries. These details will help determine whether the issue is related to worker-instance provisioning following the subscription reactivation.

For reference, the official Microsoft documentation is available here:

• Troubleshoot with Diagnostics - Azure App Service | Microsoft Learn

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.