• Hello,

    after publishing my web role into a OS-family=5 (e.g. Win2016SRV), FireFox + Chrome stopped to work with https, giving me:

    I've found some articles that this is caused by the default IIS settings, as the Win2016SRV unfortunately not supports HTTP2.0 and the default IIS settings are considered as "not safe" by the newest browsers.

    There are "solutions" like installing IIS "best practice tool" and then applying some "better" settings - and then, of course, rebooting the box.. This is completely unusable of course when deploying from VS deployment-project into the Azure web farm.

    Anyone knows some insights how to workaround this? I see these possibilities, known of which is good:
    1. Patching the server registry with "better" defaults and then rebooting
    2. Disabling HTTP2 @client: not useful as all the clients must do this
    3. Disabling HTTP2 @server: not ideal as of the hacky painful publishing hell

    Thank you,

    Tuesday, November 22, 2016 4:20 PM

All replies

  • Hi,

    Thank you for posting here!

    I would suggest you to enable diagnostic logging for cloud service, in case if you haven’t enabled it before to check the complete error messages or logs to find out the root cause of the issue.

    You may also check the article to view diagnostic logs. You may want to see SO thread Git issues which addressed similar issue.

    Let us know if that helps.





    When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer so that other customers can benefit from it.

    Wednesday, November 23, 2016 7:04 AM
  • Thank you, although this is not helpful:

    1. Diagnostics Log
    - This error is NOT a server error, e.g. no 'exception to be logged'
    - This is a default Azure VM IIS misconfiguration, which leads to modern browsers/libs rejecting it

    2. The forums
    - These forums discuss what should be configured on the IIS site - which of course should do MS and not the user deploying a web role into the MS-misconfigured default VM IIS

    => Please, would you forward this to the MS VM sysprep guys, so the IIS is configured the right way?

    Thank you,

    Wednesday, November 23, 2016 10:04 AM
  • I have the same problem and this really seems like a misconfiguration of the image.

    TLS is not working correctly out of the box with modern browsers, because blacklisted cipher suites are used. It is true, that it can easily be fixed by setting some registry keys and rebooting, but you cannot consider that as solution.

    A list of blacklisted cipher suites is in RFC7540 Appendix A. According to an SSL Labs test, the used cipher suite is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA. This cipher suite is on the blacklist.



    Thursday, November 24, 2016 3:59 PM
  • I'm wondering where should be push Azure problems like this - it can't be that to get "support" in means of "please help me, I have no idea" we have to pay for Azure "support credit", but here we find bugs and show-stoppers thanks to which MS could make the own Azure platform products usable. I don't mean "more usable", but usable at all, as this is not usable like this, forcing the users to registry-patch the misconfigured out-of-box VM IIS by some black magic hack scripts from inside the publishing process.

    In the coming months there are coming more OS=5 deployments and more users wondering why their Chrome/FF won't work anymore with our Azure sites; and there will be more mobile libs out there adopting HTTP2 which won't work anymore with our Azure hosted cloud mobile services. I'm pretty worried our ProtoBuf/HTTPS based iface stops working pretty soon, as the browsers stopped already now. Not to switching to OS=5 sucks as well, as it's needed for the .NET462 support, for all those nice things like Razor C#6 etc. I was delaying our transition to Win2016Server as long as I could as I suspected new problems coming with new OS; and this one is a pretty obvious and unnecessary show-stopper.

    Please fix this soon, thank you,

    Sunday, November 27, 2016 10:23 AM
  • in poking around looking for this i randomly ran into this reference:

    from the


    This is a sample and template Azure Web Role project containing start up scripts to disable ssl 2.0, ssl3.0 and RC4 cipher suites, configure recommended cipher suite order for your windows azure service or any windows server to be securely service on TLS/SSL channels. This is highly important to protect the data-in-transit for users of Windows/Windows Azure, as nowadays the internet is pretty heavily militarized.

    Licensed under MIT License

    does this work for you?

    Wednesday, December 7, 2016 6:01 PM
  • Ashok Kumar,

    Is this issue going to be fixed by Azure?

    Thursday, December 22, 2016 10:21 PM
  • Hi Noel Abrahams,

    Just to confirm have you tried the above suggestions given by John Gardner.

    We would like to inform you that we are checking on this with the respective teams.

    I see that the issue needs a further deeper dive technically. I recommend you to create a technical support ticket. Refer the link to create a support ticket:

    The ticket enables you to work closely with the support engineers and get a quick resolution for your issue.

    Apologies for the inconvenience caused and appreciate your patience in this matter.




    Friday, December 23, 2016 8:54 AM
  • Ashok,

    I have not tried the suggestions by John Gardner, because the script involves rebooting the instance which will add time to the instance startup time.

    Furthermore, I'm sure you agree, that rather than every single one of your customers having to patch up their startup scripts, it would make slightly more sense for Microsoft to fix this problem at source once and for all.

    The azure technical support link that you posted above requires a paid support plan. I am not sure I follow the logic where I should pay to report an obvious bug to Azure.

    Please have this resolved as soon as possible and post the resolution to this thread.


    Wednesday, December 28, 2016 4:39 PM