« Previous Next »

Thread: Removing HTTPS binding on one site breaks all sites

Last post 07-27-2009 1:59 PM by dtatgenho. 4 replies.

Average Rating Rate It (5)

RSS

Page 1 of 1 (5 items)

Sort Posts:

  • 07-23-2009, 7:10 PM

    Removing HTTPS binding on one site breaks all sites

    Hi,

    I was reading this post earlier, as we are running into this issue too (SSL using a wildcart cert on multiple subdomain websites).

    In anilr's reply (2nd post of the thread), he says: "removing the bindings in the UI will remove both those things which will of course make your other sites non-functional - you need to remove just the binding in applicationhost.config using other means like appcmd/editing in notepad etc."

    So, in other words, removing the SSL cert binding of one site (via the UI) will break the SSL bindings of ALL of the other sites.  This seems like a huge problem/limitation of the UI, especially since this can be done properly (as anilr also states) by editing the applicationhost.config file (either manually or programmatically).

    This, frankly, seems like a bug, as this behavior is not expected nor implied by the user's action (by editing a single site, you break all of them).  Is this fixed in Server 2008 R2 or by a future service pack/hotfix?

    The reason I ask is because we are testing out a hosted environment like this (wildcard SSL cert (*.mysite.com), single IP, bound to many subdomain sites via host headers (site1.mysite.com, site2.mysite.com, etc.)) and having the "touch one binding, break them all" issue with the UI just makes things way too easy to screw up.

    Anyone know if this will be fixed or if there is something I am missing?

  • 07-23-2009, 8:11 PM In reply to

    • anilr
    • Top 10 Contributor
    • Joined on 05-23-2006, 6:13 PM
    • Redmond, WA
    • Posts 2,343

    Re: Removing HTTPS binding on one site breaks all sites

    The IIS UI does not allow you to setup the configuration where multiple sites share the same SSL endpoint and use host-headers to route to the correct site - so, expecting the UI to be able to handle deletion of the binding which it could not create in the first place seems ambitious.

    Anil Ruia
    Senior Software Design Engineer
    IIS Core Server
  • 07-23-2009, 8:36 PM In reply to

    Re: Removing HTTPS binding on one site breaks all sites

    Hi anilr, thanks for the quick response.

    I did noticed that in the Site Bindings box, when you add a new binding and select HTTPS, it greys out the host header field.  Yet, via appcmd or by editing the config files manually, you can indeed set a host header value for the HTTPS binding, and/or remove "HTTPS with host header bindings" from that single site without breaking the others.

    I guess I'm just wondering why the UI behaves this way when these are not only valid configurations (SSL with host header) that IIS allows, but are able to be set (and/or removed) in every other way (manually, command line, code) *except* for the UI.

    It just seems inconsistent - why wouldn't the UI act the same way the manual/appcmd/code methods do?

    If I am not understanding something, please let me know.

  • 07-24-2009, 12:16 PM In reply to

    Re: Removing HTTPS binding on one site breaks all sites

    The biggest difference that you might be missing is that the UI will do what no other tool (appcmd, manual, etc) will do which is register the SSL binding with HTTP.sys,

    If you use AppCmd to set up that configuration it will not set anything to the HTTP.sys registration and you will need to manually add/delete it using a different command line tool such as "netsh http add sslcert".

    This task is a lot more advanced than the 80% case (remember the old saying "only expose in the 80% in the UI for everyone and leave the 20% case for advanced tools like command line".

    We thought at the time these types of certificates and configuration are not what 80% of customers would do and so in an effort to simplify the UI the scenario was left out in purpose.

    Otherwise you can imagine we would have had to expose more UI to ask you and warn you when bindings were still left and ask you if you wanted us to delete it if it was the last one, etc.

     

     

  • 07-27-2009, 1:59 PM In reply to

    Re: Removing HTTPS binding on one site breaks all sites

    I understand the "command line can be more powerful than the UI" practice, but the UI is not simply leaving out an "advanced" feature, it is actually misleading the admin in a big way.

    When I go into IIS and edit properties at the server level, I expect it to affect the server (all sites).  When I edit the properties of a single website, I expect it to affect only that website.  In the scenario in this thread, editing a property of a single site climbs all the way back up to the global level.  This is wrong, and misleading.  No reasonable admin would expect or anticipate this.

    Everywhere in the IIS 7 UI, there are links in the action pane to "Revert to Parent" (discard the locally configured property, and inherit from above), reinforcing the hierarchical nature of the IIS config structure.  And this has been this way in past versions as well, and makes sense.  There are configs at the server level all the way down to the site level and even to the file level.

    Why would any admin think that changing a single site property would ripple out to every other site on the server?

    Also, the UI (as I mentioned earlier) goes out of its way to explicitly grey out the host header field when adding an HTTPS binding.  Why would it do that, if host headers are perfectly acceptable, allowed, and even configurable in all other ways?  It’s strange that you would actually grey out a config field that is allowed and supported.

    As for the UI design issues of things like "ask[ing] you if you wanted us to delete it if it was the last one, etc.", isn't that what it should do?  This is done elsewhere in other service UIs and wizards (Active Directory wizards, DFS MMCs, etc.).  In DFS, for example, removing the last folder target also prompts to say there are no link targets, and asks if you would like to remove the replication configuration info for the DFS folder.  It asks because it NEEDS to ask, because you can have DFS replication without the DFS targets explicitly defined as a DFS share.  So, rather than make a significant change like removing file replication, it does what it should - it ASKS if this is what you want, it doesn't assume and cut the admin out of the decision entirely.

    Shouldn't this be exactly what happens in IIS?  Dependency checking is common, smart, helpful, and a sign of well-written and well-thought-out code.  A single prompt or two is a more than acceptable alternative than simply making assumptions and breaking an entire server configuration.  The UI is not making things simpler; it just willfully ignores the required complexity.

Page 1 of 1 (5 items)
Microsoft Communities