Thursday, November 21, 2013

X509Certificate2 certificate conversions

X509 certificates are useful for many common tasks. Some time ago I’ve blogged on how to create certificates programatically and how to sign and verify XML data in an interoperable way.

There are some common tasks about certificates. Let’s begin.

To access a system store and enumerate it:

X509Store store = new X509Store( StoreName.My, StoreLocation.CurrentUser );
store.Open( OpenFlags.ReadOnly );
foreach ( var cert in store.Certificates )
    Console.WriteLine( cert.ToString() );

To access a file system store (*.pfx) and enumerate certificates:

X509Certificate2Collection store = new X509Certificate2Collection();
store.Import( @"c:\filename.pfx", "password", X509KeyStorageFlags.DefaultKeySet );
foreach ( var cert in store.OfType<X509Certificate2>() )
    Console.WriteLine( cert.ToString() );

To load a single certificate from a file system store (*.pfx):

X509Certificate2 cert = 
  new X509Certificate2( @"c:\filename.pfx", "password", X509KeyStorageFlags.MachineKeySet );
Console.WriteLine( cert.ToString() );

To export a X509Certificate2 object to a file store (*.pfx) (with private key and protected with a password):

X509Certificate2 cert = ...;
File.WriteAllBytes( "cert.pfx", cert.Export( X509ContentType.Pkcs12, "foo" ) );

To export only a public key of the X509Certificate2 to a file (*.cer):

X509Certificate2 cert = ...;
File.WriteAllText( "cert.cer", Convert.ToBase64String( cert.Export( X509ContentType.Cert ) ) );

And last but not least, if you have a certificate in Base64 form (for example from ADFS2 federation metadata), just create a blank text file with *.cer extension, copy the base64 certificate, save. The file can be used from within the Windows shell.

(a side note here: although most web sources claim that base64 encoded certificates in text form need the ----BEGIN CERTIFICATE----- preamble and -----END CERTIFICATE----- at the end, this is not necessary).

For example, a first googled certificate from here stored in a cert.cer text file

and double clicked from the OS shell opens up as

Monday, November 18, 2013

MSB3147: Could not find required file 'setup.bin' on a x64 machine [.NET 4.5, cont.]

Over two years ago I’ve blogged on how to workaround the problem with building ClickOnce applications on a x64 build server. The solution was to manually create a registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\4.0 and add the Path value c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\ to it.

This worked for 2 years and last week we were hit with the issue once again. Reason? Well, .NET 4.5 has been installed on the server.

It seems that .NET 4.5 changes the way applications are built (new version of msbuild?). It no longer expects the old v7.0A SDK, instead it expects the v8.0A SDK.

Unfortunately, according to this table, there is no official installer for the v8.0A SDK. It is installed with VS2012 Update 2.

The solution was to:

1) Manually copy the contents of the c:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Engine folder from a dev machine to the build server

2) Manually create a registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\11.0 with Path set to the C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\

Important note! Although the setup.bin is physically inside the Bootstrapper\Engine subfolder, the Path points to Bootstrapper rather than Bootstrapper\Engine.

Important note 2! For some reason, the bootstrapper key corresponding to the v7.0A SDK has 4.0 suffix while the key corresponding to the v8.0A SDK ends with 11.0. A lot of unnecessary confusion and I am glad this works despite all this confusion.

Thursday, November 14, 2013

Basic Authentication Module with custom Membership Provider

The goal of this post is to document the “not-quite-practical” possibility of replacing Forms Authentication Module with a “401 Challenge”-Authentication-Module but still be able to use a custom membership provider.

The clarification could possibly dispel a common confusion – in ASP.NET the 401 Challenge authentication is often confused with Windows authentication scheme. The problem stems from the fact that the authentication module and the membership provider are two distinct responsibilities:

- your authentication could be “401 Challenge” based or cookie based (or even anything-else-based)

- your users credentials can be validated against AD or against a custom user store

Now, if you think about it, 4 combinations sound to make sense:

Windows membership Custom membership
302 Redirect (cookie) ActiveDirectoryMembershipProvider
<authentication mode="Forms">
Any custom membership provider
<authentication mode="Forms">
401 Challenge Windows authentication
<authentication mode="Windows">

You can have cookie based (forms) authentication with any membership provider, including the built-in ActiveDirectoryMembershipProvider. You can have “401 Challenge” based authentication with Windows accounts.

But what about “401 Challenge” based authentiaction with a custom membersip provider? ASP.NET has no built-in solution for this. You can have 401 Challenge-based authentication only for Windows accounts, in windows authentication mode.

This is why some people think that 401 Challenge basic authentication is only possible with Windows accounts.

Does it make sense?

Good question. There are many drawbacks of the 401 Challenge authentication, just to name a few:

- the login window is not customizable, it is built into your web browser

- there is no easy way to signal “wrong credendials” (a new 401 is returned)

There are also pros:

- 401 Challenge can be used in “active” scenario, where a client (ajax? webapi client?) can carry credentials in the very first request, without the need to redirect-with-a-cookie and then carry-cookie-with-each-request. In fact, the authentication header is automatically handled by all web browsers.

How to do it?

The code below is based mostly on the WebApi authentication module by Mike Wasson from his entry on WebApi. Minor modifications introduces authorization handling (the authentication is required only when authorization fails) and a call to a membership provider.

/// <summary>
/// Based on
/// </summary>
public class BasicAuthHttpModule : IHttpModule
    public void Init( HttpApplication context )
        // Register event handlers
        context.AuthenticateRequest += OnApplicationAuthenticateRequest;
        context.EndRequest += OnApplicationEndRequest;
    private static void SetPrincipal( IPrincipal principal )
        Thread.CurrentPrincipal = principal;
        if ( HttpContext.Current != null )
            HttpContext.Current.User = principal;
    private static bool AuthenticateUser( string credentials )
        bool validated = false;
            var encoding = Encoding.GetEncoding( "iso-8859-1" );
            credentials = encoding.GetString( Convert.FromBase64String( credentials ) );
            int separator = credentials.IndexOf( ':' );
            string name = credentials.Substring( 0, separator );
            string password = credentials.Substring( separator + 1 );
            if ( Membership.ValidateUser( name, password ) )
                var identity = new GenericIdentity( name );
                SetPrincipal( new GenericPrincipal( identity, null ) );
        catch ( FormatException )
            // Credentials were not formatted correctly.
            validated = false;
        return validated;
    private static void OnApplicationAuthenticateRequest( object sender, EventArgs e )
        var request = HttpContext.Current.Request;
        var user    = Thread.CurrentPrincipal;
        if ( !UrlAuthorizationModule.CheckUrlAccessForPrincipal( 
            request.Path, user, request.HttpMethod ) )
            var authHeader = request.Headers["Authorization"];
            if ( authHeader != null )
                var authHeaderVal = AuthenticationHeaderValue.Parse( authHeader );
                // RFC 2617 sec 1.2, "scheme" name is case-insensitive
                if ( authHeaderVal.Scheme.Equals( "basic",
                        StringComparison.OrdinalIgnoreCase ) &&
                    authHeaderVal.Parameter != null )
                    AuthenticateUser( authHeaderVal.Parameter );
    private static void OnApplicationEndRequest( object sender, EventArgs e )
        var response = HttpContext.Current.Response;
        if ( response.StatusCode == 401 )
            response.Headers.Add( "WWW-Authenticate",
                string.Format( "Basic realm=\"{0}\"", 
                    HttpContext.Current.Request.Url.Host ) );
    public void Dispose()
How to configure it?

There are two steps to configure the module. First, you register it for the processing pipeline:

    <modules runAllManagedModulesForAllRequests="true">
        <add name="BasicAuthModule" type="The.Namespace.Here.BasicAuthHttpModule"/>

The other important moment of the configuration is turning off all other 401 Challenge handling modules in the application configuration in IIS:

As you can see, the only active authentication method is “Anonymous” (Włączone = Enabled, Wyłączone = Disabled).

What happens if you don’t turn off other 401 Challenge handling methods? Well, the pipeline just uses them and since all built in modules tie 401 Challenge to Windows authentication, the custom membership provider will not even be fired as the windows authentication will most probably reject provided credentials.

What now

You can test the implementation with an http debugger to see how 401 is returned, what browser does when it sees the status code and what goes to the server with the next request.

The basic 401 Challenge authentication scheme is just one of possible 401 Challenge flows. Other possibilities are Digest, Ntlm are Negotiate flows. Google for more details.