Azure App Service IP Based SSL and SNI Based SSL configuration

25-OCT-2017: If you delete an existing binding during the certificate renewal process, then you likley will get a new inbound IP address allocated.  This would cause a problem with an A record DNS configuration.  Therefore, to renew a certificate, upload the new certificate, noting the new thumbprint and bind that one to the App Service domain without deleting the old one, I.e. replace/update instead of delete/add.

Sometimes you experience something and just want to share.  This is very corner case, but it threw me for a loop.  In this case there was an Azure App Service Web App that had 1 web site running on it.  This one site had 2 custom domains bound to it.  One of domains used IP Based SSL and the other used SNI, the certificates were different, I.e. they had a different thumbprint.  See Figure 1 and Figure 2.


Figure 1, two (2) custom domains bound to the same Azure App Services Web App

Figure 1 show the 2 custom domain bound to the same Azure App Services Web App, which is absolutely ok.


Figure 2, two (2) custom domains bound to the same Azure App Services Web App with SSL

Figure 2 you see 2 SSL bindings for the custom domains, one is IP Based SSL and the other is SNI SSL.  This is perfectly ok as well.  Have no worries about doing that.

The interesting thing is that when I perform an NSLOOKUP on the custom domains, both point to the IP of the IP Based SSL configuration.  This is OK as well.

See Figure 3 and Figure 4.


Figure 3, the IP Based SSL configuration


Figure 4, the SNI based SSL configuration

Whenever I removed the IP Based SSL configuration, I saw this DNS configuration, see Figure 5.


Figure 5, IP Based SSL and SNI SSL configuration on same web site different certificates

As you know when you create an IP Based SSL certificate, you get your own dedicated inbound IP address, I discuss that here.

NOTE:   If you don’t see the DNS being updated, you might consider running ipconfig /flushdns which will purge the DNS resolver cache.

During the time while these DNS entries are propagating, the certificate being delivered to your clients might be the * one (I.e. the wrong SSL certificate is being delivered by my Azure App Service) or you may get an exception similar to those shown in Figure 6.


Figure 6, why is the wrong certificate being sent to my client from an Azure App Service

Messages like the following:

The wrong certificate is being delivered

“This page can’t be displayed. Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to HTTP again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator.”

There is a problem with the website’s security certificate

The security certificate presented by this web site was issues for a different website’s address.

Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.

The way I recommend you get around any disruption of service if you find yourself in this situation.  I.e. that you are getting some downtime when you remove the IP Based SSL binding, in this scenario is the following:

  • Modify the existing CNAME for the custom domain with the SNI configuration with a value of:  sni.<website> (Figure 7)
  • Once the CNAME has propagated, see Figure 8, remove the IP Based SSL configuration


Figure 7, a DNS CNAME configuration to the SNI Azure App Services Web App hostname


Figure 8, a propagated DNS CNAME configuration to the SNI Azure App Services Web App hostname