Azure app service TLS 1.0 and 1.1 are not disabled even though TLS inbound minimum set to 1.2

Question

Azure app service TLS 1.0 and 1.1 are not disabled even though TLS inbound minimum set to 1.2

Jason Israel 20

azure2

User's image

Accepted answer

0 additional answers

Your answer

Answer 1

TP 119.4K Moderator

Hi Jason,

What makes you say that TLS 1.0/1.1 are not disabled even though you configured minimum 1.2? If you test the url of your app service using Qualsys SSL Server Test, you should see output similar to below (scroll down to Configuration section):

User's image

Note that the test will typically take several minutes to complete.

Please click Accept Answer and upvote if the above was helpful.

Thanks.

-TP

Jason Israel 20 Reputation points

2025-04-25T21:03:40.0866667+00:00

Here is our config and scans:
Jason Israel 20 Reputation points

2025-04-25T21:15:03.2733333+00:00

Please see updated screenshots.
TP 119.4K Reputation points Moderator

2025-04-25T21:23:05.0866667+00:00

As a test, please set it to TLS 1.0 or 1.1, click Save, then immediately switch it back to TLS 1.2 and Save again. I'm hoping to force it to write the TLS min setting again, so you could try TLS 1.3 as well, then switch back to 1.2.
Jason Israel 20 Reputation points

2025-04-25T21:36:06.2866667+00:00

No change after setting it to TLS 1.0 or 1.1, click Save, then immediately switch it back to TLS 1.2 and Save again. Also, restarted the app and then re-ran Qualsys with the same result:
TP 119.4K Reputation points Moderator

2025-04-25T21:55:35.08+00:00

I'm running out of ideas. You appear to have it configured properly, yet it still is allowing TLS 1.0.

One thing you could try is to delete the binding and then add it back. You do this on Custom domains blade, click on Actions menu (three dots) to the right of the domain, Delete binding, then click Add binding to put it back.

If that doesn't solve it then I think you should open support case so they can investigate on the backend. I use app service all the time and don't have issues with requiring TLS 1.2. I also have clients with lower versions as well.

Do you have Developer or Standard level support plan?
Jason Israel 20 Reputation points

2025-04-25T22:00:18.3966667+00:00

Thanks for trying. I already created support tickets 2504250040012720 and 2504250040012841.
TP 119.4K Reputation points Moderator

2025-04-25T22:11:08.2833333+00:00

If you create new web app in same app service plan, does it also allow TLS 1.0/1.1?

You shouldn't need to do this, but I was thinking you could create new web app, deploy all files/config settings to it, verify TLS is correct, then as final step switch over custom domain and binding.

Depending on complexity of your site/app, it may not be a big deal to do what I describe above.
Jason Israel 20 Reputation points

2025-04-25T22:17:00.32+00:00

Already headed down that path, as a last resort. This is a prod service supporting 200K users, SLA 99.99. Trying not to change DNS - downtime is not an option.
TP 119.4K Reputation points Moderator

2025-04-25T22:22:26.9366667+00:00

Already headed down that path, as a last resort. This is a prod service supporting 200K users, SLA 99.99. Trying not to change DNS - downtime is not an option.

New web app in same app service plan should get same inbound IP, so might not need to make DNS change. Give it quick try by creating new web app just to see if same inbound IP shows, then move on to TLS check of the xxx.azurewebsites.net for the new app, etc.I understand in regards to this being prod site. Ideally support would just come back to you and say they fixed something and that be the end of it.
Jason Israel 20 Reputation points

2025-04-25T23:46:07.0933333+00:00

It looks like the issue is related to the cert or SANs on the cert for dailymemphian.com. thememphianprod.azurewebsites.net is the same app service and does not allow TLS 1.0 or 1.1 based on Qualsys scan.

I tried re-binding the cert, no luck.
TP 119.4K Reputation points Moderator

2025-04-26T00:11:35.3633333+00:00

It looks like the issue is related to the cert or SANs on the cert for dailymemphian.com. thememphianprod.azurewebsites.net is the same app service and does not allow TLS 1.0 or 1.1 based on Qualsys scan.

Do you need the certificate to be a SAN cert? Looks like you have about 11 names or so. Was thinking could do quick test with free 90-day wildcard cert just to see if that resolves it.

I've downloaded both the stock azure cert and your cert and have them side-by-side for comparison. I just started looking and there are some differences (besides obvious things like different CA, names), but right now I don't know what would cause the app service front end not to require TLS 1.2.
Jason Israel 20 Reputation points

2025-04-26T12:24:53.3166667+00:00

Yes, the SAN cert is needed for all those domains.

In fact, we have a separate App service for our dev environment which uses the same cert. That App Service min TLS setting is 1.2 and the Qualsys scan of that app service does not report the TLS 1.0 and 1.1 vulnerability:
https://www.ssllabs.com/ssltest/analyze.html?d=dev.dailymemphian.com
TP 119.4K Reputation points Moderator

2025-04-27T09:07:13.1166667+00:00

I've been performing a more tests.

Please confirm if the Virtual IP address shown in Properties in portal for your web app match your DNS A records for dailymemphian.com / www.dailymemphian.com.

Thanks.
Jason Israel 20 Reputation points

2025-04-27T13:11:16.4633333+00:00

Our DNS @ and www have been set to 23.99.191.26 for 7 years. 23.99.191.26 is no longer even associated with my App Service!

How does this change?!?!?!?
TP 119.4K Reputation points Moderator

2025-04-27T15:27:33.62+00:00

Our DNS @ and www have been set to 23.99.191.26 for 7 years. 23.99.191.26 is no longer even associated with my App Service! How does this change?!?!?!?

Awesome (awesome in terms of I think I found the issue, not that they changed the IP address)! Based on the tests I've been running, I believe that is your issue.

As a test, I suggest you shorten TTL to minimum (it is set to 10 minutes/600sec now) for A records for dailymemphian.com and www.dailymemphian.com, wait 10 minutes, then update them to point to 23.99.183.149. I forget how low GoDaddy will let you set TTL, perhaps 30 seconds.

If you notice any issues you can switch them back to previous old IP and the low TTL will minimize effect.

I've tested with 23.99.183.149 (overridden using hosts file) and your site appears to work fine. Also tested with nmap and I believe once you make the change it will only allow TLS 1.2 and higher.

Generally the inbound IP doesn't change, however, it could if they do upgrades/changes to the platform. They should've notified you of the change. Please see article below:

How to prepare for an inbound IP address change

https://learn.microsoft.com/en-us/azure/app-service/ip-address-change-inbound
Jason Israel 20 Reputation points

2025-04-28T11:10:28.8066667+00:00

Good deal...

We'll have to do some planning for an IP address change. Right now, I'm not sure if there are any external services that are IP dependent.

I need a root cause as to why the IP changed to report back to my org. Do you have any idea what that may be?

Also, what is causing the vulnerabilities to be reported? My understanding is that the machine that is hosting our IP currently configured in DNS, pointing to our domain has TLS 1.0 and 1.1 still enabled and that machine is just a traffic cop. Do you think the same?
TP 119.4K Reputation points Moderator

2025-04-28T13:15:26.4533333+00:00

I need a root cause as to why the IP changed to report back to my org. Do you have any idea what that may be?

Perhaps you had IP SSL binding at some point in the past, switched to SNI binding, but that older IP binding config remained valid in app service frontend layer for some reason? You could ask Microsoft engineer to investigate using one of your open cases.

When I was troubleshooting it appeared as though only your apex and www were using that IP address, whereas the "correct" IP address is being used by multiple domains/customers.

This gives some weight to the idea the IP is/was used for IP SSL binding.

Also, what is causing the vulnerabilities to be reported? My understanding is that the machine that is hosting our IP currently configured in DNS, pointing to our domain has TLS 1.0 and 1.1 still enabled and that machine is just a traffic cop. Do you think the same?

Unsure, since in theory the incoming IP you are using (assuming you don't have another web app using it via IP binding) should, in theory, be returning 404 or otherwise not working.

In general terms, the app service frontend still supports TLS 1.0/1.1 for those customers that permit it for their older devices (e.g. IoT). When request comes in to shared incoming IP, you can think of frontend as looking at destination IP + SNI and then deciding based on min inbound TLS and min inbound cipher setting how to behave.

One concern I have is, this incoming IP you are using might stop working one day since according to your web app properties it isn't correct.
Jason Israel 20 Reputation points

2025-04-28T17:12:35.2166667+00:00

Thanks.
We updated the IP earlier this AM. So far, so good. The Qualys scan came back clean after the IP prop. Appreciate your help.

Share via

Azure app service TLS 1.0 and 1.1 are not disabled even though TLS inbound minimum set to 1.2

0 additional answers

Your answer