Cleanly driving SSL and WWW prefix on IIS


Infrequently enough to forget, I find the need to redirect all non-SSL requests to SSL… or similarly, force the WWW prefix onto a url when the initial navigation comes in without it.
I instinctively reach for the URLRewrite module due to it’s flexibility, but i’ve found that it can actually lead me astray in these particular scenarios…


Create a separate IIS web site for the “undesirable” url which does a simple HTTP Redirect to the desired path


Especially in the case of SSL, this is definitely the way to go because you’ll also want to enable “Require SSL” … which outright prevents the the non-ssl url from being able to respond with a URLRewrite Rule… i.e. the Require SSL checkbox yields a hard 403 error immediately upon resolving the non-SSL path, no other logic executes… and at this point, the IIS admin console just stares back blankly awaiting orders with no help out of this blind alley.

Security bonus

by creating a site entirely for the non-ssl redirect, we can then set that site’s physical path to something harmless, leaving no doubt the SSL URL is the only way in to our sensitive physical path.

Separate Physical Folder FOR EACH SITE

To be perfectly clear, each redirecting sites’ physical folder will now merely provide containment for its corresponding solitary web.config, yet it is crucial each site is indeed configured with a unique physical path and web.config… this is obvious once considered but can be a momentary point of confusion until one realizes why all the different sites’ settings are overlapping 🙂

[SOLVED] Comodo v7 blocking HTTP/S and FTP/S on Windows 8.1 IIS 8.5

Besides opening incoming HTTP ports in the firewall via “Global Rules”, the annoying thing for me to find was also adding an “Application Rule” for “Windows Operating System” on those same ports.

Comodo v7.0.317799.4142

And this guy explains what’s necessary for FTP very nicely…

  • in comodo > global settings > application rule – add 20,21 & 5000-6000 as allowed incoming TCP ports on “Windows Operating System”… you will also hopefully get prompted to allow svchost which is responsible for running the ftpsvc
  • on internet router – forward ports 20,21 and 5000-6000
  • in IIS FTP settings
  • filezilla settings
    • require explicit ftp over tls

CAC (SmartCard) Enabling ASP.Net on IIS

  • The only configuration settings required are (IIS7 screenshots below):
    • Require SSL (this represents server side)
    • and either Accept or Require Client Certificates … “Accept” will populate the SmartCard’s cert info to your ASP.Net Request object (if it’s provided) but won’t deny access if one hasn’t been provided, “Require” will deny access unless a valid SmartCard Cert has been provided.


  • One key thing to be aware of how this works is that the server will send a list of Trusted Root Certificates down to the client/browser and then the browser will compare that list to the Trusted Roots represented by the CAC present and only if there’s a match will it prompt for the Certificate and PIN input.  Therefore, both the Server and the client must have the same Trusted Root Certs installed for this to work, the easiest way to do this for the DoD CAC’s is to grab the latest install_root.exe and fire that up.
  • Another key thing I discovered was that after you get the certs installed, go ahead and do a reboot, I was still getting 403 access denied errors that simply disappeared after I rebooted.
  • Throw these lines in a ASP.Net wizard generated project’s Default.aspx to see the basic Cert info… the .Subject property is the juiciest looking info, there may be other properties of value.
    • <%=Page.Request.ClientCertificate.IsPresent%>
    • <%=Page.Request.ClientCertificate.Subject%>
  • It’s probably also helpful to go ahead and make sure your server side SSL cert is properly named & not expired, such that you don’t get any warnings when you browse to the page… I was getting some errors related to that when I was working with the Client Cert’s required.
    • this reference was helpful, see the section titled “Generate a Self Signed Certificate with the Correct Common Name”
    • this is the basic command you need to generate your own SSL cert for testing: SelfSSL / /V:9999
    • find SelfSSL in the IIS6 Reskit

image image

WebDrive (WebDAV client… that actually works!)

i was having a heck of a time trying to get “net use *” type WebDAV client mounts to connect… all that would ever work would be http://localhost … nothing i tried would connect to my WAN ip… always something like “System error 5… access is denied”… then i thought, ah what the heck, gotta google it… and sure enough… loaded the trial of WebDrive from South River Technologies simple little gui popped up, hit ok and two seconds later i was sitting on a W: drive in explorer… Right Mouse > New > Text Document worked, so i had write capability… obviously i had to twiddle some bits on the IIS end too but that was mainly just a matter following any typical IIS WebDAV walkthrough guide… cool, $60 for a one off license is reasonable…oh yeah, it’ll also map a drive letter to an FTP Server, Amazon S3 and SharePoint… i leave you with… ahhhhh yes the logo
UPDATE: plain vanilla “net use…” command worked straight away from an XP machine at work… so the security bits somehow weren’t lined up to let me be a WebDAV client on the Windows 7 instance i was testing with as my WebDAV IIS host… moving along…nothing to see here 😉
UPDATE 2: still gotta hand it to WebDrive… plain vanilla “net use” mounted WebDAV drives are running through Microsoft’s “WebDAV redirector” layer (aka the “WebClient” NT Service)… and it does work for small files, but large files (e.g. 250MB) tend to go off in lala land while doing the transfer (i.e. progress bar was useless) and failed consistently… WebDrive has a much more robust caching/chunky upload facility with a slick UI that shows actual progress bar… it did still fail after multiple attempts of my big test file so i had to split up into smaller chunks (e.g. 30MB) but the progress visibility WebDrive provides along with automatic retries is definitely worth something.

Enable IIS7 under BitDefender 2009 Firewall Rules

Create the following rule and make sure that it’s positioned numerically “above” (i.e. lower number) than all the service.exe related rules… especially above the main “deny” rule at the last slot… i’m assuming we’re dealing with the System process because IIS7 (Windows Vista/Server 2008) moved the core listener daemon responsibility down to a lower level than W3SVC.exeimage  image image