Configuring IIS host header for a site with non-wild card SSL certificate

The "host name" is an important piece of configuration that must set when creating sites using IIS.

The “host name” can be set of a site in IIS v7.5 when a wild-card certificate (*.mysite.net) is used. See below:

Instead of a wild-card certificate, it is possible to obtain a certificate issued to a certain host name (env-live.mysite.net). At this point we do not have any other choice but set the host name for the site as “env-live.mysite.net” in IIS.

Now consider a scenario where a SSL certificate issued to “web-test-stage.domain.local” host name. It is possible that this certificate is installed in a server called “web-test-stage”. The IIS manager will not let you set the host name in this scenario. See below:

In the above screen capture, the SSL certificate is issued to “AcerUser-PC” which happens to be name of the computer. Once the site is created we can clearly see that the host name is not set.

The “TestSite” can now be accessed using the following methods:

•  https://AcerUser-PC or
•  https://IP Address of AcerUser computer 

Now, you might wonder is it worth worrying about this? I think this is something we should keep in mind.

The client accessing the web site must use the host name (I think). So, a user trying to access the site should not use the IP address. I think this make perfect sense in a case where multiple sites are hosted at the same IIS (IP address).

The way we can set the host name is through the command line. Open command prompt as an administrator and navigate to C:\Windows\System32\inetsrv folder.

Thereafter execute the following command. 

appcmd set site /site.name:TestSite /bindings.[protocol='https',bindingInformation='*:443:'].bindingInformation:*:443:AcerUser-PC

Return to IIS and refresh the site.

By selecting the “Edit Site Bindings” we can see that the host name header is set. But if we edit this property “host name” text box is disabled.

We must be very careful at this point. Do NOT click “OK” as it clears the host name.

I agree that the scenario I discussed here is pretty strange and you may never come across such a requirement. But we must keep in mind the best practises of IIS security which requires a host name for a site. 

To be honest, I am not very keen on implementing this in a production environment as it deviates from the standard IIS configuration (but its worth knowing...)

The .NET Sockets – The Investigation (1.1)!

One method I did not discuss in detail in the previous post (1) was “SetSocketOption”.

The “SetSocketOption” method is used to set certain characteristics of a socket. Let us look the following.

socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);

You can read more about the “SocketOptionLevel” enumeration here - http://msdn.microsoft.com/en-us/library/system.net.sockets.socketoptionlevel.aspx.

According to MSDN “SocketOptionName.ReuseAddress” “Allows the socket to be bound to an address that is already in use.” But what does this mean in practise...

When “Socket.Close” is called on a socket it goes into a “TIME_WAIT” state. We will discuss this in a later post.

Consider a case where the Server shuts down with a fatal exception. There is no guarantee that the socket has been closed gracefully. At this stage the socket will move into a “TIME_WAIT” state and remain in this state until the client is notified. Remember that TCP is a “reliable” communication protocol.

If we restart the Server, it will try to use the same port that it was using before. But this will fail because the socket is in a “TIME_WAIT” state. This is where “ReuseAddress” enumeration comes into play. By enabling address reuse, the Server can bind to the same endpoint it was using prior to the crash.

Resources:
http://meteatamel.wordpress.com/2010/12/01/socket-reuseaddress-property-and-linux/

The .NET Sockets – The Investigation (1)!

The Windows Socket programming has never been the favourite subject of many developers. Looking at the resources I can find, my guess is it is considered C/C++ topic.

Before going too deep into sockets, we should clarify what an endpoint is. Now an endpoint in the context of socket programming is an address and a port number. The combination of an address (e.g. 192.168.1.1) and a port (e.g. 8992) provides us a unique endpoint which a client can use for communication (e.g. 192.168.1.1:8992). 

Once the communication channel has been established between two endpoints each participant can send and receive data.

 The data received from a socket can be read synchronously or asynchronously. A simple search will return many hundreds of articles written about this subject. 

My goal of this post is to start very simply by creating a socket and build on it. We will then create a server followed by a client.

So let us create a socket. When creating “stuff” like sockets I tend to use a factory (pattern).

[Most importantly before writing any code, consider whether the code is testable. I am not going to use any IOC frameworks here, but make sure you consider using C# “interfaces” at least.]

Consider the following contract.

using System.Net.Sockets;
namespace Common
{
/// <summary>
/// Interface for creating a <see cref="System.Net.Sockets.Socket"/>.
/// </summary>
public interface ISocketFactory
{
  Socket Create();
 }
}

Now you would argue that since I am using a factory to create a socket, I could also use an “ISocket”. I considered that, but purpose of this post is to educate about the use of sockets. 

Let us implement this interface.

using System.Net.Sockets;
namespace Common
{
/// This class creates a socket.
public class SocketFactory : ISocketFactory
{
/// Creates a TCP/IP socket and sets its  to close immediately. 
public Socket Create()
{
            var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp
        {
                                 LingerState = new LingerOption(false, 0)
                             };
            socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
            return socket;
}
}
}

We have created a “TCP/IP” socket. One most important thing to remember is that there is already a “TCPClient” class which wraps a socket designed specifically for “TCP/IP” communication. I would prefer to use the above technique rather than the built-in “TCPClient”/related classes. Alternatively you can use “.NET Reflector” to check what is happening under the hood of “TCPClient” class.

The “AddressFamily” defines addressing scheme used by the socket. Since we are using “TCP/IP” socket, we should use “AddressFamily.InterNetwork”. The “SocketType” defines the type of socket (obviously...). We must use “Stream” here in order to adhere to “TCP/IP” standard.  And finally the protocol type, which in this case is “TCP”.

The next most important property you should be concerned is “Linger”. The idea behind setting the “Linger” option is to ensure that the socket is closed as soon as the “Socket.Close” method is called and the port is released.  Closing a socket gracefully is a subject on its own and you should read this entry - http://msdn.microsoft.com/en-us/library/windows/desktop/ms738547(v=vs.85).aspx. Make sure you visit this link as well - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4468997.

Ok, that will do for the moment. Let us visit the Server code next.

References:

C# Network Programming – Richard Blum

MSDN

http://msdn.microsoft.com/en-us/library/sb27wehh.aspx 

Hello!

I was using Wordpress, but was not going too well!..

Just moved!