0

We're trying to test our web apps on Server 2019 to see how they're going to work. We have our Team City deploy working, and now I'm trying to figure out what's going on with Server 2019.

Any page on https:// gives me the error:

HTTP 503

Source:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Service Unavailable</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Service Unavailable</h2>
<hr><p>HTTP Error 503. The service is unavailable.</p>
</BODY></HTML>

If I go to a page on Http:// it works.

There is nothing else going on with this.

The Application

The application is an ASP.NET 4.6 MVC app. It currently works on multiple servers from 2012 to 2016, and windows 10 w/o issues.

Setup:

  • Brand new AWS EC2 (Web App)
  • All ASP.NET Services for 4.7 have been installed.
  • SQL Server is installed on this EC2
  • List item
  • IIS is setup with correct app pools (and they're started)
  • Bindings are correct
  • I have given NEtwork Services and IIS USER full control over the /website/ folder
  • Binding Information: enter image description here

What I've done

  • gone through ~30 posts on HTTP 503 w/o any luck.
  • I added a test.html page to one of the applications. I still get a HTTP 503 with this.
  • verified the root SSL cert is installed correclty
  • installed intermediate ssl certs
  • Added a new user to the server, gave them "All" permissions and full control over /websites/, set them as the user in the App Pool (restarted app pool) and still a 503.
  • Quintuple checked the app pools to make sure they're started. They are started.
  • I do not see any errors in the Event Logs or /Server Roles/ Web Server (IIS) logs.
  • Running the command: netsh http show urlacl url=https://+:443/

I get both of these at times:

Reserved URL            : https://+:443/
Can't get security descriptor, Error: 87


    Reserved URL            : https://+:443/
    SDDL: O:NS

I'm at a loss as I have no other information as to why 503 is coming back. It's almost as if IIS isn't running, as it's not even able to server up a test.html page. I fully expect this to be something dead simple where I'll face palm for a week or something unique with Server 2019.

Ryan Ternier
  • 8,714
  • 4
  • 46
  • 69
  • What auth schema settings are enabled for the website in IIS? (IIS> Expand Sites > select site in question > select authentication in right pane) – Travis Acton Sep 10 '19 at 18:37
  • @TravisActon Anonymous Authentication is Enabled, the rest are disabled. This is similar to our production site. – Ryan Ternier Sep 10 '19 at 18:55
  • Click the edit button when you select anon and make sure it is using your app pool identity – Travis Acton Sep 10 '19 at 18:57
  • @TravisActon it is using IUSR. The app pool is using ApplicationPoolIdentity. I changed it to another group and a few other options and it changed nothing. – Ryan Ternier Sep 10 '19 at 19:15
  • Alright, I have narrowed it down to SSL. If I go to a site on http:// it shows, with https:// Service is Unavailable. – Ryan Ternier Sep 10 '19 at 19:21
  • Ok so now double check (just to be sure) that https is enabled for the site: Site > Advanced Settings > Enabled Protocols > make sure you have https in here as well – Travis Acton Sep 10 '19 at 20:00
  • @TravisActon http, https are both selected in Enabled Protocols – Ryan Ternier Sep 10 '19 at 20:34
  • The only remaining piece of advice I can give without being on the server is to check and make sure nothing else is parked on your 443 port for the machine and reserving it. You can check by running the following in a command prompt: netsh http show urlacl url=https://+:443/ – Travis Acton Sep 10 '19 at 20:57
  • @TravisActon Updated my question with the response. – Ryan Ternier Sep 10 '19 at 22:21
  • https://docs.jexusmanager.com/tutorials/binding-diagnostics.html#background You might check whether the site bindings are correct. As you didn't reveal the actual HTTPS URL in the screen shot, the browser might go to a wrong site, whose application pool was disabled. – Lex Li Sep 10 '19 at 22:30
  • @LexLi The URL won't help much. but I've added binding information to the question. Thanks. – Ryan Ternier Sep 10 '19 at 22:35
  • 1
    If I read that right(on a phone) then looks like it’s marked as reserved. Flip your site in IIS to use port 8443 instead of 443 or you can flip the command for netsh from show to delete to clear the res. I’d be a bit hesitant on the delete for res if you do t know why it’s there in the first place... – Travis Acton Sep 10 '19 at 22:51
  • I deleted whatever was holding onto the 443 port. seems to be working. I'm not sure what would do that, but removing it fixed it. Please add that as an answer so I can mark it for you! – Ryan Ternier Sep 10 '19 at 23:07
  • Glad to see a resolution for you, answer has been added. – Travis Acton Sep 11 '19 at 13:41

1 Answers1

2

Root cause extracted from comments troubleshooting:

In the event that IIS is serving an application on http but receiving 503 service unavailable for https AND it is confirmed that both http and https protocols are enabled, verify that the SSL port 443 is not reserved by the system.

You may do this by running the following from command line:

netsh http show urlacl url=https://+:443/

If the output confirms that the URL is reserved then you have two options:

  1. Delete the reservation by running command 

    netsh http delete urlacl https://+:443/

***If reserved port must remain intact (Run cmd netstat -a -n -o | findstr 443 to find the PID running on the port and use process explorer to identity the process from the PID) then use option 2

  1. Re-provision your application to run on port 8443 (assuming that is not also shown in the reserved url list.

***Although you can use any port to run SSL, browsers automatically prefix 443 and 8443 with https. Applications using SSL comms on ports other than 443 and 8443 must take special care to redirect users to https as browser will not auto prefix. Also to note that it is common practice for some access points disable comms not coming over 80 or 443 so environmental factors may play into the usage of switching the port...ie do your due diligence for your users :)

Travis Acton
  • 4,292
  • 2
  • 18
  • 30
  • The culprit was Windows Admin Center holding onto port 443. After i unreleased control on it, we uninstalled it. – Ryan Ternier Sep 12 '19 at 16:05
  • Looks like you can define the port it uses on install, good to know these little gotchas for future use. Not much documentation on how you can change the port post installation though. I would imagine there would be more robust documentation as I imagine there would be much more people hitting this issue... – Travis Acton Sep 12 '19 at 16:37