Receiving ERR_CERT_COMMON_NAME_INVALID in small number of requests to websites hosted at Azure

Joseph 1

We host multiple websites at Azure. Infrequently (a few times a day) we get reports of customers seeing a certificate error on our sites. This is happening on all our sites. This started happening a couple months ago. The error is:

NET::ERR_CERT_COMMON_NAME_INVALID

This server couldn't prove that it's www.XYZXYZ.com; its security certificate is from *.azurewebsites.net. This may be caused by a misconfiguration or an attacker intercepting your connection.

If you refresh the page it will go away and the certificate will properly load. This only happens in a VERY small number of requests (my estimation would be about .1% of requests).

I have both IP based certificate binding and SNI based bindings. Changing it does not seem to fix the issue. Are there ways to track down what the original cause of this issue would be? It seems that traffic is not being forwarded properly to the right endpoint to get the correct certificate?

Thanks for the help!

Ryan Hill 25,981 Reputation points Microsoft Employee

2021-10-15T14:55:51.727+00:00

Does this occur on a specific route or all over? The customers receiving the error, are they accessing you site at HTTP or HTTPS? Is your app behind Traffic Manager or Front Door?
Joseph 1 Reputation point

2021-10-15T21:32:46.987+00:00

This happens all over - from all locations across the US. They could be accessing either way, we enforce SSL in the Configuration of the AppService. So all HTTP traffic should be rerouted to HTTPS. Our websites are not behind a Traffic Manager and not behind a Front Door configuration. Just a standard App Service with a custom domain and SSL certificate. (Separate App Services for different websites)

Thanks for the assistance!
Joseph 1 Reputation point

2021-10-28T21:15:44.26+00:00

Hello Ryan,

Any other ideas here? We have been getting this error a bunch today -- moreso than usual.

Thanks,
~Joe
Ryan Hill 25,981 Reputation points Microsoft Employee

2021-11-02T12:26:23.297+00:00

Apologies for the late reply @Joseph . This could happen if mix IP based and SSL bindings. Is the SSL cert 3rd party or a managed? You also mentioned you have several sites, are you using the same cert with multiple app services?
Joseph 1 Reputation point

2021-11-02T21:54:33.737+00:00

Thank you Ryan...
I mis-typed in my original post I suppose - I have tried BOTH IP and SNI SSL bindings. Originally, it was just SNI bindings for our site (www.aestax.com). Then I moved it to IP based bindings to see if that would work. However, we still see the error occasionally. I also then removed my original bindings and tried the managed certificate option and we are still seeing this occasionally.

I have multiple websites, each with their own app service (although both under the same app service plan). They have their own security certificates (not shared between the sites). The security certificates were originally purchased through Azure. But I have moved to the managed certificates (as of this morning) and we are still getting the error.
Ryan Hill 25,981 Reputation points Microsoft Employee

2021-11-03T04:06:49.867+00:00

I'm wondering if since the number of requests are so low, if those clients are non-SNI enabled. SNI bindings, including defaults, will fail the URLS and return the IP SSL cert. Nonethess, we should have a closer look. Please respond to the private message below.
Joseph 1 Reputation point

2021-11-16T16:05:14.777+00:00

Hello @Ryan Hill ,

Just to close out this thread, I wanted to inform you (and the community) that this has been resolved. We ended up purchasing a support agreement from Azure and opened a ticket through our support agreement. We had extremely good customer service once this ticket was opened and the RCA resolution was as follows:

"Upon investigation, we found that there was a race condition in the way we were loading certificates on our reverse proxy Frontends. The gist of the issue was that we were occasionally using private certificates with invalid or disposed keys. We believe we have identified the correct fix now and it has already been rolled out to most instances that were affected. We have also added more telemetry in order to proactively catch and diagnose similar bugs in the future, in case they do arise again."

So, as I suspected, this was not a configuration error on our part, but an issue with the frontend that was directing traffic before it even got to our WebApp. As of this fix last week, we have not seen a single instance of this error.

Thank you.