Top Rated

Archive for the ‘IIS’ Category

I recently ran into an interesting issue when developing a connector for a third-party API. When trying to connect to the API endpoint, I received the following error message:

“An error occurred while making the HTTP request to https://<API endpoint>. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server.” Inner exception was “Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.”

Not very informative at first glance, right?

However, after some digging around I realized that the error message was correct, at least in the following part: “This could also be caused by a mismatch of the security binding between the client and the server.” I checked my SOAP bindings, and everything seemed to be correct: server required SSL connection, and I had TransportLevelSecurity specified in my binding:

var binding = new BasicHttpBinding(BasicHttpSecurityMode.Transport);

After I read more about SSL and Transport Level Security (TLS), I understood that “not all HTTPSs are created equal.” HTTPS relies on a family of lower level security protocol implementations called transport level security (TLS), each using different cryptographic algorithms. TLS standards keep developing and improving. At the moment TLS 1.2 is a latest encryption standard powering SSL and TLS 1.3 is in works. In general, anything that is using TLS standard below TLS 1.2 is considered to be non secure because these older encryption algorithms are known to be cracked.

Apparently, the provider of the API I was trying to call disabled all other security protocols except for TLS 1.2. That was reason I was getting the error.

So, why didn’t .NET framework support TLS 1.2 in my case? Well, that was because my application was using .NET 4.0. In .NET 4.0 default transport level security standard is TLS 1.1. The solution for my problem was to upgrade my application to the latest .NET framework: 4.6.1. In this framework version TLS 1.2 is a default cryptographic standard.

But what if you can’t upgrade your application to latest .NET framework and still want to use TLS 1.2? Solutions exist, but they vary depending on the framework version:

.NET 4.6 and above. You don’t need to do any additional work to support TLS 1.2, it’s supported by default.

.NET 4.5. TLS 1.2 is supported, but it’s not a default protocol. You need to opt-in to use it. The following code will make TLS 1.2 default, make sure to execute it before making a connection to secured resource:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

.NET 4.0. TLS 1.2 is not supported, but if you have .NET 4.5 (or above) installed on the system then you still can opt in for TLS 1.2 even if your application framework doesn’t support it. The only problem is that SecurityProtocolType in .NET 4.0 doesn’t have an entry for TLS1.2, so we’d have to use a numerical representation of this enum value:

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

.NET 3.5 or below. TLS 1.2 is not supported and there is no workaround. Upgrade your application to more recent version of the framework.

P.S. For scenario #3 there is also a registry hack which forces 4.5 to use TLS 1.2 by default without enforcing it programmatically.

Tip on preventing the delay that commonly occurs from a cold hit on an ASP.NET website running on IIS. This tip seemed to strike a chord with a few developers so I’ve decided to expand on it here.

The First Hit

Have you ever thought that the first request to your ASP.NET application seems to take much longer than others? If so, then you’re not imagining things…it actually does. That’s because to maximize resources IIS doesn’t keep all sites on an instance running at all times. In fact, the AppDomain for a website on IIS is not loaded until its needed and, by default, will eventually be unloaded after a period of inactivity.

It’s this lazy-loading of websites that causes the first request to an ASP.NET site to take so much longer than others. Since the site hasn’t been accessed yet, it must first be loaded by IIS before ASP.NET can properly respond to the request.

Luckily there is a solution. Auto-Start, introduced with IIS 7.5, allows an ASP.NET application deployed to IIS to be available immediately after deployment. In the simplest sense, enabling this feature causes IIS to prime an application as soon as it is deployed removing the warm-up time often required of “cold hits” to a website. In this article we’ll see how we can enable this feature either through IIS Manager or configuration files and even how we can perform more advanced application warm-up routines, such as priming a cache.

Configuring Auto-Start with IIS Manager

Enabling Auto-Start via IIS is actually quite simple, though the settings can be tricky to find the first time.

Open Internet Information Services (IIS) Manager.

In the Connections pane, select the Application Pools node, revealing the Application Pools pane in the main view.

Select the application pool for which you wish to enable Auto-Start.

Click Advanced Settings…

Locate the Start Mode option under the General group and set it to AlwaysRunning.

Click OK.

That’s it! Now the website hosted by the application pool you just modified will always be instantly available, even after extended periods of activity.

Configuration Auto-Start with applicationHost.config

Enabling Auto-Start using the IIS Manager UI is quick and simple, but tweaking the settings for all of your application pools via the user interface may not be scalable. For example, imagine that you were rolling out your website to a large web server farm and need to automate the configuration of all your application pools.

In this case, we can also enable Auto-Start by tweaking the applicationHost.config file which controls the application domains for all instances running on that server. applicationHost.config can be found at <Windows>\System32\inetsrv\config\applicationHost.config.

Inside of the applicationHost.config file, locate the <applicationPools> node located under <configuration>/<system.applicationHost>. Inside of the <applicationPools> node, locate the entry whose name attribute corresponds to your application pool, and add a startMode attribute with the value of “AlwaysRunning”.

The addition of the startMode attribute will override the default start mode of “OnDemand“.

Advanced Application Warm Up with Auto-Start

We’ve seen how to work around the “cold-hit” problem that often affects websites running on IIS. However, imagine that early requests to your site can still cause delays, perhaps due to expensive data that has to be retrieved. In these cases you can certainly cache the data after it’s retrieved to make subsequent requests faster, but the unlucky visitor who first makes the request still has to bear the brunt of the work for others.

While in the past it wasn’t unheard of for developers to prime their caches with these expensive data requests in the Application_Start() function of Global.asax.cs, IIS now provides a cleaner way through the use of Auto-Start Providers.

For example, let’s imagine that the home page of your application contains a rather expensive call. In the fact, the call is so expensive that we’ve elected to cache the results improve the performance of subsequent requests. However, this still lays the bulk of the work at the feet of the site’s first visitor.

While this technique does improve the performance for subsequent visitors, it still lays the bulk of the work at the feet of the site’s first. However, IIS now provides a better place to perform these types of warm-up tasks.

Preload clients, which implement the IProcessHostPreloadClient interface, contain a single method Preload(…) which can be used to cleanly perform these warm-up tasks.

However, this class will not be loaded automatically. We need to tell IIS both about the existence of this class as well as which website it applies to. To do this, we’ll need to return to our applicationHost.config file.

First, we’ll need to add an element called <serviceAutoStartProviders> to the <configuration>/<system.applicationHost> node.

This is done by adding the serviceAutoStartEnabled attribute, set to true, and by adding the serviceAutoStartProvider attribute, set to the name of the serviceAutoStartProvider entry we added in the previous step.

Wrapping Up

With just a few easy steps we’ve ensured that our application is always ready to go when a user a visits. In addition, we’ve also discovered an easy way to offload time intensive operations, such as priming a cold cache, from the first user to the initial startup of the application. With these two tips in hand we’re sure to have a fast and responsive application that our users will rave about.

A lot of you have probably had problems setting up complete unavailability of your public web site running the Agile Platform on IIS; for example, to run Maintenance tasks.

Sure, if you want to put one individual application offline you can use the Put Offline option in Service Center, but what if you want to bring everything down?

Or what if you are using a older version of the Agile Platform (6.0-) with out the Put Offline option?

At IIS level there are multiple ways to cut access to an application. My prefered way is to use a trick based on the 403.6 error – that means creating a list of IP that are allowed to access and leave the others out.

In this scenario I will only allow 127.0.0.1 to pass through – this will give me the option to access the apps and Service Center when logged on the server to confirm that things are working after the maintenance is complete.

This is how it is done.

Prepare the server

This is something you do only once in each server to prepare it.

—

1. Create an HTML maintenance page, and save it somewhere. The simplest HTML content you may use is something like:

<html><body><p>This server is under maintenance</p></body></html>

Save it in a file in the server – I suggest C:\Inetpub\wwwroot\maintenance.html

—

2. Now create the custom error page for the 403.6 error to point to this page:

4. Finally fix a setting in ApplicationHost.Config that prevents you from using absolute paths in error pages. For this, open a Notepad (right-click, Run As Administrator), open file C:\Windows\System32\InetSRV\Config\ApplicationHost.config, locate the tag <httpErrors and add attribute allowAbsolutePathsWhenDelegated=”true”.

For this step, make sure to make a backup copy of the file before any editing.

Put the server offline

When you want to put your server offline you need to go back to IP Address and Domain Restrictions.

Here, choose Edit Feature Settings and switch the default to Deny:

When you do this, immediately all accesses to your IIS from outside the server will produce this result:

But you will still be able to access from inside the machine (and timers continue to run, and etc).

Bring the server back online

For this, simply revert the IP Address and Domain Restrictions – from Deny to Allow.

HTTP Blacklist

The HTTP Blacklist, or “http:BL”, is a system that allows website administrators to take advantage of the data generated by Project Honey Pot in order to keep suspicious and malicious web robots off their sites. Project Honey Pot tracks harvesters, comment spammers, and other suspicious visitors to websites. Http:BL makes this data available to any member of Project Honey Pot in an easy and efficient way.

Http:BL provides data back about the IP addresses of visitors to your website. Data is exchanged over the DNS system. You may query your local DNS server and receive a response back that indicates the type of visitor to your site, how threatening that visitor is, and how long it has been since the visitor has last been seen within the Project Honey Pot trap network.

Http:BL has been implemented on a number of different web servers, content management systems, blogging platforms, and forums. These systems query the http:BL servers for visitors to your site and restrict their access if they are found to be malicious. Note that version numbers are not always up to date.

An elegant way to handle change when it comes to renaming and moving pages around within an ASP.NET web application is to take advantage of the IIS 7 Rewrite module. With this strategy in place I can easily add redirects to a single xml file and update it as needed.