IIS 7.5 Binding Bug

[silverBull3t]

Hi,
there is a BUG when fetching a website on IIS 7.5 "/api/webserver/websites/bc-sYFqIYoYTtsibA4Tn9A"
my sites have a specific HTTPS binding.
every site that I try to "GET" that has that Binding, I get a 500 error.

----------------this is the log-------------------------
2017-10-16 19:16:24.077 +03:00 [Error] An unhandled exception has occurred: Either the application has not called WSAStartup, or WSAStartup failed. (Exception from HRESULT: 0x8007276D)
System.Runtime.InteropServices.COMException (0x8007276D): Either the application has not called WSAStartup, or WSAStartup failed. (Exception from HRESULT: 0x8007276D)
at Microsoft.Web.Administration.Interop.IAppHostProperty.get_Value()
at Microsoft.Web.Administration.ConfigurationElement.GetPropertyValue(IAppHostProperty property)
at Microsoft.Web.Administration.ConfigurationElement.GetAttributeValue(String attributeName)
at Microsoft.Web.Administration.Binding.get_CertificateStoreName()
at Microsoft.IIS.Administration.WebServer.Sites.SiteHelper.ToJsonModel(Binding binding)
at Microsoft.IIS.Administration.WebServer.Sites.SiteHelper.ToJsonModel(Site site, Fields fields, Boolean full)
at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.d__28.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Builder.RouterMiddleware.d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.IIS.Administration.WebServer.Injector.d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.IIS.Administration.WebServer.Injector.d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.IIS.Administration.HeadTransform.d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.IIS.Administration.Startup.<>c.<b__4_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.IIS.Administration.Security.Authorization.AuthorizationPolicyMiddleware.d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware1.<Invoke>d__18.MoveNext() --- End of stack trace from previous location where exception was thrown --- at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware1.d__18.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.IIS.Administration.Cors.CorsExtensions.<>c.<b__0_3>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Cors.Infrastructure.CorsMiddleware.d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.IIS.Administration.Cors.CorsExtensions.<>c__DisplayClass0_0.<b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.IIS.Administration.ErrorHandler.d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.IIS.Administration.ErrorHandler.d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.d__6.MoveNext()

[jimmyca15]

Okay, have you tried creating https bindings with another certificate to see if the issue was limited to that certificate? I see that the binding is using a wildcard subject, is there anything else notable about it?

[silverBull3t]

Actsualy no.
Main thing is that it's a wildcard cert.
If i delete the binding from a site. It works. When adding again it breaks

[silverBull3t]

Do you have any suggestion for a temp workaround ?
Maybe a change in a ps1 file ?

[jimmyca15]

The PowerShell scripts only effect installation so any modifications will not effect runtime behavior. Can you tell me what certificate stores the wildcard certificate is installed in on the machine?

[silverBull3t]

I hope i'm answering correctly, all of them a total of 3 certs are in a store called "My"

[jimmyca15]

That sounds right, and it is the correct store. The terms "My" and "Personal" are interchangeable.

[jimmyca15]

I got onto a server 2008 R2 machine to look into this. I created a self signed certificate using
New-SelfSignedCertificate -Subject "*.abc.com"
and then ensured the certificate was in the personal store (My) with the Server Authentication key usage.

After patching a web site to use this certificate for an HTTPS binding I received a 500 error. the binding was created but the certificate was not used in the binding. I was able to patch the web site to use a certificate that did not use a wildcard subject. Also I was able to update the website using Inetmgr.exe to use the wildcard certificate.

I did not have an exact reproduction of the issue because I had no trouble retrieving the site through the API. The only problem was with creating the binding to use the wildcard certificate. So there is an issue.

My log on the PATCH request

2017-10-16 11:17:24.469 -07:00 [Error] An unhandled exception has occurred: A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520)
System.Runtime.InteropServices.COMException (0x80070520): A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520)
   at Microsoft.Web.Administration.Interop.IAppHostMethodInstance.Execute()
   at Microsoft.Web.Administration.ConfigurationMethodInstance.Execute()
   at Microsoft.Web.Administration.Binding.AddSslCertificate(Byte[] certificateHash, String certificateStoreName)
   at Microsoft.Web.Administration.BindingManager.BindingTransaction.Commit()
   at Microsoft.Web.Administration.BindingManager.Save()
   at Microsoft.Web.Administration.ServerManager.CommitChanges()
   at Microsoft.IIS.Administration.WebServer.MgmtUnit.Commit()
   at Microsoft.IIS.Administration.WebServer.Sites.SitesController.Patch(String id, Object model)
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.<InvokeActionFilterAsync>d__28.MoveNext()

[silverBull3t]

Iis 7.5 and wildcard certs are not the best match.
I had to perform some voodoo to enable SNI on it in order to make it work with a header.
It cant be done in the GUI. I use appcmd to attach the binding.
I'm sure that is the root of the problem or atleast a part of it.
The exception you got is different then my.
Would sending you my binding script help ?

[jimmyca15]

Yes, add it if you don't mind.

[jimmyca15]

Also did you try restarting iis with iisreset.exe and also maybe restart the Microsoft IIS Administration service?

c:\>iisreset

Attempting stop...
Internet services successfully stopped
Attempting start...
Internet services successfully restarted

c:\>net stop "Microsoft IIS Administration"
The Microsoft IIS Administration service is stopping.
The Microsoft IIS Administration service was stopped successfully.

c:\>net start "Microsoft IIS Administration"
The Microsoft IIS Administration service is starting.
The Microsoft IIS Administration service was started successfully.

After finding an article that mentions that IIS 7.x may need certificates to be imported with the private key set as exportable I re-imported the certificate I was using and from that point everything was working correctly.

I am still trying to reproduce the issue that you were seeing, but from the error message it seems that either IIS or the Administration service entered a bad state.

[silverBull3t]

appcmd set site /site.name:"%1" /+bindings.[protocol='https',bindingInformation='xxx.xxx.xxx.xxx:443:%1.yyy.com']

[silverBull3t]

and yep.
I restarted IIS using iisreset and also restarted IIS Admin Service. that was one of the first things I tried.

[silverBull3t]

any ideas ?
maybe connecting remotely to my system and seeing the bug would help?

[jimmyca15]

I have not been able to get the bug reproduced so I haven't come up with any workarounds at this point. I have yet to use the appcmd you and perhaps that will cause the error.

A connection to the affected system would be very helpful, however there is no secure way to provide credentials so reproduction steps are the best bet. I'm trying to hit the bug again right now.

[jimmyca15]

You mentioned that you get an error when trying to create the binding through the inetmgr.exe UI right? Is it the same error message?

[jimmyca15]

I just reproduced the issue by using the appcmd command you sent.

appcmd set site /site.name:"Default Web Site" /+bindings.[protocol='https',bindingInformation='127.0.0.1:443:abc.abc.com']

[silverBull3t]

Nope. Actsualy it's not posoible to set this binding from the UI.
This is why i have the script.

So...after using my binding script you get them same exact error ?
If so this is good news. I hope a patch will soon follow.

[jimmyca15]

I noticed that the appcmd script that you provided sets a specific value for the ip address in the binding information attribute. This appears to be what is causing the issue. Do you have multiple ip addresses assigned to the server that you are creating the binding on?

[jimmyca15]

If you change your script to listen on all IP the problem should disappear

appcmd set site /site.name:"%1" /+bindings.[protocol='https',bindingInformation='*:443:%1.yyy.com']

[silverBull3t]

I need to try this.
The problem is that i have hundrads of sites allready setup this way. I would need to go over all of them or atleast write a script for that.
Also, i dont know how this would work with multiple certs on other ip addresses. I would need to do some testing to make sure it doesn't break.

Also, there is a big chance that other users will encouter this bug. I believe it would be better to have a fix for this issue instead of going through hundrads of sites in a production server.

What do you think ?

[jimmyca15]

I agree that the problem should be addressed. Specifying '*' as the IP address is a workaround of sorts to make the API operable.

It looks like the problem is not something that will have a simple work around to accomplish the same level of functionality. I have not yet dived into the code to get the root cause but it could be far down in the stack.

[jimmyca15]

@silverBull3t

We have found out what is causing this issue to occur on IIS 7.5 machines. There will be a fix for this in our next release.

No workaround is available for viewing the bindings of the sites that have a value other than * for the ip address.

However, viewing sites is still possible as long as the fields query parameter is provided to select fields other than bindings.

Requesting this URL /api/webserver/websites/{website.id}?fields=name,physical_path,key,status,server_auto_start,enabled_protocols,limits,application_pool will show all the website's properties other than bindings.

[silverBull3t]

great, thank you.
hope the release will come soon.

[jimmyca15]

Hello @silverBull3t we just released a new version of the IIS Administration API. The 2.2.0 release fixes this issue.

Fixed by #168