Let’s look at each steps in detail. I have put some code as well to understand a little better how everything works in MVC.

Step 1: Routing

In ASP.NET application each asp.net page implements the IHTTPHandler interface.

This interface has a ProcessRequest() method that gets called when you request the page. The ProcessRequest() method is responsible for processing the request and generating the response. So in asp.net application it is simple, you request for a page in the url like https://mysite1\default.aspx and then it search for that page on the disk and execute the processrequest method and generate the response.

However in MVC application it doesn’t work in that way. There is no physical page exist for a particular request. All the requests are routed to a special class called Controller. The controller is responsible for generating the response and sending the content back to the browser.

When you build a MVC application you can define a bunch of controllers. Each controller can handle multiple requests. For example, all the following will route to same Controller.

https://mysite1/Controller1/1

https://mysite1/Controller1/2

https://mysite1/Controller1/3

These requests will execute the same Controller Controller1 and in that it will extract the id from the URL and process the request. This gives more readable URL then asp.net page.

So how these requests are routed to particular controller. Now the RouteTable come into the picture. Every ASP.NET MVC application has a RouteTable. This routetable is responsible to map the mvc requests to particular controller.

public class MvcApplication : System.Web.HttpApplication

{

public static void RegisterRoutes(RouteCollection routes)

{

routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.MapRoute(

"Default", // Route name

"{controller}/{action}/{id}", // URL with parameters

new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults

);

}

protected void Application_Start()

{

AreaRegistration.RegisterAllAreas();

RegisterRoutes(RouteTable.Routes);

}

}

}

Whenever the Application Start the Application_Start events will get called and it will call the method RegisterRoutes which will send the collection of Routes as the parameter and the routes will be added to this Collection which is a Dictionary of NamedMaps.

Each route also references a handler which will handle the rest of the request. When we use MapRoute, what we really do is creating a route by instantiating the 3 dictionaries and defining the default MVC handler: PageRouteHandler. Each RouteHandler implements an interface IRouteHandler.

protected override IView CreateView(ControllerContext controllerContext, 

                            string viewPath, string masterPath)

{

    return new WebFormView(viewPath, masterPath);

}

Why we need SSL

To encrypt Sensitive information

Just imagine, you are browsing a website which sends the data in un-encrypted format over the network. You entered your credit card details in the site. One hacker hacked into the network and gets the unencrypted information from the network and gets your credit card details. Result, you will lose money and you won’t even get to know what hit you.

The primary reason why SSL is used is to keep sensitive information sent across the network encrypted so that only the intended recipient can understand it. Since data will be in encrypted format so even if the hacker is able to get the data, he can’t decrypt the information so you are still safe.

Authentication

In addition to encryption, SSL also provides authentication. Imagine you created a website and your customer are trying to login to your website. In internet, the data is sent through series of computers so any of these computers can pretend to be your website. The malicious servers can trick your users to send the personal information to them.

Using SSL certificate, the Client and the Server can authenticate each other to make sure that they are sending data to the correct client or the server.

Digital Certificate

Digital certificates are the vehicle that SSL uses for public-key cryptography. Public-key cryptography uses two different cryptographic keys: a private key and a public key. Public-key cryptography is also known as asymmetric cryptography, because you can encrypt information with one key and decrypt it with the private key from a given public-private key pair.

Public-private key pairs are simply long strings of data that act as keys to a user's encryption scheme. The user keeps the private key in a secure place (in IIS it would be machine keys folder) and provides the public key to anyone with whom the user wants to communicate. The private key is used to digitally sign all secure communications sent from the user; the public key is used by the recipient to verify the sender's signature.

The private key is used to decrypt text that has been encrypted with the public key. Client sends a message to the server by encrypting it using the public key. Once the Server receives this message it can decrypt it using the private key. In addition to encrypting messages (which ensures privacy), Server can authenticate itself to the Client (so Client know that it is really the Server who sent the message) by using its private key to encrypt a digital certificate. When Client receives it, Client can use the public key to decrypt it.

A digital certificate serves two purposes: it establishes the owner's identity, and it makes the owner's public key available. A digital certificate is issued by a trusted authority--a certificate authority (CA)--and it is issued only for a limited time. When its expiration date passes, the digital certificate must be replaced.

Certificate authorities and trust hierarchies

Trust is a very important concept in digital certificates. Each organization or user must determine which CAs can be accepted as trustworthy.

A user of a security service requiring knowledge of a public key generally needs to obtain and validate a digital certificate containing the required public key. Receiving a digital certificate from a remote party does not give the receiver any assurance about the authenticity of the digital certificate. To verify that the digital certificate is authentic, the receiver needs the public key of the certificate authority that issued the digital certificate.

If the public key user does not already hold an assured copy of the public key of the certificate authority that signed the digital certificate, then the user might need an additional digital certificate to obtain that public key. In general, a chain of multiple digital certificates might be needed, comprising a digital certificate of the public key owner (the end entity) signed by one CA, and optionally one or more additional digital certificates of CAs signed by other CA.

SSL Handshake

1. The client sends a client "hello" message that lists the cryptographic capabilities of the client (sorted in client preference order), such as the version of SSL, the cipher suites supported by the client, and the data compression methods supported by the client. The message also contains a 28-byte random number.
2. The server responds with a server "hello" message that contains the cryptographic method (cipher suite) and the data compression method selected by the server, the session ID, and another random number.

Note:

The client and the server must support at least one common cipher suite, or else the handshake fails. The server generally chooses the strongest common cipher suite.

1. The server also sends its digital certificate.
2. If the server uses SSL V3, and if the application requires a digital certificate for client authentication, the server sends a "digital certificate request" message. In the "digital certificate request" message, the server sends a list of the types of digital certificates supported and the distinguished names of acceptable certificate authorities.
3. The server sends a server "hello done" message and waits for a client response.
4. Upon receipt of the server "hello done" message, the client (the Web browser) verifies the validity of the server's digital certificate and checks that the server's "hello" parameters are acceptable.
5. The client sends a "client key exchange" message. This message contains the pre-master secret, a 46-byte random number used in the generation of the symmetric encryption keys and the message authentication code (MAC) keys, encrypted with the public key of the server.

If the server requested a client digital certificate, the client sends a digital certificate, or if no suitable digital certificate is available, the client sends a "no digital certificate" alert. This alert is only a warning, but the server application can fail the session if client authentication is mandatory.

If the client sent a digital certificate to the server, the client sends a "digital certificate verify" message signed with the client's private key. By verifying the signature of this message, the server can explicitly verify the ownership of the client digital certificate.

Note:

An additional process to verify the server digital certificate is not necessary. If the server does not have the private key that belongs to the digital certificate, it cannot decrypt the pre-master secret and create the correct keys for the symmetric encryption algorithm, and the handshake fails.

1. The client uses a series of cryptographic operations to convert the pre-master secret into a master secret, from which all key material required for encryption and message authentication is derived. Then the client sends a "change cipher spec" message to make the server switch to the newly negotiated cipher suite. The next message sent by the client (the "finished" message) is the first message encrypted with this cipher method and keys.
2. The server responds with a "change cipher spec" and a "finished" message of its own.
3. The SSL handshake ends, and encrypted application data can be sent.

SSL in IIS6

1. After the TCP handshake and SSL handshake, The HTTP requests in the encrypted form reach to the HTTP.SYS layer.

2. The Kernel mode HTTP.SYS driver doesn’t know how to decrypt the request.

3. Kernel driver uses the service called HTTP SSL Service to do the operation. This service runs under Lsass.exe and this service runs under the user mode.

4. The HTTP Protocol stack receives the request from the client and then it will place it in the SSL Queue.

5. There is a filter called HTTPFilter in the HTTP SSL Service which keeps listening to the SSL Queue. As soon as the request comes, it will pick it up for processing.

6. HTTP Filter checks the IP-Address and port from the request. Get the Certificate from the SSL Binding info based on the IP-Address and port, decrypt the request and then send the decrypted request to the HTTP.SYS Layer.

7. After decryption of the request HTTP.SYS knows about the IP-Address, port and the host-header so it will put the request accordingly in the correct worker process request queue. From where w3wp.exe picks it up and work on it.

8. After processing w3wp.exe sends the response to the HTTP.SYS layer. HTTP.SYS layer again put the response into the SSL Queue.

9. HTTPFilter again picks up the request from the SSL Queue, get the certificate and then encrypt the request using the private key and then send the encrypted request to the HTTP.SYS.

10. HTTP.SYS then send this encrypted request to the Client.

SSL in IIS7

HTTPSSL Service is in UserMode and HTTP.Sys is in Kernel mode. As mentioned above, the IIS6 process of SSL encryption and decryption require lot of context switching between the User mode and the Kernel mode and thus reduce the performance. You can enable the Kernel mode SSL in IIS6 using the registry key as mentioned in the following article

https://technet.microsoft.com/en-in/library/dd441380%28v=office.13%29.aspx

In IIS7, The SSL is done by default at the Kernel level at HTTP.SYS layer. So it improves the performance.

In IIS7, instead of using HTTPFilter SSL uses Schannel driver in the Kernel mode itself for the encryption and decryption of the request.

IIS6 SSL request/response flow

IIS7 SSL request/response flow

This new design of how SSL processing is done inside kernel mode increases performance on IIS7.

Server Authentication

SSL by itself does not guarantee that the client is communicating with the correct server.

  To illustrate the risks involved with this protocol, consider the following scenario. There are two servers,Server1 (myserver1.com) and Server2 (myserver2.com), and one client, Client (IE). Both servers have valid certificates from a CA that the client trusts. Client wants a secure session with Server1, but Server2 wants to eavesdrop on their communication, and is physically located in such a place that it can do so. The scenario goes as follows:

1. Client sends a request for an SSL session to Server1. The request (and all subsequent traffic) actually goes through Server2. Instead of forwarding Client's request to Server1, Server2 responds directly to the request by sending its own certificate to Client.

2. Client receives Server2's certificate and checks its list of trusted CAs. Since Server2's certificate is signed by the same CA as Server1's certificate, Client accepts the certificate and creates a secure session with Server2.

3. Having completed the secure session with Client, Server2 requests and creates its own SSL session with Server1. From this point, Client sends encrypted information to Server2. Server2 decrypts the information, re-encrypts it, and then sends it to Server1. It does the same for information flowing in the opposite direction. The result is that, although all data is encrypted when it flows over the Internet, Server2 is able to read it, and even change it.

4.

To avoid the above danger, there is something called Server authentication. Server Authentication is a mechanism by which a Client authenticate the server so that Client will get to know if it is talking to the correct server or not. To authenticate the server one condition has to match that the common name in the server's certificate must match its Internet name.

After Enabling Server Authentication the above scenario goes now like this

1. Client sends a request for an SSL session to Server1. The request (and all subsequent traffic) actually goes through Server2. Instead of forwarding Client's request to Server1, Server2 responds directly to Client's request by sending its own certificate to Client.

2. Client receives Server2's certificate and checks its list of trusted CAs. Since Server2's certificate is signed by the same CA as Server1's certificate, Client accepts the certificate and creates a secure session with Server2.

3. After the secure session has been completed, but before any real data has been sent or received, Client compares the Internet name in the certificate it received (myserver2.com) with the name of the server it wants to talk to (myserver1.com). Since they do not match, Client knows that the connection should not continue and disconnects it.

To know how client authenticate the server please follow the link

https://support.microsoft.com/kb/257587

Until IIS 7.5, the major limitation of IIS is that IIS will allow you to bind only one site for one IP: Port combination using an SSL certificate.  If you try to bind a second site on the IP address to the same certificate, IIS will give you an error when starting the site up stating that there is a conflict. In order to assign a certificate to be used by multiple IIS sites on the same IP address and port, we need to use a special mechanism. Before we go there let’s understand why it is not possible for IIS to allow the binding of multiple sites on same IP: Port combination using an SSL certificate.

Classic Chicken and Egg Problem

We know that IIS identifies a site using three piece of data:

1. IP-Address

2. Port

3. Host Header

You can have multiple HTTP site configured with different combination of above. The binding, for example 192.168.1.0:80 can be configured to site “MyServer1.com”. That means if I browse to IP-address 192.168.1.0 over port 80 then I will hit the site “MyServer1.com”. I can have the binding as 192.168.1.0:80:myserver2.com configured for site “MyServer2.com”. That means when I browse the site over IP-address 192.168.1.0 over port 80 with a host header as “myserver2.com” then I will hit the site MyServer2.com. This allows multiple DNS hostnames on a single server at the same IP address.

However this doesn’t work in HTTPS. To know why it doesn’t work in HTTPS lets understand the SSL handshake briefly.

1. Client - > (SSL Handshake) - > “ Hello, I support XYZ algorithm for encryption”

2. Server -> (SSL Handshake) -> “Hi there, Okay so here is my public certificate. Let’s use algorithm X”

3. Client -> (SSL Handshake)-> “Great we can use that”

4. Client -> (In Encrypted format)-> “HTTP Request”

5. Server -> (In Encrypted format)-> “HTTP Response”

<And now cycle continues>

Now let’s say hypothetically, you have set two sites on same IP-address and port and different host headers and you set two different certificates on both of them.

Look at the steps in SSL Handshake, Client sends the HTTP Request only in Step 4. That means Server doesn’t know what host header HTTP request is referring to until step 4. So at Step 2, Server has only IP-Address and Port information with it, so how can server figure out which certificate it needs to send to the Client as you have bind two certificates to same IP-Address and port.

When a request comes to HTTP.SYS layer, the HTTP.SYS reads the site configuration, including the certificate used to encrypt/decrypt the data. The host name is encrypted in SSL Blob that the client sends. However, IIS needs to know the host name in order to get the right certificate. Without the host name IIS cannot get to the correct site. As IIS is not able to get to the correct site so it cannot get the right certificate to decrypt the SSL blob to get the host name. This is the classic Chicken and Egg problem. We are turning into circles with no way out.

This is the precise reason; HTTP server can only allow one site per IP-Address: Port combination for HTTPS browsing. If you need to bind another site over HTTPS then you need to get either a different IP-Address or bind the site to a different port.

Sometimes getting a new IP-Address or port for each website becomes costly affair. So how we can attach two website to HTTPS over same IP: Port. There are two ways to do it in IIS7.

Wild Card Certificate.

A wildcard certificate can secure an unlimited number of first level sub domains on a single domain name. For example, you can get a certificate which is issued to *.mydomain.com. This certificate will secure www.mydomain.com, secure.mydomain.com, welcome.mydomain.com etc. Basically it will work on any subdomain that replaces the wildcard character (*).

Setting up the Wild Card Certificate

Step 1: Install the wildcard certificate.

Verify if the certificate is properly installed.

1. Select Start –> Run

2. Type in “MMC” and hit enter

3. From the console, select File –> Add / Remove Snap-in

4. Select Certificates from the Add / Remove dialog

5. Select Computer Account when prompt for which certificates the snap-in will manager.

6. Select Local Computer when prompted

7. Click OK to add the Snap-in to the MMC

8. Locate your SSL certificate

9. Right click on the certificate and select properties

10. You should see the * in the friendly name.

Once you have installed the certificate then the issued to should be the *.mydomain.com

Step 2: Setup the wildcard certificate in IIS

Let’s say you need following configuration

So let's say you have the following configuration:

Website                   Host Header Value                  IP Address      Port             SSL Port
==================================================================
Test1                         www.myserver.com              10.0.1.1              80                  443
Test2                        test2.myserver.com               10.0.1.1              80                  443

Test3                        test3.myserver.com                10.0.1.1             80                  443

IIS6

You need to select the certificate for all the three sites which are configured for same IP-Address and port.

To know how to bind the certificates in IIS6 please follow the following link

https://blogs.iis.net/robert_mcmurray/archive/2011/02/17/iis-6-setting-up-ssl-part-3-installing-the-certificate.aspx

After you installed the Certificate on all the websites with same IP address and port and you try to browse the sites. You will see that all of the HTTPS responses come from one specific site.

That means if you try to access https://test1.myserver.com, https://test2.myserver.com or https://test3.myserver.com you will get the response from one site only.

You won't get the corresponding pages from different Websites depending upon the site in URL. Why? Because of the chicken and Egg problem remember. When the request comes to HTTP.SYS layer then Schannel will be able to decrypt the request but after decrypting the request it doesn’t know which site it needs to send the request as all the sites listening to same IP-Address and port.

You will also see that only one of the Websites will be running. Other Websites will be in stopped state because we cannot have multiple Websites running with same IP and same SSL port binding. If you try to start the other Websites you may see something like this below:

How to resolve above issue

To resolve this issue we need to add host headers to the sites.

Go to Start Menu, click Run, type "cmd", and then click OK.

Type the following command at the command prompt:

C:\Inetpub\AdminScripts>cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings "*:443 :< host header>"

For example

C:\Inetpub\AdminScripts>cscript.exe adsutil.vbs set /w3svc/1/SecureBindings "10.0.0.1:443:test1.myserver.com"

Do this for all the three sites

C:\Inetpub\AdminScripts>cscript.exe adsutil.vbs set /w3svc/2/SecureBindings "10.0.0.1:443:test2.myserver.com"

C:\Inetpub\AdminScripts>cscript.exe adsutil.vbs set /w3svc/3/SecureBindings "10.0.0.1:443:test3.myserver.com"

You can also change this by changing the metabase.xml for that particular site.

For Example your site id is 1 then you would see following in the Metabase.xml

<IIsWebServer Location ="/LM/W3SVC/1"

AuthFlags="0"

SSLCertHash="ee6c56aaacd9e52137ccd4563131c35bdb020712"

SSLStoreName="MY"

SecureBindings=":443:"

ServerAutoStart="TRUE"

ServerBindings=":80:"

ServerComment="ssltest">

Add the hostname in the SecureBindings explicitly for each site.

<IIsWebServer Location ="/LM/W3SVC/1"

AuthFlags="0"

SSLCertHash="ee6c56aaacd9e52137ccd4563131c35bdb020712"

SSLStoreName="MY"

SecureBindings=":443:www.test.com"

ServerAutoStart="TRUE"

ServerBindings=":80:"

ServerComment="ssltest">

IIS7

In IIS7, attaching a wild card certificate is much easier. You can attach the certificate to the website you need to attach to. The moment you select the wildcard certificate the hostname field in the UI will be enabled. You can type the host header in it. You can do the same procedure for multiple sites.

How Wild Card Certificate resolve the Chicken and Egg problem

We have multiple sites on same IP: Port with the same certificate (wildcard certificate) attached to them. When the request reach to HTTP.SYS layer, the Schannel gets the IP: Port information from the request. Since there is only one certificate attached to that IP: Port Schannel use that wildcard certificate and decrypt the request using the private key. After decrypting the request, HTTP.SYS is able to get the host header information. Using the host header, HTTP.SYS can put the request into the proper request queue.

Limitation of Wild Card Certificate.

There are certain limitations of wild card certificate.

1) It can only be applicable to single level of subdomain. For example you got a wild cart certificate for *.mydomain.com then you can bind this certificate to sites such as site1.mydomain.com or site2.mydomain.com. However, you cannot bind the wildcard certificate to Site1.myexample.mydomain.com or Site1.example2.mydomain.com or xyz.abc.mydomain.com etc.

That means the wild cart certificate will work only till first level of subdomain.

2) The wild card certificate will work only if the site has same domain name. That means if you have certificate for *.mydomain.com then you cannot bind this certificate to sites such as www.example.com or www.mydomain2.com etc. Wild card certificate will work only for sites which have same domain name.

3) You can set the wildcard certificate only for one top level domain. For example you can bind a wild card certificate for www.test1.myserver.com or www.test2.myserver.com, but you cannot bind the same certificate for hostheader www.test2.myserver.org or www.test2.myserver.net etc.

SAN Certificate (Subject Alternative Name Certificate)

You can setup the wildcard certificate if the domain name for all the sites are same and first level subdomain changes. What if you want to set up the sites which should work on two different domain names, for example, a site with host header as www.testserver1.com and another site with hostheader as www.testserver2.com. In this case Wildcard certificate won’t help you. To resolve this issue we have SAN Certificate.

A SAN cert allows for multiple domain names to be protected with a single certificate. For example, you could get a certificate for myserver.com, and then add more SAN values to have the same certificate protect myserver.org, myserver.net and even myserver2.com or www.example.com.

You can see the domain names in the Subject Alternative Name option in the Certificate

Setup the SAN certificate in IIS

Let’s say you need following configuration

So let's say you have the following configuration:

Website                   Host Header Value                  IP Address      Port             SSL Port
==================================================================
Test1                         www.test.edu               10.0.1.1              80                  443
Test2                        www.test.com               10.0.1.1              80                  443

Test3                    www.test.testing.com 10.0.1.1             80                  443

IIS 6

You need to select the SAN certificate for all the three sites which are configured for same IP-Address and port.

Note: The hostheaders which are defined in the Subject Alternative Name, only to those hostheaders you can bind the site. That means if you set the Subject Alternative Name to www.test.edu, www.test.com, www.test.testing.com then you cannot bind this certificate to a site with hostheader say www.example.com.

To know how to bind the certificates please follow the following link

https://blogs.iis.net/robert_mcmurray/archive/2011/02/17/iis-6-setting-up-ssl-part-3-installing-the-certificate.aspx

After you installed the Certificate on all the websites with same IP address and port and you try to browse the sites. You will see that all of the HTTPS responses come from one specific site.

That means if you try to access https:// www.test.edu, https://www.test.com or https://www.test.testing.com you will get the response from one site only.

You won't get the corresponding pages from different Websites depending upon the site in URL. Why? Because of the chicken and Egg problem remember. When the request comes to HTTP.SYS layer then Schannel will be able to decrypt the request but after decrypting the request it doesn’t know which site it needs to send the request as all the sites listening to same IP-Address and port.

You will also see that only one of the Websites will be running. Other Websites will be in stopped state because we cannot have multiple Websites running with same IP and same SSL port binding. If you try to start the other Websites you may see something like this below:

How to resolve above issue

To resolve this issue we need to add host headers to the sites.

Go to Start Menu, click Run, type "cmd", and then click OK.

Type the following command at the command prompt:

C:\Inetpub\AdminScripts>cscript.exe adsutil.vbs set /w3svc/<site identifier>/SecureBindings "*:443 :< host header>"

For example

C:\Inetpub\AdminScripts>cscript.exe adsutil.vbs set /w3svc/1/SecureBindings "10.0.0.1:443:www.test.edu"

Do this for all the three sites

C:\Inetpub\AdminScripts>cscript.exe adsutil.vbs set /w3svc/2/SecureBindings "10.0.0.1:443:www.test.com"

C:\Inetpub\AdminScripts>cscript.exe adsutil.vbs set /w3svc/3/SecureBindings "10.0.0.1:443:www.test.testing.com"

You can also change this by changing the metabase.xml for that particular site

<IIsWebServer Location ="/LM/W3SVC/1"

AuthFlags="0"

SSLCertHash="ee6c56aaacd9e52137ccd4563131c35bdb020712"

SSLStoreName="MY"

SecureBindings=":443:"

ServerAutoStart="TRUE"

ServerBindings=":80:"

ServerComment="ssltest">

Add the hostname in the SecureBindings explicitly for each site.

<IIsWebServer Location ="/LM/W3SVC/1"

AuthFlags="0"

SSLCertHash="ee6c56aaacd9e52137ccd4563131c35bdb020712"

SSLStoreName="MY"

SecureBindings=":443:www.test.com"

ServerAutoStart="TRUE"

ServerBindings=":80:"

ServerComment="ssltest">

IIS7

You need to select the certificate for all the three sites which are configured for same IP-Address and port.

Note: The hostheaders which are defined in the Subject Alternative Name, only to those hostheaders you can bind the site. That means if you set the Subject Alternative Name to www.test.edu, www.test.com, www.test.testing.com then you cannot bind this certificate to a site with hostheader say www.example.com.

To know how to bind the certificates in IIS7 please follow the following link

https://www.iis.net/learn/manage/configuring-security/how-to-set-up-ssl-on-iis

To configure the SAN certificate you need to run the below command after changing the website name, ip-address and port and the host header value.

Go to Start Menu, click Run, type "cmd", and then click OK.

Go to the location “C:\Windows\System32\inetsrv”

Type the following command at the command prompt:

appcmd set site /site.name:”<WEBSiteName>” /+bindings.[protocol='https',bindingInformation='*:443:<hostHeaderValue>']

For example

appcmd set site /site.name:"Test1" /+bindings.[protocol='https',bindingInformation='*:443:www.test.edu’]

appcmd set site /site.name:"Test2" /+bindings.[protocol='https',bindingInformation='*:443:www.test.com’]

appcmd set site /site.name:"Test3" /+bindings.[protocol='https',bindingInformation='*:443:www.test.testing.com’]

Alternatively you can go to the applicationhost.config and modify the binding part of the website to add the host header. Do this for all the three sites. For example

<site name="TestSite" id="2" >

<application path="/" applicationPool="TestSite">

<virtualDirectory path="/" physicalPath="C:\Publish" />

</application>

<bindings>

<binding protocol="http" bindingInformation="*:8089:TestSite" />

<binding protocol="https" bindingInformation="*:443:TestSite" />

</bindings>

</site>

How SAN Certificate resolve the Chicken and Egg problem

We have multiple sites on same IP: Port with the same certificate (SAN certificate) attached to them. When the request reach to HTTP.SYS layer, the Schannel gets the IP: Port information from the request. Since there is only one certificate attached to that IP: Port Schannel use that SAN certificate and decrypt the request using the private key. After decrypting the request, HTTP.SYS is able to get the host header information. Using the host header, HTTP.SYS can put the request into the proper request queue.

Limitation of SAN Certificate.

There are certain limitations of SAN certificate.

1) One major limitation of SAN certificate is if you have issued the SAN certificate for say two host-headers www.test1.com and www.test2.edu but you need to setup a site for www.test3.net using the same certificate then you can’t use it. You need to get another SAN certificate from the CA with all the three host-headers. In short, for every addition of a host-header you need to get another SAN certificate.

2) There are certain limitations which are defined by the CA on the number of host-header you can add to the Certificate. That means, after a certain number of host-header you cannot add further host-header into it.

Server Name Indication in IIS8

IIS8 has a new functionality called Server Name Indication (SNI) to overcome this problem. To know more about SNI please follow the following links

https://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-server-name-indication-sni-ssl-scalability

https://blogs.msdn.com/b/kaushal/archive/2012/09/04/server-name-indication-sni-in-iis-8-windows-server-2012.aspx

In windows server 2003 server we can create our own custom certificate trust list using the UI in IIS to bind the CTL to the SSL certificate.

To check how we can add the custom CTL in IIS6 please follow the following link

https://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/6e8034d4-c5fc-4b98-a9de-44075de5a589.mspx?mfr=true

However, the same UI is not provided in IIS7.5. To add the custom CTL in IIS7.5 we need to perform following steps

Create Custom CTL

We need to create a custom CTL. We can do it using MakeCTL.exe. However, MakeCTL.exe doesn’t work in Windows Server 2008 R2. So, we need a Windows Server 2003 or Windows Server 2008 (non R2) server to do it.

Step 1: Install MakeCTL.exe.

To install MakeCTL.exe you need to install Windows server 2003 SDK (https://www.microsoft.com/en-us/download/details.aspx?id=15656) or .net framework 1.1 SDK.

Step 2: Run MakeCTL.exe as an administrator

Step 3: Click Next on the “Welcome to the Certificate Trust List Wizard”

Step 4: In Certificate Trust List Purpose screen, provide a Prefix for this CTL.  This will work as the friendly name for the CTL. Provide a simpler name for this as whenever you want to attach the CTL to the certificate you need to provide this name. I have given the name as CTLTest.

Step 5: Click on the Add purpose.

Step 6: In the User Defined Purpose box, add the following in the Object ID field and click OK:    1.3.6.1.4.1.311.10.1. Make sure you don’t add any space before or after this value.

Why we need to provide 1.3.6.1.4.1.311.10.1.

As per the article https://support.microsoft.com/kb/287547 1.3.6.1.4.1.311.10.1 object Id belongs to Certificate Trust List (CTL).

Step 7: Check whether 1.3.6.1.4.1.311.10.1 has been added to the list of purposes and has a checkmark on it. If yes, click next.

Step 8: Select the “Add from Store” button on the Certificates in the CTL window.

Step 9: In the Select Certificate window, select the certificate of the Trusted Root CAs that you need to configure your CTL for.

Step 10: In the Certificate Trust List Storage window, select File and click the Browse button.

Step 11: Save the File as .stl format.

Step 12: Click the Next button and see the CTL information in the window to verify

Step 13. Click on Finish and it will show a message as “The Certificate Trust List wizard was succeeded”.

Step 14: Copy this STL file manually to the Windows Server 2008 R2 server.

Import the CTL in certificate mmc

Step 1: Click on Intermediate Certification Authorities and Click on Import

Step 2: Click on Next in the Certificate Import Wizard.

Step 3: Click on Browse and select the stl file.

Step 4: Keep “Place all certificates in the following store” as “Intermediate Certificate authorities”. Click on Next.

Step 5: Check the information before the finish. If everything is correct click on finish.

Step 6: You will get the message as “The import was successful”.

Add CTL to the certificate

Step 1: Launch a command prompt in Administrator mode.

Step 2: Type the command as netsh http show sslcert.

This will show all the ssl bindings you have on your server. You should recognize which IP and Port combination you need to use. For example I am using IP:Port as 0.0.0.0:443.

IP:port : 0.0.0.0:443

Certificate Hash : 6471dc4d170d6aa6fc80511243a30bb3d97d306c

Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}

Certificate Store Name: MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time: 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Please note down the Certhash value and the appId. We need to use them later.

Note: CTL Identifier and CTL Store Name are both null.   We need to change it to begin using the CTL.

But to change it we have to delete this binding and add it again with the specified information.

Step 3: Type the command as netsh http delete sslcert ipport=0.0.0.0:443. You will receive the command as “SSL Certificate successfully deleted”

Step 4: Now add the certificate with the CTL information. Type the command as

netsh http add sslcert ipport=0.0.0.0:443 certhash=15e3063e10e3d50127d323d8b6827ddd7ae33936 appid={4dc3e181-e14b-4a21-b022-59fc669b0914} sslctlidentifier=TestCTLs sslctlstorename=CA

Note: You need to change the Ip:Port ,Certhash,appId and sslCtlidentifier as per your settings. Refer the values you note down in Step 2.  Your sslctlidentifier value is going to be the friendly name of your CTL.  Remember, that the friendly name must be spelled perfectly and with case sensitivity.  Sslctlstorename simply needs to be CA.

If you get the message as

“SSL Certificate add failed, Error: 1312 A specified logon session does not exist. It may already have been terminated”

First thing you need to check if you are putting the correct name in the sslctlidentifier.

If everything is right then you may need to install following hotfix (If you don’t have Windows Server 2008 R2 SP1).

https://support.microsoft.com/default.aspx?scid=kb;EN-US;981506

After installing the hotfix the certificate will be added.

Step 5: You can now check certificate again using the command netsh http show sslcert. It will be shown as below.

IP:port : 0.0.0.0:443

Certificate Hash : 6471dc4d170d6aa6fc80511243a30bb3d97d306c

Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}

Certificate Store Name : (null)

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time: 0

URL Retrieval Timeout : 0

Ctl Identifier : CTLTest

Ctl Store Name : CA

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

CTL is not honored in initial SSL handshake

One would assume that Certificate Trust List (CTL) will limit the list of Trusted Certificate Authorities (CA's) being sent to the client during the initial SSL handshake. However, IIS 6.0/7.0 using CTL's you cannot limit the list of CA's sent back to the client during the SSL/TLS handshake. That means you can't use CTL's to limit the list of certificates that Internet Explorer is showing. IE will show all the certificates irrespective of whether the issuing CA is a part of the CTL or not. For more information follow the following link

https://blogs.msdn.com/b/saurabh_singh/archive/2007/12/07/certificate-trust-list-not-being-honored-by-iis-5-0-6-0-7-0.aspx

Though if you select a certificate whose CA is not a part of the CTL then you will get the error as 403.16: Client Certificate is untrusted or invalid.

Hope this blog helps you.

• Server - Specifies web server version.
• X-Powered-By - Indicates that the website is "powered by ASP.NET."
• X-AspNet-Version - Specifies the version of ASP.NET used.

Before you go any further, you should evaluate whether or not you need to remove these headers. If you have decided to remove these headers because of a security scan on your site, you may want to read the following blog post by David Wang.

https://blogs.msdn.com/b/david.wang/archive/2006/03/29/silly-security-scans.aspx

If you would like to go ahead and remove the headers then follow the following options.

Server Header

There are three ways to remove the Server header from the response. The best one is to use the third option.

1. Using the Registry key.

Create a DWORD entry called DisableServerHeader in the following Registry key and set the value to 1.

HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

After adding the Registry key, restart the HTTP service using the net stop http command and the net start http command. If the HTTP service doesn’t start up then use the iisreset command. If that also doesn’t work then you can restart the server.

Please note that this method is used only when the Server header comes as “Microsoft-HTTPAPI/2.0”.

When the request comes to IIS, it is first goes to http.sys driver. HTTP.SYS driver either handle the request on its own or send it to User mode for further processing. When the request goes to User mode that’s the time it returns the server header as “Microsoft-IIS/7.5.”.

However when the request returns from the HTTP.SYS driver then the server header comes as “Microsoft-HTTPAPI/2.0”. By placing the above registry key it will remove this specific header

If you would like to remove the Server header as “Microsoft-IIS/7.5.”, then follow the following methods.

2. Using the URLScan tool.

Install the URLScan in your machine. Please follow the following link for that

https://www.iis.net/downloads/microsoft/urlscan

After installing URLScan, open the URLScan.ini file typically located in the %WINDIR%\System32\Inetsrv\URLscan folder. After opening it, search for the key RemoveServerHeader . By default it is set to 0, but to remove the Server header, change the value to 1.Doing so will remove the Server header Server: Microsoft-IIS/7.5 from the User mode response.

Please note that changes made by URLScan at global level apply to all of your sites. If you would like to setup this for particular site then look at the following article (site filter section)

https://www.iis.net/learn/extensions/working-with-urlscan/urlscan-setup

There are also some pitfalls to using URLScan. You can learn about those pitfalls at the following URL:

https://msdn.microsoft.com/en-us/library/ff648552.aspx#ht_urlscan_008

3. Using URLRewrite

If you don’t want to go with URLScan, you can use the URLRewrite module to remove the value of the Server header. Please note that it will not remove the header all together but it will remove the value of it.

Step 1. Install URLRewrite. To install the URLRewrite please go to the following link

https://www.iis.net/downloads/microsoft/url-rewrite

Step 2. Open the site on which you would like to remove the Server header and click on the URLRewrite section.

Step 4. Click on the “View Server Variables” in the Actions pane in the right hand side.

Step 5. Click on the Add button and then enter “RESPONSE_SERVER” in the textbox provided.

Step 6. Now we need to create an outbound rule. To know how to create an outbound rule, look at the following link

https://www.iis.net/learn/extensions/url-rewrite-module/creating-outbound-rules-for-url-rewrite-module

Step 7. Create an Outbound rule as the following.

Please note that this is a website-specific rule. If you want to create the rule for all of your applications, create the rule at the server level. Also, some applications, especially third party applications, may require the Server header, so you may need to remove this rule for those applications.

X-Powered-By

There are two ways to do remove this header as well. Second method would be the preferred one.

1. Using IIS HTTP Response headers.

Open the site which you would like to open and then click on the HTTP Response Headers option.

Click on the X-Powered-By header and then click Remove on the Actions Pane to remove it from the response.

2. Using URLRewite Rule.

Please note that it will not remove the header all together but it will remove the value of it.

Step 1. Install URLRewrite. To install the URLRewrite please go to the following link

https://www.iis.net/downloads/microsoft/url-rewrite

Step 2. Open the site on which you would like to remove the X-Powered-By header and Click on the URLRewrite section.

Step 3. Click on the “View Server Variables” in the Actions pane in the right hand side.

Step 4. Click on the Add button and then enter “RESPONSE_X-POWERED-BY” in the textbox provided.

Step 5. Now we need to create an outbound rule. To know how to create an outbound rule, look at the following link

https://www.iis.net/learn/extensions/url-rewrite-module/creating-outbound-rules-for-url-rewrite-module

Step 6. Create an Outbound rule as the following

Please note that this is a website-specific rule. If you want to create the rule for all of your applications, create the rule at the server level. Also, some applications, especially third party applications, may require the x-powered-by header, so you may need to remove this rule for those applications.

X-AspNet-Version

There are two ways to do remove this header as well. Preferred one is the first one.

1. Using the httpRuntime element.

Add the following line in your web.config in the <system. Web> section

<httpRuntime enableVersionHeader="false" />

2. Using an URLRewite rule.

Please note that it will not remove the header all together but it will remove the value of it.

Step 1. Install URLRewrite. To install the URLRewrite please go to the following link

https://www.iis.net/downloads/microsoft/url-rewrite

Step 2. Open the site on which you would like to remove the Server header and go to the URLRewrite section.

Step 3. Click on the “View Server Variables” in the Actions pane in the right hand side.

Step 4. Click on the Add button and then enter “RESPONSE_X-ASPNET-VERSION” in the textbox provided.

Step 5. Now we need to create an outbound rule. To know how to create an outbound rule, look at the following link

https://www.iis.net/learn/extensions/url-rewrite-module/creating-outbound-rules-for-url-rewrite-module

Step 6. Create an Outbound rule as the following.

Please note that this is a website-specific rule. If you want to create the rule for all of your applications, create the rule at the server level. Also, some applications, especially third party applications, may require the x-aspnet-version header, so you may need to remove this rule for those applications.