andyfrench.info

This post is a quick follow up to an earlier one, Generating temp SSL certificates for development, which showed a manual method for creating self-signed certificates. If you’ve got IIS 7 then the following method is much quicker and easier.

The method

Open the Internet Information Services (IIS) Manager.

Select the server node in the connections pane.

Find the Sever Certificates item and double-click on it.

Right-click in the Server Certificates pane and choose Create Self-Signed Certificate… from the pop-up menu.

In the dialog box provide a friendly name for the certificate and click OK.

 

That’s all there is to creating a self-signed certificate in IIS 7!

To use the certificate on a web site hosted in IIS you need to open the Sites node in the Connected Sites pane and select the web site that needs the SSL certificate.

In the Actions pane on the right click Bindings…

If there isn’t an HTTPS binding you’ll have to add one in the Site Bindings dialog. You could edit an existing HTTPS binding if you need to.

You’ll be prompted to select an SSL certificate for the binding. Just select the self-signed certificate you’ve created. Click OK and you’re done.

You are now ready to use SSL on your website.

References

• Create a Self-Signed Server Certificate in IIS 7 (TechNet)

Read More

Problem

I needed to host a WCF 3.5 web service on IIS 7 (running on Windows Server 2008) using SSL. In fact the service was configured to use wsHttpBinding with TransportWithMessageCredential. The service was running on a public facing web server with a registered domain name.

The problem was usual one; having navigated to .svc file in a browser the service description page showed the WSDL URL to be using the machine name, not the domain name. When viewing the generated WSDL the service location was also using the machine name.

Solution

The web site bindings had been set up in IIS for HTTP and HTTPS. It appears that when the HTTPS binding is setup the host name is not set. You cannot set this using the Internet Information Services (IIS) Manager so you have to do it by other means.

 

To add the host name to the HTTPS binding do the following:

1. Open the applicationHost file located in C:\Windows\System32\inetsrv\config.
2. Locate the section for the website in question (you can see the web site name in the Internet Information Services (IIS) Manager).
3. Find the https binding and change the bindingInformation by adding the domain name after “:443:”.
4. Save the applicationHost file and restart IIS.

 

Now when you view the service .svc file in a browser and the generated WSDL the domain name will appear in place of the machine name.

Read More

You may have noticed that when creating or editing application pools in IIS 7 you can choose between 2 different modes: Classic and Integrated. So what’s the difference?

Firstly, a quick reminder on how to get to the application pools. Crack open the IIS manager and select Application Pools from the connections tree-view on the left. You’ll see a list of application pools which you can select. If you right-click on an application pool and choose “Basic settings…” in the pop-up menu you can change the “Managed pipeline mode” using a drop-down. [2]

 

IIS manager showing basic settings for an application pool

 

Microsoft documentation describes an application pool in the following terms:

“An application pool is a group of one or more URLs that are served by a worker process or a set of worker processes. Application pools set boundaries for the applications they contain, which means that any applications that are running outside a given application pool cannot affect the applications in the application pool.” [1]

It goes on to say:

“The application pool mode affects how the server processes requests for managed code. If a managed application runs in an application pool with integrated mode, the server will use the integrated, request-processing pipelines of IIS and ASP.NET to process the request. However, if a managed application runs in an application pool with classic mode, the server will continue to route requests for managed code through Aspnet_isapi.dll, processing requests the same as if the application was running in IIS 6.0.” [1]

In versions of IIS prior to version 7, ASP.NET integrated with IIS via an ISAPI extension (aspnet_isapi.dll) and and ISAPI filter (aspnet_filter.dll). It therefore exposed its own application and request processing model which resulted in “ASP.NET components executing entirely inside the ASP.NET ISAPI extension bubble and only for requests mapped to ASP.NET in the IIS script map configuration” [3]. So, in effect, there were 2 pipelines: one for native ISAPI filters and another for managed application components (ASP.Net). This architecture had limitations:

“The major limitation of this model was that services provided by ASP.NET modules and custom ASP.NET application code were not available to non-ASP.NET requests. In addition, ASP.NET modules were unable to affect certain parts of the IIS request processing that occurred before and after the ASP.NET execution path.” [4]

In IIS 7 the ASP.NET runtime was integrated with the core web server, providing a unified request processing pipeline exposed to both native and managed components.

Some benefits of the new architecture include:

• Allowing services provided by both native and managed modules to apply to all requests, regardless of handler. For example, managed Forms Authentication can be used for all content, including ASP pages, CGIs, and static files.
• Empowering ASP.NET components to provide functionality that was previously unavailable to them due to their placement in the server pipeline. For example, a managed module providing request rewriting functionality can rewrite the request prior to any server processing, including authentication.
• A single place to implement, configure, monitor and support server features such as single module and handler mapping configuration, single custom errors configuration, single url authorization configuration. [3]

There’s a nice description of how ASP.Net is integrated with IIS 7 here.

References

• [1] Managing Application Pools in IIS 7
• [2] Configure the Request-Processing Mode for an Application Pool (IIS 7)
• [3] How to Take Advantage of the IIS 7.0 Integrated Pipeline
• [4] ASP.NET Integration with IIS 7

Read More

Make sure failed request tracing (FRT) is installed

You can tell if FRT is installed because when you open the IIS manager and select a web site the option to Failed Request Tracing… option is missing.

 

Fig 1 - IIS Manager with no Failed Request Tracing… option

 

To enable this feature:

1. Open the Server Manager.

2. Expand Roles and select Web Server (IIS).

 

Fig 2 – The Server Manager

 

3. Scroll down to the Role Services section.

4. The Tracing feature will not be installed.

 

Fig 3 – Tracing feature not installed.

 

4. Click Add Role Services.

5. Enable Tracing.

Fig 4 – Enable Tracing

 

6. Click Next etc. to install the feature.

7. Close the Server Manager and reopen the IIS Manager and select a web site.

8. Failed Request Tracing… is now available.

 

Fig 5 – Failed Request Tracing… is now available.

 

9. Click on Failed Request Tracing… and select Enable.

10. Click OK.

 

Fig 6 – Enable Failed Request Tracing…

Read More

The problem

I ran into the situation where a WCF service had a reference to sever 3rd party components. One of the components itself actually had a reference to some ancient 16-bit code. The WCF service was hosted in IIS7 on a 64-bit machine and used Unity to resolve dependencies.

As Unity tried to resolve dependencies I kept getting an error that looked a bit like this:

Unexpected exception thrown by call to <service type here>: Resolution of the dependency
failed, type = "<service contract interface here>", name = "(none)".
Exception occurred while: Calling constructor <type that failed construction>.
Exception is: FileNotFoundException - Could not load file or assembly <assembly name here>,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=<key here>' or one of its dependencies. 
The system cannot find the file specified.

 

The solution

The solution was to configure the application pool that the service was using to allow 32-bit assemblies.

1. View application pools and select the appropriate pool from the list.
2. Choose ‘Advanced settings…’ from the menu on the right.

3. Set ‘Enable 32-Bit Applications’ to True.
4. Click OK.

Read More

Problem

I needed to deploy a WCF service to IIS7 running on windows server 2008. The service was accessed via a .svc file but upon calling it from a browser an error was reported stating that the .svc extension was not recognised.

Solution

The solution was to reregister the WCF Service Model with IIS by running ServiceModelReg.exe:

"%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe" -r -y

The flags used were:

Flag	Description
-r	Re-registers this version of WCF and updates scriptmaps at the IIS metabase root and for all scriptmaps under the root. Existing scriptmaps are upgraded to this version regardless of the original versions.
-y	Do not ask for confirmation before registering or re-registering components.

After reregistering the WCF Service Model the .svc extension was correctly installed. Note that IIS7 did not require a restart.

Full details of ServiceModelReg.exe and all its flags can be found here: ServiceModel Registration Tool (ServiceModelReg.exe)

Read More

Update 01/03/2014

If you’re using IIS 7 there is a quick way to create self-signed certificates. Details can be found in this post: Create a self-signed certificate for development in IIS 7.

If you still want to know about the manual method read on.

Original post

I needed to generate an SSL certificate for testing a WCF service which needed to be secure. Not wanting (or having the budget for) a real SSL certificate I elected to generate my own. The following batch file contains the main ingredients:

@echo off

echo Step 1 - Creating a self-signed root authority certificate and export the private key.
echo You will be prompted to provide a password to protect the private key.
echo The password is required when creating a certificate signed by the root certificate.
echo ===================================================================================
makecert -n "CN=RootTempCA" -r -sv RootTempCA.pvk RootTempCA.cer

echo Step 2 - Create a new certificate signed by a root authority certificate
echo ========================================================================
makecert -sk domain.to.secure -iv RootTempCA.pvk -n "CN=domain.to.secure" -ic RootTempCA.cer -sr localmachine -ss my -sky exchange -pe

The domain.to.secure should be replaced to match the environment (this could be localhost, the machine name, whatever you need). Step 2 should install the certificate into the certificate store – no need to do it manually.

The makecert flags used above breakdown as follows:

Flag	Step	Description
-n subjectname	1, 2	Specifies the subject name. The convention is to prefix the subject name with "CN = " for "Common Name".
-r	1	Specifies that the certificate will be self-signed.
-sv privateKeyFile	1	Specifies the file that contains the private key container.
-sk subjectKey	2	The location of the subject's key container that holds the private key. If a key container does not exist, one is created. If neither of the -sk or -sv options is used, a key container called JoeSoft is created by default.
-iv issuerKeyFile	2	Specifies the issuer's private key file.
-ic issuerCertFile	2	Specifies the location of the issuer's certificate.
-sr location	2	Specifies the subject's certificate store location. location can be either currentuser (the default) or localmachine.
-ss store	2	Specifies the subject's certificate store name that stores the output certificate.
-sky keytype	2	Specifies the subject's key type, which must be one of the following: signature (which indicates that the key is used for a digital signature), exchange (which indicates that the key is used for key encryption and key exchange), or an integer that represents a provider type. By default, you can pass 1 for an exchange key or 2 for a signature key.
-pe	2	Marks the generated private key as exportable. This allows the private key to be included in the certificate.

Because this process creates a self-signed certificate if you access the service from a remote machine you will likely run in to problems because the certificate was issued by an unknown Certification Authority. To get around this you need to import the root certificate into the trusted root certificate store on the client machine. I find it best to import the certificate using a Personal Information Exchange (pfx) file. To create the .pfx run the following:

pvk2pfx.exe -pvk RootTempCA.pvk -spc RootTempCA.cer -pfx RootTempCA.pfx -po password_here

References

• How to: Create Temporary Certificates for Use During Development
• How to: View Certificates with the MMC Snap-in
• Makecert.exe (Certificate Creation Tool)

 

See also

• Keyset does not exist

Read More

I was trying to run a WCF service with additional security and generated the following “Keyset does not exist” error:

 

Reading the stack trace I got the following additional information:

[ArgumentException: It is likely that certificate 'CN=RPKey' may not have a
private key that is capable of key exchange or the process may not have access
rights for the private key. Please see inner exception for detail.]

This turned out be file security settings on the key file. To fix the problem you may need to grant file permissions to the appropriate key file (in this case the RPKey file). To find the location of the key file I ran the FindPrivateKey utility which shipped with the WF and WCF Samples obtained from MSDN. Build the FindPrivateKey sample an run it in a command window:

C:\...path here...\FindPrivateKey\CS\bin>findprivatekey My LocalMachine -n "CN=RPKey" –a 

This gave the location of the key file and I was able to grant permissions to the ASPNET user. You may need to grant permissions to the network service user.

Normal service restored.

Read More

I thought it was time to review process and application domains in .Net…

Processes

In general terms a processes is an operating system construct used to run programs. A process can own resources like memory and kernel objects and often a single process can have multiple threads running inside it which in turn execute the code. Where multiple threads are used code can execute concurrently. It is the operating system that takes the responsibility to protect processes from interfering with each other.

Application domains

The .Net framework and the CLR introduced a new concept above standard operating system processes: the application domain. An application domain forms an isolation boundary for security, versioning, reliability, and unloading of managed code. Each application domain has its own virtual address space which scopes the resources for the application domain. In effect an application domain is the CLR equivalent of an operation system process and is used to isolate one application from another.
A CLR application domain is itself contained within an operating system process and a process may contain many application domains. In effect the CLR functions like an operating system within an operating system; it runs in a single process but contains multiple sub-processes (application domains).
MSDN documentation states:

“Operating systems and runtime environments typically provide some form of isolation between applications. For example, Windows uses processes to isolate applications. This isolation is necessary to ensure that code running in one application cannot adversely affect other, unrelated applications.
Application domains provide an isolation boundary for security, reliability, and versioning, and for unloading assemblies. Application domains are typically created by runtime hosts, which are responsible for bootstrapping the common language runtime before an application is run.” *

Some features of application domains are:

• Multiple threads can run in a single application domain
• Security access levels can be applied to application domains individually
• Faults or exceptions in one domain do not affect another domain or the entire process that hosts the domains
• Configuration is scoped to the application domain and not the scope of the host process
• Code running in one domain cannot directly access code running in another
• Stopping an application in one application domain does not affect the state of another domain in the same process

The advantage of Application Domains is that running multiple Application Domains requires fewer resources, such as memory, than running multiple operating system processes. Again, MSDN documentation states:

“Application domains provide a more secure and versatile unit of processing that the common language runtime can use to provide isolation between applications. You can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of making cross-process calls or switching between processes. The ability to run multiple applications within a single process dramatically increases server scalability.” *

A quick note on worker processes and application pools

An Internet Information Services (IIS) worker process is a windows process (w3wp.exe) which runs web applications, and is responsible for handling requests sent to a web server for a specific application pool (see below). Each worker process hosts its own CLR.
An Internet Information Services (IIS) application pool is a grouping of URLs that are routed to one or more worker processes. Application pools provide a way to administer a set of web sites and applications and their corresponding worker processes. Worker processes are separated by process boundaries so a web site or application in one application pool will not be affected by problems in other application pools. Application pools increase the reliability and manageability of a web infrastructure.

See also

* MSDN documentation, Application Domains. TechNet documentation, IIS Application Pool.

Read More

The following rules might help out in protecting a site against SQL injection:

[ISAPI_Rewrite]
RewriteRule .*(?:global.asa|default\.ida|root\.exe|\.\.).* . [F,I,O]

RewriteRule .*(?:DECLARE).* /null.htm [F,I]

RewriteRule ^.*\+update\+.*$ /null.htm [F,I]
RewriteRule ^.*SUBSTRING\(.*$ /null.htm [F,I]
RewriteRule ^.*CHARINDEX.*$ /null.htm [F,I]
RewriteRule ^.*NVARCHAR.*$ /null.htm [F,I]
RewriteRule ^.*CHAR\(.*$ /null.htm [F,I]
RewriteRule ^.*CAST\(.*$ /null.htm [F,I]
RewriteRule ^.*%20xp_.*$ /null.htm [F,I]
RewriteRule ^.*%20@.*$ /null.htm [F,I]
RewriteRule ^.*@%20.*$ /null.htm [F,I]
RewriteRule ^.*';*$ /null.htm [F,I]
RewriteRule ^.*EXEC\(@.*$ /null.htm [F,I]
RewriteRule ^.*sp_password.*$ /null.htm [F,I]

F – forbidden
I – Ignore case

Read More

IIS needs to be set-up to use the Microsoft MVC framework or you will get an error along the lines of 'controller can't be found'. A new file extension needs to be added to IIS.

1. Open the IIS MMC snap-in.
2. View the properties for the webs site in question.
3. Go to the Home Directory tab.
4. Click Configuration...
5. Add a new extension (.mvc).
   
   1. Map the extension to the aspnet_isapi.dll.
   2. Limit to the following verbs: GET,POST,HEAD,DEBUG.
   3. Uncheck the 'Check that file exists' and 'Script engine' checkboxes.

Read More

If you get this error...


... check that the ASP.NET settings on the IIS Virtual Directory are set to the right ASP.NET version (i.e. version 2).

Read More