Today I will be discussing the very infamous error that is seen while adding a SSL binding in IIS 7 & higher. Below is a snapshot of the error message while trying to add the SSL binding in IIS.

Well, the error is definitely not descriptive enough, neither does it provide any vital information to troubleshoot the issue. However, if you look at the Event logs, you will find the clue and the reason why the error is seen.

The event logs should give you some clue regarding the problem. The primary reason for the above error is the problem in accessing the “Private Key” of the certificate due to a broken keyset.

For those who may not be following, Public Key Cryptography deals with “Public Key” & “Private Key”. The Public key is distributed to the clients, while only the Server has access to the Private key as it is used for decrypting the SSL Request. So “Private Key” is of utmost importance here.

There are few scenarios where we could see a problem accessing the “Private Key” of the SSL Cert. I will discuss a few in this article:

SCENARIO 1

The most common scenario is when the users use the IIS MMC to import a certificate and they uncheck the option “Allow this certificate to be exported”. This results in a broken keyset and thus results in the problem.

Solution:

There are 2 ways to fix this problem. Before we start off, delete/remove the existing certificate from the store.

1. If using IIS MMC to import the certificate, then ensure that the “Allow this certificate to be exported” is checked.
2. If making the private key exportable is not an option, then use the Certificates MMC to import the certificate. Please go through the following KB on how to import a certificate using the MMC: http://support.microsoft.com/kb/232137

SCENARIO 2

Another reason which can result in a broken keyset is due to missing permissions on the MachineKeys folder. This is the location where all the private keys are stored. The folder path (IIS 7 & higher) is as shown below: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

The default permissions on this folder are described in the following articles:

http://support.microsoft.com/kb/278381

http://msdn.microsoft.com/en-us/library/ee248638(v=vs.100).aspx

Solution:

Firstly, delete/remove the broken certificate from the store. Ensure the permissions are as per the articles mentioned above. So we need to permissions to the Administrators and Everyone account. Do remember to select the

After giving the necessary permissions, re-import the certificate as described in SCENARIO 1.

SCENARIO 3

There is another possibility, that the issue might occur even after ensuring the both mentioned above. I have observed this behavior typically on Windows Server 2008. This depends on the KeySpec property of the certificate.

The KeySpec property specifies whether the private key can be used for encryption, or signing, or both.

The following MSDN article describes KeySpec property:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379020%28v=vs.85%29.aspx

In order to examine the KeySpec property of the certificate, use the following command:

NOTE: In the above command the thumbprint information can be found in the details tab of the certificate. The following are valid commands:

certutil -v -store my "32 b5 39 8e d3 c9 c6 f1 a3 50 bc d4 b5 14 eb b5 a4 5d 1f c6"

certutil -v -store my "32b5398ed3c9c6f1a350bcd4b514ebb5a45d1fc6"

certutil -v -store my 32b5398ed3c9c6f1a350bcd4b514ebb5a45d1fc6

Get the output of the above command in a notepad and then search for KeySpec, which is part of the CERT_KEY_PROV_INFO_PROP_ID section. The KeySpec is represented as a hexadecimal value.

As described above it can take three values:

So the issue is seen if the KeySpec value is set to anything other than 1. The issue is more likely to be occur when the CSR is generated using a custom template and the KeySpec is not specified.

Whenever the KeySpec attribute is not explicitly specified, it takes the default value of 2 i.e., it can be used for signing purposes only.

Solution:

So one thing that you need to remember is that the KeySpec attribute has to be specified explicitly.

1. If you are generating a certificate via the code, then ensure you are explicitly setting the KeySpec attribute to 1.
2. If using certreq.exe utility along with an inf file to submit a request to SAN, ensure that you explicitly specify the KeySpec attribute to be 1.

• Refer the following article for this: http://support.microsoft.com/kb/931351

For further read on KeyUsage refer the below 2 links:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379021%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379417%28v=vs.85%29.aspx

Configuring and Troubleshooting Certificate Services Client–Credential Roaming: http://technet.microsoft.com/en-us/library/dd277392.aspx

How to create a certificate request with CertEnroll (JavaScript): http://blogs.msdn.com/b/alejacma/archive/2009/01/28/how-to-create-a-certificate-request-with-certenroll-javascript.aspx

Generating a certificate (self-signed) using PowerShell and CertEnroll interfaces: http://blogs.technet.com/b/vishalagarwal/archive/2009/08/22/generating-a-certificate-self-signed-using-powershell-and-certenroll-interfaces.aspx

Hope this helps.

In my previous posts on IIS 8, I discussed how scalability was  achieved in IIS 8 via SNI.

Below are the links to previous posts:

                  ·         SSL Scalability with IIS 8

                  ·         SNI with IIS 8

In the first post I mentioned that scalability was achieved in IIS via Server Name Indication (SNI) and Central Certificate Store (CCS). In my second post linked above I discussed how scalability was achieved via SNI.

In this article I’ll discuss CCS in detail and also its functionality.

What is CCS?

Central Certificate Store or Centralized SSL Certificate Support is a feature which allows certificates to be stored on a central location like a file share. This feature is very similar to Shared Configuration, where the certificates are stored on a file share and the servers in farm load them on demand.

In CCS the files are exported along with the private key (in .pfx format) and stored centrally on a file share. Files are named specifically using a naming convention and stored in the file share which are loaded on demand basis for an incoming SSL request. CCS uses the Server Name Indication information from the Client Hello for functionality.

Why do we need CCS when we already have SNI?

While SNI addressed only the SSL scalability problem with IIS, CCS addresses both SSL scalability and manageability of the certificates.

Also consider a hosting scenario where typically there are close to 1000 sites. If all of these were SSL enabled, then there would be close to 1000 SSL bindings. These explicit bindings are specific to a site and are loaded in memory during start-up of IIS Services. In case of CCS there exists only binding and the certs are loaded on demand and cached for future use, this way the memory consumption is lesser and there is a slight performance gain.

How does CCS improve manageability of Certificates?

Prior to IIS 8, IIS always picked up the certificates store (Personal store of MY Computer account) which is local to every machine. In case of a stand-alone server this is not a problem. However, consider a web-farm scenario with 2 or more servers in the farm. If one has to configure a site to use SSL, the certificate has to be installed on all the servers along with the private key. If the certificate expires, again the same step has to be repeated on all the servers. So there was lot of manual work involved. If there were more servers in the farm or if you were to introduce another SSL site, it would be a bigger headache for the server admins.

In the server farm, we configure all the servers to use the CCS binding which reads from this Central Certificate Store. Now IIS picks the certificate from the file share and not the local certificate store. The server admins have the task simplified and they need to install/renew the certificate on a single location i.e., the file share.

Installing CCS

Unlike SNI, CCS is not pre-installed it has to be installed separately. It is shipped as a native module and has to be installed via the Server Manager console on Windows Server 2012 & via Programs & Features on Windows 8. Below are instructions to

Installing CCS on Windows Server 2012:

·         Launch Server Manager.

·         Under Manage menu, select Add Roles and Features:

       

·         In "Add Roles and Features Wizard" click "Next".

·         Select "Role-based or Feature-based Installation" and click on Next.

·         Select the appropriate server (local is selected by default) and click on Next.

·         Select Web Server (IIS):

       

·         No additional features are needed for IIS, so click "Next".

·         Click on Next again.

·         By default, Centralized Certificates is not selected. Expand Security and then select "Centralized SSL Certificates Support" and click on Next.

       

·         Click on Install and wait until the installation completes.

·         Upon successful installation the wizard would reflect the status:

       

Installing CCS on Windows 8:

·         Go to run prompt, type "appwiz.cpl", and hit Enter key.

·         This would launch the Programs and Features Console.

·         Click on "Turn Windows features on or off".

·         Select "Internet Information Services" and expand the tree.

       

·         Go to World Web Wide Services->Security

·         Select "Centralized SSL Certificate Support" and click on ok.

        

·         Centralized Certificates is installed successfully.

Configuring Central Certificate Store

1.                   Launch IIS Manager.

2.                   Under "Connections" select <MachineName>.

3.                   In the middle-pane, under "Management", double-click on "Centralized Certificates"

4.                   Under "Actions" pane select Edit Feature Settings:

5.                   Select the check box "Enable Centralized Certificates" and provide the following details:

6.                   Centralized SSL Certificate Support feature is now ready to be used.

7.                   One manageability feature that is noteworthy is the ability to group the certificates by their expiration dates:

8.                   The webserver is setup to use Centralized Certificate Store.

Configuring a website to use CCS Bindings

1.                   Open IIS Manager.

2.                   Under Connections pane, right click "Sites" and select "Add Website…"

3.                   Fill the details as shown below

a.              Site name: CentralSSL0

b.              Physical path: C:\inetpub\wwwroot\CentralSSL0\

c.               Type: https

d.              Hostname: CentralSSL0

·         In Windows Server 8, host name must be specified when using CCS. (New )

·         The value depends on the certificate being used.

e.              Require Server Name Indication: Selected

f.              Use Centralized Certificate Store: Selected

NOTE: There is no need to select a specific certificate.

g.                With the use of SNI and the naming contract, the corresponding certificate is selected automatically. In this example, IIS tries to read CentralSSL0.pfx from the Centralized SSL Certificates file share.

h.                Click on "OK".

You have successfully created a website using Centralized Certificate Store. The management experience is similar to that of Shared Configuration and traditional SSL. There are some differences though:

·         The certificates are stored centrally on a file share.

·         Host name has to be specified for SSL site when using CCS.

·         SSL binding is not managed explicitly 1-to-1. They are loaded on-demand.

CCS Bindings

To view the CCS bindings we execute the same netsh command as earlier. Execute the following from an elevated command prompt:

netsh http show sslcert

The above command reads the following registry key and enumerates the values. Below is the location:

HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslCcsBindingInfo

CCS Configuration

In my previous post I had mentioned a new attribute called sslFlags. This attribute specifies whether the SSL binding is using SNI or CCS or both. CCS Configuration

If the sslFlags attribute is set to either 2 or 3, then it is using the CCS bindings. If you check the applicationhost.config this is what the binding section would contain:

However, you wont find the configuration for the CCS Module in applicationhost.config. Well, this information is not stored in any of the config files. It is stored in registry under the following node:

HKLM\SOFTWARE\Microsoft\IIS\CentralCertProvider

However, you wont find the configuration for the CCS Module in applicationhost.config. Well, this information is not stored in any of the config files

More Information:

·         Microsoft Virtual Academy: IIS8 Centralized Certificate Store

·         IIS 8.0 Centralized SSL Certificate Support: SSL Scalability and Manageability

·         Plan SSL Central Certificate Store

 

I’m not done yet. There are few things that I need to address like, if someone has all the 3 types of bindings then which cert would be served? I’m not going to answer it now.

I will do it in my next blog post. Until then Ciao!

I have been asked this question on several occasions on how to disable revocation check in IIS 7.  It was pretty easy for IIS 6, on IIS 7 there is no documentation on how to do so. This post will describe on how to achieve this task.

Firstly, list out all the existing IIS bindings via command line as shown below:

NOTE:

    
In order to disable the revocation check, we need to delete the existing binding first. Before you do that make a note of the above details, especially the certificate hash.

Now add the binding again using netsh as shown below:

Highlighted portion of the above command depicts that we are disabling the client certificate revocation. This adds a DWORD at the following location in registry:

DefaultSslCertCheckModecan take the following values. Click here for more info.

Review the SSL bindings after executing the above command. The CRL check would be disabled.

NOTE: Client Certificate Revocation is always enabled by default.

More details on the netsh commands for HTTP can be found here: http://technet.microsoft.com/en-us/library/cc725882(v=ws.10).aspx#BKMK_2

MORE INFORMATION

NETSH Commands for HTTP in IIS 8:

With IIS there are 2 new SSL bindings viz. SNI Bindings and CCS Bindings. So the above commands would have to be modified slightly to incorporate these changes. So we have 2 additional parameters than what are listed in the above TechNet article. They are:

hostnameport is very similar to the ipport. The only difference is that it takes a Unicode string as an input along with the port number.

Below are the modified commands for the corresponding bindings in IIS 8:

In this article I will be discussing about the following:

• Self-Signed Certificate
• Root CA Certificate
• Intermediate CA Certificate

At the end I would like everyone to be able to differentiate between these certificate types.

Self Signed Certificate

Self Signed Certificates are certs where both the Issued To and the Issued By field of the certificates are same. In simple words it is a certificate where one issues a certificate to itself and hence the name Self Signed Certificate. Here is one example:

As seen in the above image the Issued to and Issued by are same. You may also observe the warning indicating that the certificate is not trusted. Of course it is not as it is self-signed, none of the Known Public CA’s have issued this, so it wont be trusted.

Hope this article will clear some confusion at least.

Until then CIAO

With the dawn of CLOUD COMPUTING, every one is betting big time on cloud. I might be little late to arrive here, but its never too late.

MICROSOFT named its cloud infrastructure as AZURE.

Coming to the topic, Windows Azure Web Sites aka ANTARES is a PasS offering provided by Microsoft. This is currently in preview mode, hence there is still a big room for improvement.

PasS is an acronym for Platform as a Service.

SUBSCRIBING TO WINDOWS AZURE:

To start off, sign in to Windows Azure Management Portal: https://manage.windowsazure.com.

You should have a outlook.com credentials to login to this portal. If you are accessing this link for the first time you will see this:

Don’t be disheartened, click on “SIGN UP FOR WINDOWS AZURE”.

On the next page, you will get options to chose the way you would like to subscribe. For beginners and testers you could sign-up for a 3-month (or 90 day) free trial.

This is what is offered under the 90 day free trial:

The next steps will verify the account details. Once done you could successfully login to the portal using your credentials.

Once you are through with all these, you will be greeted with the below page. This is the Windows Azure Management Portal. I have highlighted “WEB SITES” which is referred to as WINDOWS AZURE WEB SITES (WAWS) OR ANTARES.

NOTE: Only the Web Sites section of Windows Azure is referred to as Antares or WAWS.

Windows Azure Management Portal

Creating a Web Site:

Once you have successfully subscribed, you could create a new website on WAWS either with a database or without a database. You have the option of choosing PHP as the language and MySQL as the database.

Instead of blogging the entire process, you could go through the following blog link on how to create a web site on WAWS:http://blogs.msdn.com/b/windowsazure/archive/2012/06/22/web-sites-series-create-php-and-mysql-sites-with-windows-azure-web-sites-and-webmatrix.aspx 

Upon website creation the portal updates itself and reflects the changes. Notice how the count below the websites indicate the number of websites that I have.

Click on the name to configure/manage/deploy that specific site. Click on the DASHBOARD.

As you can see the UI is crisp and clear and the interface is pretty simple, straightforward and easy to use.

Deploying a Web Site on WAWS:

This is one of the interesting features that have been provided. The user could deploy his application in various ways. There are plethora of tools to select from the list:

• File Transfer Protocol
• Web Matrix
• Visual Studio
• TFS
• GIT (software) etc.

I used Web Matrix to deploy a site and here is the URL: http://kaushal.azurewebsites.net/ 

That's it for today. This article is not enough to discuss all the features and options available for the users on WAWS. I will post more on this in the coming days.

Until then CIAO!

MORE INFORMATION:

Windows Azure home page: http://www.windowsazure.com/en-us/ 

Windows Azure Web Sites:

• http://www.windowsazure.com/en-us/home/scenarios/web-sites/ 
• https://www.windowsazure.com/en-us/manage/services/web-sites/

How to Manage Web Sites:https://www.windowsazure.com/en-us/manage/services/web-sites/how-to-manage-websites/

Channel9 video: http://channel9.msdn.com/Events/windowsazure/Learn-2012TechEd-EU/WebSites

YouTube:

Create and Mange Web Sites on Windows Azure

In my previous post, click here, I mentioned and described few of the features of WAWS, cloud offering from Microsoft. As I mentioned we could associate a application with either the MySQL db or Microsoft’s own SQL Server db. There is a small twist in the story though. MySQL is owned by ClearDB and there is no UI on Windows Azure to manage MySQL db.

Windows Azure has a web interface/UI for managing SQL Server db. Here is a snapshot of the same:

Windows Azure portal for managing SQL Server databases

Last week, one of the consumers of the Windows Azure wanted to know how to retrieve the MySQL connection string so that he could use it with other application that he had on Azure. This could get tricky. As I said earlier, there is no UI for managing MySQL database. So the question is how does one retrieve the connection string if he wishes to.

Before I proceed ahead on how to retrieve the connection string let me show you how do you create a MySQL db on Windows Azure.

Creating a MySQL db on Windows Azure Web Sites

• Go to WEB SITES and click on NEW.
• Select COMPUTE and then WEB SITE and then click on CUSTOM CREATE.

• This will show up another portal where you will get the following options
• Chose the URL for the Web Site.
• Chose the subscription you want to use, in case you have more than one.
• The geographical location where you want this to be created.
• Create either a new SQL Server or MySQL db or chose from the existing one.

• Once you have created or selected the database, you will see the DB CONNECTION STRING NAME. This can be edited.

• Click on  to confirm the creation of both the site and the database.

So I created a site (kaushal-mysql) to use a MySQL database successfully. Now lets proceed to the next step where we can retrieve/view the connection string.

Retrieving/Viewing the MySQL Connection String

In order to be able to the view the connection string the MySQL Db should be linked to the site i.e., if you go to the LINKED RESOURCES section then you should see that the corresponding MySQL db.

• Click on WEB SITES.
• Click on the site which is using the MySQL db. In my case it is kaushal-mysql.
• Click on DASHBOARD.
• Towards the RHS of the portal under quick glance you will see the option “View connection strings.” Click on this to view the connection string.

There you go! Here is the MySQL connection string that you were looking for. Obviously this will also show the SQL Server connection string in case the site was created with a SQL Server db.

So ensure that the database is linked to the site in order to view the connection string. Once you have copied the connection string. You could unlink and use that connection string in another application.

That's it for today folks. Hope this helps someone. Until then ciao!

Recently Dropbox was added to Windows Azure as yet another source control which could be used for publishing source code on to Windows Azure Web Sites. It makes the deployment task much simpler. Lets discuss this in detail here.

Installing and Configuring Dropbox

• Go to http://www.dropbox.com and sign up for a Dropbox account which we can use with Windows Azure.
• Download and install Dropbox on your local computer. Click here

Once this is done follow through the Dropbox setup:

• Select “I already have a Dropbox account” and click on Next.

• Enter your Dropbox Credentials and click on Next.

• The next screen will prompt you to Upgrade your Dropbox from free to paid account. Let us continue with the Free storage of 2 GB and click on Next.

• Select Typical and click on Next.
• Now you will get a series of window which will provide a small demo of this tool. Click on Skip Tour and then click on Finish on the next screen.

A folder by the name Dropbox will be created under the following path: “C:\Users\<username>\Dropbox”

Linking Windows Azure Web Site to Dropbox

• Go to Windows Azure Portal.
• Click on “Set up deployment from source control” under quick glance section of the DASHBOARD page.

• Select Dropbox from the given list and proceed forth

• Once done you will get a prompt to authorize your Windows Azure account to access Dropbox. Click on Allow.

• Now you will get an option to Set up publishing. If this is the first time just click on the Next icon. If you have previously published via Dropbox then you will see an additional option under FOLDER NAME dropdown list.

• It will take some time to link Dropbox to the corresponding site. Until then users will see this:

• Now go back to Windows Explorer and check the Dropbox folder. 3 Folders would have been created under Dropbox nested within each other in one hierarchy. Under Dropbox there will be a new folder called Apps. Under App there will be a folder called Azure and under Azure there will be a folder for every corresponding site. Below is the snapshot of the hierarchy:

• Copy and paste your application content within the folder for the web site.
• Now go back to the Windows Azure portal and click on the SYNC Icon at the bottom.
• It will take some time to publish the source code from Dropbox to Windows Azure Web Site. Once deployed the portal will refresh to reflect the changes.

• Click on BROWSE icon to browse the site. Below is a snapshot of the content I deployed.

NOTE: The DEPLOYMENTS page will not be seen under the portal unless a source control for deployment has been setup for the Website.

As you can see the deployment with Dropbox is pretty much simple and doesn’t take too much effort. Go ahead and try out the Windows Azure Web Sites feature today.

Until then Ciao!

This is the most common requirement on most of the Exchange servers hosted on IIS. The server admins configure an http to https redirect.

Today I will be discussing few ways of doing this. I will keep updating this document as I find more ways to do so. I am considering OWA as a sub application under IIS for all the below examples. Here is the structuring of the Web Site:

In this case, we want all the requests (both HTTP& HTTPS) to be redirected on HTTPS to the application called "OWA" under the Default Web Site.

Method 1: Using IIS URL Rewrite Module

For this you will have to install the URL Rewrite module. (FYI, this is available for IIS 7 and higher only.)

Download from here: http://www.iis.net/downloads/microsoft/url-rewrite

Once installed, the URL Rewrite module would be listed under IIS section. There are few articles out there on this. Here are few to list:

1. http://www.sslshopper.com/iis7-redirect-http-to-https.html
2. http://www.jppinto.com/2010/03/automatically-redirect-http-requests-to-https-on-iis7-using-url-rewrite-2-0/

These articles are definitely a great repository, however I observed that they have not addressed an important factor.

As specified in the above links add the below section in the web.config at the root of the site:

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

<system.webServer>

<rewrite>

<rules>

<rule name="HTTP/S to HTTPS Redirect" enabled="true" stopProcessing="true">

<match url="(.*)" />

<conditions logicalGrouping="MatchAny">

<add input="{SERVER_PORT_SECURE}" pattern="^1$" />

<add input="{SERVER_PORT_SECURE}" pattern="^0$" />

</conditions>

<action type="Redirect" url="https://{HTTP_HOST}/OWA/" redirectType="Permanent" />

</rule>

</rules>

</rewrite>

</system.webServer>

</configuration>

You can find the complete list of IIS Server variables here: http://msdn.microsoft.com/en-us/library/ms524602(v=vs.90).aspx

Alternatively, instead of the above server variable the following server variable "HTTPS" and "SERVER_PORT" can also be used correspondingly.

Method 2: Using IIS Default Document (a default.asp page)

In this method we will introduce a sample asp page at the root of the website and then add the following piece of code:

<%

        If Request.ServerVariables("HTTPS")  = "off" Then

                Response.Redirect "https://"& Request.ServerVariables("HTTP_HOST") & "/OWA"

        ElseIf Request.ServerVariables("HTTPS")  = "on" Then

                Response.Redirect "https://"& Request.ServerVariables("HTTP_HOST") & "/OWA"

        End If

%>

Alternatively you could use the following piece of code as well (ensure to change the port numbers as per the website configuration).

<%

        If Request.ServerVariables("SERVER_PORT")=80 Then

                Response.Redirect "https://"& Request.ServerVariables("HTTP_HOST") & "/OWA"

        ElseIf Request.ServerVariables("SERVER_PORT")=443 Then

                Response.Redirect "https://"& Request.ServerVariables("HTTP_HOST") & "/OWA"

        End If

%>

The logic is pretty simple, we are checking if the requesting is on HTTP (Port 80) or HTTPS (Port 443) and redirecting them to https://<HostName>/OWA.

There are obviously several ways to write the same code by checking other server variables.

Method 3: Using IIS HTTP Redirect Module

This is one of the simplest methods, but has a lot of limitations and ideally not used. Here is how we do it:

PRE-REQUISITES: HTTP Redirect module is installed and the website has a valid HTTPS binding in place.

• Launch the IIS Manager.
• Go to the HTTP Redirect module.
• Fill the details as per the requirement as shown below:

This may not be ideal for all the scenarios as the user is redirected to a specified URL.

There is another way using custom error pages which has been documented here:

• http://www.sslshopper.com/iis7-redirect-http-to-https.html
• http://www.jppinto.com/2009/04/automatically-redirect-http-requests-to-https-iis-7/

The author in the 2^nd link claims that it doesn't work on IIS 7.5 and higher versions due to updates in the configuration security.

I haven't found the time to test and write it up and neither am I sure if the above actually works. Once I have tested I will add it up here.

There were lot of differences with regards to SSL moving from IIS 6 to IIS 7.x and then to IIS 8. IIS 6 in itself was a breaking change, however there were lot of limitations and they were addressed in higher versions. I will try to pen down as I remember them and will update the blog if I come across other changes.

Before I proceed further, for readers who are not familiar with IIS and Windows versions, this is a small info to set the stage:

• IIS 6 (Windows Server 2003 and Windows XP 64 bit only)
• IIS 7 (Windows Server 2008 and Windows Vista)
• IIS 7.5 (Windows Server 2008 R2 and Windows 7)
• IIS 8 (Windows Server 2012 and Windows 8)

I will be addressing both IIS 7 and IIS 7.5 as IIS 7.x.

Differences from architectural perspective:

One major difference between IIS 6 and the IIS 7.x was the way they would handle incoming HTTPS requests. Lets discuss how HTTPS requests were handled in IIS 6 before we proceed any further.

Taking the above architecture into consideration this is how the IIS 6 request flow looks like:

1. HTTPS requests comes into SSL Queue within HTTP.SYS, which is in the KERNEL Mode.
2. The encrypted requests is then sent to a USER Mode process called LSASS.exe for decryption. The request is decrypted using SChannel.dll loaded inside the lsass.exe process.
3. The decrypted request is not sent back to the HTTP.SYS In the Kernel Mode.
4. This is now placed in the corresponding Application Pool queue and then routed to corresponding worker process in USER Mode based upon which w3wp.exe a application pool queue corresponds too.
5. The w3wp.exe generates the response and sends it back to the HTTP.SYS in the KERNEL Mode.
6. This response is again sent to the Lsass.exe process in the user mode for encryption.
7. After encryption, lsass.exe sends it back to the HTTP.SYS in the KERNEL mode.
8. The encrypted response is sent back to the client.
   

PROBLEM 1:

During the course of the entire processing of request, there were several context switches (Whenever there is a flow of control from KERNEL MODE to USER MODE or vice versa, it is referred as a CONTEXT SWITCH).

There were 6 context switches in the above flow, out of which 4 context switches happened for encrypting and decrypting of request and response.

Context switching induces additional overhead and delays the processing of requests. This impacts the performance as this happens for every HTTPS request-response cycle.

These 4 context switches could have been avoided if the encryption and decryption happened in the KERNEL Mode. This was addressed in IIS 7 and the same was retained in later versions.

PROBLEM 2:

Another problem is the problem with host headers. Host Headers were never defined in the original SSL Specification, as they were part of the HTTP RFC and defined there. The TCP Layer never defined the Host headers for obvious reasons. Due to this, a major problem emerged & made SSL applications not scalable.

Due to the unavailability of the Host Header in the TCP layer, the incoming encrypted HTTPS request provided only IP+Port as information to HTTP.SYS. In IIS the problem was addressed by allowing only one SERVER CERTIFICATE (Certificate Hash) per IP+PORT binding. The SSL Host Header was mostly irrelevant unless the Server Certificate was either a Wild Card Certificate or a SAN Certificate.

This problem was later addressed by the IEEE by introducing Subject Name Indication (SNI). Here the host header was made available in the Client Hello,sent by the client to the serer during the initiation of the SSL Handshake.

This was implemented in IIS 8. However, it has its own set of limitations.

SOLUTION:

In IIS 6, the solution was already present in the form of KERNEL MODE SSL. However this required tweaking of a registry key and was not a ideal solution as it wasn’t used by most of the customers and was never recommended.

In IIS 7, KERNEL MODE SSL is the default option and this cannot be changed. The KSECDD.SYS driver is responsible for providing the cryptographic functionalities in the kernel mode.

This reduces the context switching during the request response cycle and hence improves the overall performance. Below is the improved request-response flow:

1. HTTPS requests comes into SSL Queue within HTTP.SYS, which is in the KERNEL Mode.
2. The encrypted request is decrypted with the help of KERNEL Mode SSL.
3. This decrypted request is placed in the corresponding Application Pool queue and then routed to corresponding worker process in USER Mode based upon which w3wp.exe a application pool queue corresponds too.
4. The w3wp.exe generates the response and sends it back to the HTTP.SYS in the KERNEL Mode.
5. This response is encrypted via the KERNEL Mode SSL component.
6. The encrypted response is sent back to the client.

As seen there is a clear performance improvement due to the reduced context switching.

In IIS 8, this problem 1 was already addressed as it was inheriting the architecture of IIS 7. However, considerable changes were made to the HTTP.SYS and the SSL functionality to incorporate SNI in the server architecture.

A new form of SSL binding called SNI bindings was introduced, which were in the form of HostName+Port.

You can read more about it here:

• http://blogs.msdn.com/b/kaushal/archive/2012/08/08/ssl-scalability-with-iis-8-windows-8-server.aspx
• http://blogs.msdn.com/b/kaushal/archive/2012/09/04/server-name-indication-sni-in-iis-8-windows-server-2012.aspx
• http://blogs.msdn.com/b/kaushal/archive/2012/10/11/central-certificate-store-ccs-with-iis-8-windows-server-2012.aspx
  

Differences from Configuration Perspective:

In IIS 6, this is how the bindings section looked like within the MetaBase.xml:

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

...

...

...

SSLCertHash="1c25a46a479813472f8d997b3ef4b699130b0737" SSLStoreName="MY"

SecureBindings=":443:"

ServerAutoStart="TRUE"

ServerBindings=":80: :80:www.kaushal.com :80:www.kaushal.edu :80:kaushal"

ServerComment="Default Web Site" ServerSize="1"

SslCtlIdentifier="{6A615835-58F1-4B6F-A779-3F5AE1F1F9E7}"

SslCtlStoreName="CA" UseHostName="TRUE">

As seen in the above snippet of the config section, the SSL cert hash was stored within the MetaBase.xml along with the bindings information and SSL related information like SSLStoreName, SSLCtlStoreName etc.

This information was also present in the registry as well. There was supplication of efforts one could say because the user mode processes would refer the MetaBase.xml while kernel mode components would refer the registry related information.

This changed in IIS 7.x and later versions have incorporated it, all the certificate related information was moved to the registry, no cert related information is stored in the config file. Below is a snippet of the config:

<sites>

<site name="Default Web Site" id="1" serverAutoStart="true">

<application path="/">

<virtualDirectory path="/" physicalPath="%SystemDrive%\inetpub\wwwroot" />

</application>

        ...

        ...

        ...

<bindings>

<binding protocol="http" bindingInformation="*:80:" />

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

</bindings>

<traceFailedRequestsLogging enabled="true" />

</site>

As seen above lot of information has been removed from the config file. There were no duplication of efforts due to the removal of the cert related section from the config file, mainly due to KERNEL Mode SSL dependency. This reduced the size of the overall configuration file as well.

Differences from UI Perspective:

There was significant change as to what options were available in the IIS UI for the users when configuring SSL. This changed drastically from IIS 6 to IIS 7. Even the latest version of IIS, follows the same UI which was changed in IIS 7 with additions to incorporate the new functionalities.

IIS 6 UI was pretty limited. There were several problems associated with it. The UI allowed only one certificate to be bound to the site irrespective of whether there were 2 or more combinations of IP+Port. The reason for this was that the UI for specifying the IP+Port was different than the one which was used to bind the certificate. These were presented to the user as 2 different sections and hence was a problem.

To get the above UI:

• Right click and go to the Web Site properties:
• Go to the Web Site tab.
• Under Web site identification click on Advanced…
• Click on Add.. under Multiple identities for this Web site.

The above image is the UI to add the bindings for the web site. There is no option to choose the certificate or to specify the host header. The user can only specify the IP and Port and then he has to traverse to another section to choose the certificate for the site.

As shown above the UI to add a certificate is in a different tab altogether. Even if the user adds 3 distinct secureBindings, the UI allows only one certificate to be mapped to the Web site. This is because there was no way in the config to identify which bindings will use what certificate. As a result due to this, all the bindings for that site ended up using only one certificate. Not a ideal situation at all.

All these short comings were addressed in IIS 7 and this has remained as a base for the future IIS versions too. take a loot at this UI:

The UI is pretty simple. It allows the user to select a certificate for a corresponding IP+Port combination. The Host name section contains a textbox to specify the value, but is disabled by default (This is another shortcoming in IIS 7.x versions). This is enabled only if the certificate is a Wild Card certificate (If it’s a SAN certificate, the textbox would still remain disabled). When the user selects a certificate from the drop down list, it directly updates the registry values corresponding to the SSL binding.

There are few other changes which exist moving forth from IIS 6 to IIS 7 and are not pleasant. Yes I’m referring to Client Certificates.

IIS 7 onwards there is no UI to specify Client Certificate mapping.

However, citing these problems, the configuration editor was introduced as separate download for IIS 7 (It is available by default in IIS 7.5 and later versions).

The configuration editor was a blessing in disguise for user who still use IIS Client Cert Authentication. However, the IIS 6 UI probably was better in this regards at least.

With this, I am calling an end to the lengthy blog. I will update the list as I come across other differences between these IIS versions.

The QUICK START management page is seen right after the user selects one of the websites in the management page. As self descriptive it can get, the page provides quick access to important actions relating to creating a deployment of a site on to Windows Azure. This is also the default landing page in the portal for a newly created website.

The user can chose to skip the Quick Start page when they visit the website next time. To do so select the checkbox “Skip Quick Start the next time I visit” provided right at the center of the page.

Below is a snapshot of the page:

The page contains the following sections:

• Get the tools– Provides links to Install WebMatrix and Windows Azure SDK.

        WebMatrix is a free, lightweight web development tool that includes everything you need to create web sites and publish applications for Windows Azure. WebMatrix supports the latest web technologies, including ASP.NET, PHP, HTML5, CSS3, Node and more. The Windows Azure SDKs allow you to build applications that take advantage of Windows Azure's scalable cloud computing resources.

• Publish your app.– Once the user has set up a web site and dependent resources, such as a database in the Portal with the create option, they can download the generated publishing profile, import it into the development tool of choice (for example, WebMatrix or Visual Web Developer), and deploy the web site to Windows Azure within seconds.

        They can also publish the web application from FTP directly by setting up deployment credentials in the portal and pushing the application to Windows Azure using one of their favorite FTP clients.

• Integrate source control– This allows the user to setup deployments from a source control providers like TFS, CodePlex, GitHub, Dropbox, Bitbucket and Local Git.

The last two options are again available on the Dashboard page.

Unlike other management pages this one is represented by a Image, rather than a descriptive name. The Image is very tiny and the users might miss it. Even I missed noticing this one. However thanks to my colleague Ivanov for figuring this out as soon as I approached him with the problem. Sometimes its always better to take a second opinion.

You might have seen this links on the DASHBOARD management page of the website hosted on WAWS, under the quick glance section:

• Reset your publish profile credentials
• Reset your deployment credentials

There is both similarity and difference in what these 2 options provide and can be confusing at times. The similarity is that both operate on the deployment credentials. But before we understand the difference lets download the publish profile for a website hosted on WAWS.

Once you download the file (.publishsettings file), open it in a notepad and review the section. The file contains the configuration needed to deploy a web application on to WAWS. It contains 2 sections, one for Web Deploy and another for FTP. Both the sections make use of the same deployment credentials (username and password). The format of specifying the username differs while the password remains the same.

The userPWD keyword contains the hash of the password of the deployment account.Make a note of the this keyword called userPWD.

I created a test site and downloaded the publish profile for it. Here is how it looks like:

Reset your publish profile credentials:

Now lets click on the option “Reset your publish profile credentials”. This will prompt you with the following warning:

The above message implies that when we chose the above option, it will invalidate all the previously downloaded publish profiles for this site. Now what causes the file to be invalidated is discussed next.

Click on YES when the warning message is prompted and the below message is displayed upon successful reset of the publish profile credentials as shown below:

Here is what happens; clicking the above option changes the hash of the password for account used for the deployment for this site. As the hash of the password has been changed, the previous file contains a different hash altogether and when the user tries to use that file for deployment, it is bound to fail due to password hash mismatch. Below is a snapshot of the userPWD section after resetting of the password.

The deployment credentials are website specific and will affect only the current website on which the action has been performed.

Reset your deployment credentials:

Now lets click on the option “Reset your deployment credentials”. This will prompt the user with the following pop-up:

Now, this option is self explanatory. It allows the user to change the deployment credentials i.e., the username and password. However this option is not specific to a website, as the user is changing the password for the deployment account, it will affect all the web sites. These credentials are directly tied to the Microsoft account (Outlook.com or Live.com). So changing these credentials will be changing it for all the subscriptions tied to the Microsoft account. Thanks to one of my peers in the escalation team (Jim Cheshire) for clarifying this out to me. He is one of the most active members on the Windows Azure Web Sites Forum.

David Ebbo has explained it here: https://github.com/projectkudu/kudu/wiki/Deployment-credentials

This will in turn change the hash of the password, which makes it similar to the previous option. But with a major difference that the user changes the actual deployment credentials (username or password or both) which affects all the sites and invalidates the publish profile for all the sites.

Hopefully, this should clear the confusion on this topic.

Finally in the first week of June 2013, it has been announced that Windows Azure Web Sites will provide native support for SSL, which includes both SNI SSLandIP based SSL for custom web site domain names. This feature was one which took some time to be implemented and finally has been introduced. Before this the only way of doing SSL was via Cloud Service & Rewriting the URL. Refer this article: http://www.bradygaster.com/running-ssl-with-windows-azure-web-sites 

The users can view and configure this feature on the CONFIGURE management page. Below is a snapshot of what the users would view:

The certificates and the ssl bindings section are the ones which were incorporated into the portal. Before we discuss further we need to understand there are certain pre-requisites which has to be acknowledged.

• This feature is not available to sites which are running in either Free or Shared mode. (SSL support for Shared mode maybe added later, but there is not time frame provided for this.)

• ssl bindings section is enabled when the user has a valid custom domain name added for that site. which also implies that in order for the Choose a certificate drop down to work the user should configure a custom domain name for the website.

Adding a SSL Binding to the Windows Azure Web Site

Once the site has the provided pre-requisites, the user is ready to configure a SSL binding for the site. Lets ensure the web site is scaled to RESERVED before we proceed.

Uploading the Certificate

• Go to the Windows azure Portal and select Web Sites.
• Select the site (running in RESERVEDmode) for which we need to configure this binding.
• Go to the CONFIGURE management page.
• Scroll down to the certificates section.
• click on upload a certificate. This would pop-up a window as shown below:

• Browse to the location of the file and select the file.
• Enter the private key password.
• Click on to upload the certificate. If the upload is successful the portal would reflect the change.

Adding a custom domain name

Follow the instructions in the following URL to configure a custom domain for your site: Configuring a custom domain name for a Windows Azure web site.

I added a custom domain on one of my Web Sites for the demo. Here is the snapshot:

Adding the SSL Binding

On WAWS, the user can configure the following 2 types of bindings:

1. IP based SL binding.
2. SNI SSL binding.

SNI SSL Binding

• Go to the ssl bindings section on the CONFIGURE management page.
• Click on the Choose a domain name drop down to select one of the domain names configured for the site.

• Click on the Choose a certificate drop down to select a certificate from the list of certificates uploaded for this site.

• SNI SSL is the default option, so no changes has to be done.
• Click Save to commit the changes. The user will get a warning notification regarding the impact this may have on billing for the site.

• click on YESto proceed. Upon success the below message will be seen.

IP based SSL Binding

• As specified in the earlier steps, the user has to upload a certificate and configure a domain name for the website.
• Once done, he could choose it for the corresponding drop downs as we showed earlier.
• Now select IP Based SSL from the third drop down to configure the IP based SSL bindings for the site.

• Click Save to commit the changes. The user will get a warning that this may impact the billing for the site.

• Click on YESto proceed. Upon success, the below message will be seen.

*******IMPORTANT*******

Pricing for the SSL Connections for Windows Azure Web Sites

The users have to shell out more money when they configure the website to use IP Based SSL. This is very obvious, as this requires a dedicated IP (a resource) to be allocated for the website. This is also an expensive resource.

SNI SSL is comparatively cheaper as it doesn’t need a dedicated IP Address. However, it has own limitations as the non-SNI compliant browsers will not be able to access the site.

Windows Azure Pricing Calculator for Web Sites:http://www.windowsazure.com/en-us/pricing/details/web-sites/ 

Yesterday one of my colleagues came up to me with a simple problem regarding wild card certificates. I gave him the solution immediately, but it had to take a lot of convincing to do. This shows that there is a lot of confusion around how wild card certificates work.

For first time readers, wildcard certificates are server certificates which contain a wildcard (*) as part of the hostname. They offer a great advantage as one hostname containing a wildcard can match multiple hostnames provided they satisfy the condition.

Typically the Issued To section of the certificate will contain a hostname with a wildcard. There are real world examples like Facebook and Yahoo:

SAN certificates can also contain wildcard hostnames. They are a parent set, so a SAN certificate is also a wildcard certificate if it contains a hostname with a wildcard as shown in the above image.

****CONFUSION****

As only one cert can be bound to a specific IP+Port, regular certificates were not very helpful. Wildcard certificates provided solution to this problem. Thought not a full-fledged solution to the problem. It provided some relief. The admins could have a certificate issued to *.contosso.com and then have hostnames configured accordingly.

However this gave rise to some confusion. Even though this is clearly documented in the RFC’s. I have still seen many getting confused on this.

Consider a certificate issued to *.contosso.com. If this has to be configured any web server, then a question arises. What all valid hostnames can be configured with the above certificate?

Lets take a look at the below table

Looking at the above table you should have understood that the wildcard character allows only one single domain as an addition to the hostname.

If you were to configure a host name as per 3 & 4 on IIS for a cert issued to *.contosso.com, then the client browser would throw an error indicating address mismatch. Different browsers throw different errors.

Below is a snapshot of errors thrown by different browsers:

• Internet Explorer:

IE displays a user friendly error. It doesn’t contain any detailed errors, which is not required but nevertheless they cant be completely ignored. A little more detail in this regards would have been better.

• Google Chrome:

Chrome does a better job than IE here, it provides more details informing the user what the certificate is issued to and the hostname they are browsing to.

• Mozilla Firefox:

Mozilla Firefox gives more detailed error on what actually happened. It includes the Error code ssl_error_bad_cert_domain.

• Opera

Opera gives details about the certificate, but the information is not presented as clearly as Firefox or Chrome for that matter.

****REASON****

Now why is that the last 2 (3 & 4) in the table were invalid? The reason is that the RFC2818 defines it to be this way. The RFC allows matching of only a single domain for a given wild card character.

Below is a snippet of RFC 2818:

Rescorla                     Informational                      [Page 4]
RFC 2818                     HTTP Over TLS                      May 2000
.  Endpoint Identification
3.1.  Server Identity
   In general, HTTP/TLS requests are generated by dereferencing a URI.
   As a consequence, the hostname for the server is known to the client.
   If the hostname is available, the client MUST check it against the
   server's identity as presented in the server's Certificate message,
   in order to prevent man-in-the-middle attacks.

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted. (For instance, a
   client may be connecting to a machine whose address and hostname are
   dynamic but the client knows the certificate that the server will
   present.) In such cases, it is important to narrow the scope of
   acceptable certificates as much as possible in order to prevent man
        

   in the middle attacks.  In special cases, it may be appropriate for
   the client to simply ignore the server's identity, but it must be
   understood that this leaves the connection open to active attack.

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

   Matching is performed using the matching rules specified by
[RFC2459].  If more than one identity of a given type is present in
the certificate (e.g., more than one dNSName name, a match in any one
of the set is considered acceptable.) Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com.In some cases, the URI is specified as an IP address rather than a
   hostname. In this case, the iPAddress subjectAltName must be present
   in the certificate and must exactly match the IP in the URI.
   If the hostname does not match the identity in the certificate, user
   oriented clients MUST either notify the user (clients MAY give the
   user the opportunity to continue with the connection in any case) or
   terminate the connection with a bad certificate error. Automated
   clients MUST log the error to an appropriate audit log (if available)
   and SHOULD terminate the connection (with a bad certificate error).
   Automated clients MAY provide a configuration setting that disables
   this check, but MUST provide a setting which enables it.

   Note that in many cases the URI itself comes from an untrusted
   source. The above-described check provides no protection against
   attacks where this source is compromised. For example, if the URI was
   obtained by clicking on an HTML page which was itself obtained
   without using HTTP/TLS, a man in the middle could have replaced the
   URI.  In order to prevent this form of attack, users should carefully
   examine the certificate presented by the server to determine if it
   meets their expectations.
        

If you observe the above snippet carefully you would notice that certificates can be issued to IPAddresses as well. But then the IPAddress should match the IPAddress in the certificate exactly. failing which could lead to a address mismatch error.

Hope this clears some confusion. Let me know if this post helped you.

Capturing memory dumps is a most common ask while troubleshooting performance related issues with web applications. We generally use DebugDiag to do so. Not many are familiar with the tool and hence find it difficult to use it to capture the data.

This time I’ll discuss how to use DebugDiag to generate memory dumps on First Chance Exceptions. Please go through the following blog if you want to know what a first chance exception is:

http://blogs.msdn.com/b/davidklinems/archive/2005/07/12/438061.aspx

I’ll be using DebugDiag v1.2, below is the download link:

http://www.microsoft.com/en-us/download/details.aspx?id=26798

Download and install the tool corresponding to the bitness of the server and not the process i.e., for 32 bit machines download x86 and for 64 bit download x64.

The default installation folder is “C:\Program Files\DebugDiag”

There are 2 ways to capture FIRST CHANCE EXCEPTION dumps of a process.

• Method 1: Generate a dump for all First Chance Exception or

• Method 2: Target a specific First chance exception (Recommended)

Method 1: Generate a dump for all First Chance Exception

This is the easiest way to capture a dump for any exception that is raised within the process, However this captures unnecessary data and a lot of junk data is generated and hence is never recommended. Below are the steps to configure the same:

1. Launch DebugDiag
   
2. In the Rules tab select Crash and click on Next.
           
3. In “Select Target Type” select “A specific process” and click on Next.

Note: If the target is a web application hosted on IIS then, choose either “All IIS/COM+ related processes” or “A specific IIS web application pool”.

4. In “Select Target” select the target process and click on Next.         
                
5. In “Advanced Configuration (Optional)” under “Unconfigured First Chance Exceptions” set the following:
   
1. Action type for unconfigured first chance exceptions: Full Userdump
2. Action Limit for unconfigured first chance exceptions: 10
   
    
6. Click on Next twice and then click on Finish to activate the rule.

This will generate a dump for any unconfigured exception that may occur inside the target process. The file name will be in the following format:

<ProcessName>__<ApplicationPool>__PID__<PIDValue>__Date__<DateValue>__Time_<TimeValue>__First chance exception <Exception_Code>.dmp

Example:

w3wp__DefaultAppPool__PID__10032__Date__05_09_2012__Time_12_52_51PM__406__First chance exception 0XE0434352.dmp

Method 2: Target a specific First Chance Exception (Recommended)

Follow the above method until step 5. Here we will target a specific First Chance Exception. I will be targeting OOM exception for my example/

1. In “Advanced Configuration (Optional)” click on the Exceptions… button.
   
   
   
2. In “First chance Exception Configuration” click on “Add Exception…”
   
3. In “Configure Exception” select the Exception code from the LHS and since we are targeting OOM, specify the details as shown below:
   
1. .NET Exception Type: System.OutOfMemoryException
2. Action Type: Full Userdump
3. Action Limit: 3
   


NOTE: The Exception type is case sensitive. Ensure it is entered correctly. For more details please visit the following link: http://msdn.microsoft.com/en-us/library/system.systemexception.aspx

4. Click on Ok and then click on “Save & Close”.
   
5. Click on Next twice and then click on Finish to activate the rule.
   

The dumps created by this rule will be in the following format:

<ProcessName>__PID__<PID>__Date__<DateValue>__Time_<TimeValue>__First Chance <ExceptionName>.dmp

Example:

w3wp__PID__2364__Date__05_09_2012__Time_12_59_51PM__406__First Chance System.OutOfMemoryException.dmp

Hope this helps. Until then. Adios!

One of the cool features of Windows 8 is the improved set of PowerShell commandlets that have been shipped with it. There are several of them which could have made the task a lot easier for the server admins.

In here I will be discussing about one of the commandlets using which we can create a self-signed SSL Certificate. Yes, I mean self-signed and a SAN Certificate.

What you also need to know is that there are no lengthy procedures, it is a simple command with few parameters which adds to the simplicity.

So here are few pre-requisites that I could think of,

• Windows PowerShell and PowerShell ISE needs to be installed.
• OS is either Windows Server 2012 or Windows 8. (I’m not aware if this cmdlet has been back-ported to previous OS versions, I hope they do)
• The Windows PowerShell help menu is updated (Well this is not a necessity, but it will help if this is done.)

Commandlet Name: New-SelfSignedCertificate

Syntax:

New-SelfSignedCertificate [-CertStoreLocation <String>] [-CloneCert <Certificate>] [-DnsName <String>] [-Confirm <SwitchParameter>] [-WhatIf <SwitchParameter>] [<CommonParameters>]

Scenario

Consider you need to create a self-signed SAN certificate for the following hostnames:

• www.test.com
• www.test.edu
• www.test.testing.com

Using the above commandlet the cert can be issued and automatically placed in the personal store of My Computer Account.

Here is the command that we need to execute to generate the cert.

This will install the self-signed cert in the Personal store of machine account.

Note: Certificate wouldn’t be trusted. Place the certificate in the Trusted Root CA store and the error will go away.

So this is what the certificate looks like:

It can’t get easier than this.

Another thing worthwhile mentioning is the help menu, which is very descriptive. I have pasted the entire help menu content for the above commandlet below

The good thing is that it also provides descriptive examples.

        Recently one of my colleagues came across with an interesting question. He questioned why he couldn’t see the “Content-Encoding” header in the IE HTTP debugger but was able to view it in the Fiddler.

        First of all, Fiddler and IE are two different products. Their functionality should not be compared at any point of time. I will try to explain as to why we don’t see the above header in the IE HTTP debugger but we can view it in the Fiddler.

        To demonstrate this, I will set-up a simple repro. I’m going to use IIS 7.5 (the latest version) to demonstrate this. Enable Compression in IIS as shown below:

        Now, browse the website. For me its the default web site, so I access it over http://localhost. Hit F12 key to launch IE Developer Tools window or IE HTTP Debugger or whatever you call it. Go to the Network tab and click on “Start Capturing”.

        Now Launch Fiddler, and click on Clear Cache, so that nothing is served from the cache. Now when I browse to localhost, the traffic is capture by both the IE HTTP Debugger and the Fiddler. Lets take a look at both.

Here is the output from Fiddler:

        For those of you who are not familiar with fiddler, to inspect the HTTP traffic after gathering the trace, click on the Inspectors tab as shown above. The upper portion consists of Request headers and the below portion consists of Response headers.

        We can see that the Server Response contains the “Content-Encoding: gzip” header in the HTTP Response. For the readers I have also highlighted a portion of the image in blue which reads as “Response is encoded and may need to be decoded before inspection. Click here to transform”.

        We will re-visit this again, but before that lets take a look at what we see in IE for the same request. Below is what we see in the IE debugger.

        Select the URL which reads http://localhost and click on “Go to detailed view”. Here select “Response Headers”. You will see that the Content-Encoding header is missing. Interesting right? you will start wondering why the difference in behaviour.

Reason

        The reason we don’t see the Content-Encoding header in IE because it decodes (or decompresses) the response and then reads the header values. It needs to decode the HTTP response as it needs to do this to perform Script debugging and Inspect HTML Elements and CSS Rules. (Probably it would have been better if it read the Response Headers before decoding them so that we look at the complete HTTP Response)

        Even in fiddler, you get a option to decode the HTTP Response for the encoded responses. However, once you decode the HTTP Response (Click on “Click here to transform” in the above image), the response is encoded and the Content-Encoding header vanishes from the HTTP Response.

Response Headers in Fiddler before Decoding:

Response Headers in Fiddler after Decoding:

        Just to Let you folks know, the debugger that comes with Firefox reads the Response headers before they are processed.

Below Snapshot is from Firefox HTTP debugger:

        Some may question as to why cant IE do it. Well, these are different products and have different implementations. No one actually uses the browser for traffic monitoring, you have better tools to do so, like Network Monitor and WireShark. The HTTP debugger was designed mainly for Script Debugging and Inspection of HTML Elements.

        Hopefully, the IE HTTP Debugger may become capable of reading the HTTP Response headers before they are parsed or may be it wont. The answer lies in the future.

Until then CIAO!

        Windows 8 was RTM’d last week and as a curious soul I upgraded to RTM. Once done, I was loading my machine with all the tools that I use everyday. This includes the networking tools like Network Monitor and WIRESHARK. Both have their own advantages. I was able to install Network Monitor without any issues. However, I ran into problem when I was trying to install WIRESHARK on Windows 8. I was always greeted with the following error:

WinPCap installer error on Windows 8

Go to this page to download the WIRESHARK Installer: WIRESHARK

Running it as administrator doesn’t help either. Well, selecting either of the options won’t help. So here is what we need to do.

Solution

        It’s a simple solution. We need to run the WinPCap installer in Windows 7 compatibility mode. Most of you would have got this hint. For those who haven’t please refer the below instructions.

        I am going to use 7-Zip to simplify our approach. You could download it from here: Download 7-Zip. I am using 7-Zip as it allows to extract contents from a installer file.

1. Install 7-zip and extract the WinPCap installer file to any other folder on to your disk. If you open the archive, you can see the WinPCap installer file as shown below:
   
2. Right click the exe and select Properties.
3. Go to the Compatibility tab.
4. Click on “Change Setting for all users”
5. Select the check box “Run this program in compatibility mode for” and select Windows 7 from the drop down as shown below:
   
6. Also check the option to run this program under the privilege of an administrator.
7. Click on Ok and then run WinPCap installer again. You will again see a warning as we saw earlier.
8. Click the 2nd option “Run the program without getting help”, this will take you through the rest of the installation.

Voila! It is installed successfully.

The same has been suggested as a solution in the WIRESHARK discussion forums too. I have outlined the steps for simplicity.

One of the biggest problems with IIS on the previous versions of IIS was in regards to scalability. This restriction was at the OS level at the kernel mode. There is nothing much that we could do to address this in IIS. One cannot bind more than one Certificate to a combination of <IP:Port>. The workarounds were:

None of this was an ideal workaround. You could read more about this restriction here:
http://blogs.msdn.com/b/anilpras/archive/2012/05/23/server-certificate-bindings-and-its-restrictions-in-iis-6-0-amp-iis-7-x.aspx

This has been finally addressed in Windows 8 and here are the solutions.

• Server Name Indication or SNI
• Central Certificate Store or CCS

For SNI: http://learn.iis.net/page.aspx/1096/iis-80-server-name-indication-sni-ssl-scalability/

Also refer the Wiki article: http://en.wikipedia.org/wiki/Server_Name_Indication

For CCS: http://learn.iis.net/page.aspx/1091/iis-80-centralized-ssl-certificate-support-ssl-scalability-and-manageability/

The result of this change is that now you would see 2 additional entries under the following registry key as shown below:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters

Let’s discuss these keys a little bit:

1.    SslBindingsInfo:
        This legacy registry key was also present in earlier version of Windows prior to Windows 8. The bindings were of the type IP:Port. Only one certificate could be associated with an entry (or that key) and hence the limitation. We could add multiple SSL bindings by creating multiple combination of IP:Port and then associating each with a SSL Server Certificate.

        The problem was that it was not feasible to have multiple ports open on the server. The ideal choice was always going to be the default SSL 443. So this suggests that we need to have more IP Addresses on the server. In the real world, this is not an acceptable solution and hence we had to use SAN or Wild Card certificates.

2.    SslSniBindingsInfo:
        This isnew inWindows 8 and is not available in previous Windows Versions. The bindings are of the type Hostname:Port. As the previous one, only one certificate could be bound to Hostname:Port key.

       In this case we don’t have to use additional IP Addresses. We can use the hostname present in the certificate and then continue using the default SSL Port 443. Since Hostnames are always unique, 2 bindings could never have the same certificate.

3.    SslCcsBindingsInfo:
        This is new in Windows 8 and was not available in earlier versions of Windows. True SSL Scalability was achieved with this. This reads the certificates from a File Share. There is only one binding for a specific port and you could have multiple Site listening on this binding. The Server certificate is loaded based on hostname section available from the Client Hello at run time. If you try to list out the SSL bindings then this is how it would look:

       This allows you to configure multiple sites on a single binding, as the certificates are loaded at run time. The management of certificates is also easier as we can have multiple certificates read from a central file location. If a certificate expires we can just update the certificate on that particular file share.

I will blog in more detail on how this works with scenarios to help this understand better. There is more to the Central Certificate Store and I will blog multiple posts with more detailed explanation.

You can read more on IIS 8 here:

http://weblogs.asp.net/owscott/archive/2012/03/01/what-s-new-in-iis-8.aspx
http://learn.iis.net/page.aspx/1087/what39s-new-in-iis-80-for-windows-8/
http://technet.microsoft.com/en-us/library/hh831725.aspx

Until then. Adios!

Here is the link: SSL Scalability with IIS 8.

In this blog I will discuss specifically about Server Name Indication aka SNI. We will learn how scalability is achieved through this.

During SSL handshake when the client sends a HTTPS request (Client Hello) to the web server, the HTTP headers are not available to the server. Once the SSL handshake is completed the client will encrypt the headers and send the encrypted HTTP request to the server. Therefore server cannot access the HTTP headers or the content until the request is encrypted. Hence, the problem.

Before decrypting the request the only information available to the server will be the IP Address and the Port number. This is available through the TCP headers as only the HTTP headers are encrypted. This leads to the limitation of only one certificate can be bound to a combination of <IPAddress>:<Port>.

Legacy SSL handshake between client and IIS 7.x and earlier

NOTE: The Public key cryptography is used to decide on a symmetric key (session key), which is then used by the client and the server for both encryption and decryption of the HTTP Headers and the content body. If you realized by now, SSL handshake involves both asymmetric encryption and symmetric encryption. Symmetric encryption is used for encryption of the actual data.

All the SSL bindings on Windows OS prior to Windows Server 2008 R2/Windows 7 can be found under following registry key:

HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslBindingInfo

Even if the client provides the server name in the client hello, the server wasn’t capable of using it. This is addressed in IIS 8. To solve this problem associated with SSL/TLS, IETF added a new TLS extension called Server Name Indication. It is mentioned in the following RFC’s

• RFC 3546– Section 3.1
• RFC 4366– Section 3.1
• RFC 6066– Section 3

You could also read about SNI on Wikipedia.

As mentioned in the above RFC’s a TLS extension called ServerName was introduced to tackle this problem. Below is a snippet from RFC 6066.

East Lake                  Standards Track                      [Page 5]

RFC 6066              TLS Extension Definitions               April 2011

3. Server Name Indication

Now the client can send the hostname it wants to access over https as a part of client hello. This helps the server to associate the client hello to a specific request and thus we overcome the limitation which was imposed earlier.

If you were to capture a network trace of SNI complaint browser accessing a HTTPS site you could see this extension as part of the client hello. I captured a Wireshark trace while accessing https://www.outlook.com. I filtered the trace by SSL and searched for Client Hello.

snapshot of a SSL trace in Wireshark 

***IMPORTANT***

One important thing to note here is that SNI is part of the Client Hello. So it is the client browsers that need to support this extension. Most of the current day browsers support SNI.

However, there are few browsers out there that don’t support SNI. For example, on Windows OS any version of IE running on Windows XP or lower versions do not support SNI. Vista onwards support for SNI was included for IE 7 and higher. There is a good list on Wikipedia on browsers that provide support for SNI. Below is a snippet from Wikipedia:

List of SNI Compliant Browsers:

So far I was trying to explain the basics of SNI. We need to know this to understand the server side solution for this.

NOTE: SNI is available only on IIS 8 and may be future versions. It is not available on any of the previous versions of IIS like IIS 7.x, IIS6 etc.

SNI on IIS 8

IIS 8 supports Server Name Indication. This is enabled by defaultand no separate installation is required. Now while adding a HTTPS binding for a website on IIS 8, the option to enable SNI is available. This is how the UI looks like:

There are 2 things to remember when enabling SNI for a specific site on the server.

• Selecting the above option enforces the site to use SNI i.e., it will expect the client to send a server_name as the part of the Client Hello during SSL handshake. If the server_name extension is not present then the SSL handshake would fail.
• The hostname has to be provided, this is a strict mandate. The server will use this information to associate an incoming request to a specific site.

 How does the IIS know if a specific binding uses SNI?

When a SSL bindings is added for a site, there is also a small change in the configuration file i.e., the applicationhost.config. This is how the binding section looks like:

The highlighted attribute called sslFlagsis. This attribute tells IIS what type of binding it is. This flag can be thought of as a doing an OR operation on 2 variables x and y. Below table would give you a gist of what this flag signifies.

Changes in Registry

In IIS 8 we have a new registry key where all the SNI bindings are stored. I had mentioned this in my previous blog post. This location of this registry key is

HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslSniBindingInfo

Executing the following command “netsh http show sslcert” will read this key and show a formatted output as shown below:

So now we have 3 types of SSL bindings:

1. IP:Port– Legacy SSL binding.
2. Hostname:Port– SSL binding using SNI. (new in IIS 8)
3. Central Certificate Store– SSL binding using Central Certificate Store. I will discuss this in detail in my next blog. (new in IIS 8)

There is a small problem that the administrators have to take care of while configuring SSL bindings to use SNI. If a non-SNI compliant browser connects to a site on which SNI is enforced, as I mentioned earlier the SSL handshake would fail.

To tackle this there is a fall-back mechanism in IIS where the it would try to determine a binding with the combination of IP:Port, if this is not present, then the SSL handshake fails. For this the IIS admin has to configure a binding which neither uses SNI nor CCS.

If legacy binding doesn’t exist, then the IIS UI will throw an alert as shown below. This message is a warning saying that there is no legacy binding, so in case of a failure the SSL handshake would fail.

SSL Handshake between a SNI compliant browser and SNI Compliant Server

Below are the steps involved during SSL handshake between a SNI compliant Client and a site hosted on IIS 8 on which a SSL binding is configured to use SNI.

1. The client and the server establish a TCP connection via TCP handshake.
2. The client sends a Client Hello to the server. This packet contains the specific protocol version, list of supported cipher suites along with the hostname (let’s say www.outlook.com provided its a SNI compliant browser). The TCP/IP headers in the packet contain the IPAddress and the Port number.
3. The server checks the registry (legacy bindings) to find a certificate hash/thumbprint corresponding to the above combination of IP:Port.
4. If there is no legacy binding for that IP:Port, then server uses hostname information available from the Client Hello checks the registry to find a certificate hash corresponding to the above combination of Hostname:Port. The server checks the below key to find the combination:
   HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslSniBindingInfo
5. If the above step fails i.e., if the server couldn’t find a corresponding hostname:port, then it would use the IPAddress available to search for a legacy SSL binding for that IPAddress and PORT. (If this is absent then the SSL handshake would fail)
6. Once it finds a match, the crypto API’s are called to retrieve the Server Certificate based on the thumbprint/certificate hash from the certificate store. The retrieved certificate is then added to the Server Hello and sent to the client.

More Information:

You could refer the following links on additional information on this topic:

http://en.wikipedia.org/wiki/Server_Name_Indication

http://learn.iis.net/page.aspx/1096/iis-80-server-name-indication-sni-ssl-scalability

http://blogs.iis.net/yaminij/archive/2012/06/25/sni-server-name-indication-readiness-tool-draft.aspx

One of my article has been published on IIS.NET on how to troubleshoot SSL related issues. Here is the link:

Troubleshooting SSL related issues (Server Certificate)

There is another article written by my colleague few years ago. Here is the link to that:

http://blogs.msdn.com/b/saurabh_singh/archive/2007/09/05/troubleshooting-ssl-related-issues-with-iis.aspx

Let me know if there are any additional scenarios that you want me address in this.

CIAO!