Local HTTPS for Optimizely, IIS, and Kestrel using certificates (Pt 2)

Bind the certificate to HTTPS in IIS

1. Open IIS Manager.
2. Right-click on your pre-defined site and choose “Edit Bindings…”.
3. Click “Add…”.

Otherwise, create a new site in IIS.

Instructions for IIS 8.0+

1. Change the type to https.
2. Leave the port as 443 unless you want to specifically designate a port number for your HTTPS connection. (If you have multiple sites, they can all use 443 without conflicts based on the next steps.)
3. Enter the hostname. If also using HTTP, make this the same as that entry.
4. Check “Require Server Name Indication”.
   This will force IIS to only accept calls made to your hostname for this website and not “localhost:port” or any variation. This is key to ensuring that multiple sites on the same machine can all use the default 443 for their HTTPS port.

Problem

As more e-commerce sites come on line and more businesses are storing and sharing sensitive documents online, the ability to host and scale secure sites are increasingly more important. Prior to Windows Server 2012, there were a couple of challenges when it comes to hosting secure sites:

SSL Scalability: In a multi-tenanted environment, such as a shared hosting, there is a limitation as to how many secure sites can be hosted on Windows Server, resulting in a low site-density.

IPv4 scarcity: Because the network end-point can only be identified with IP:Port binding, where tenants request to use the standard SSL port, 443, hosting a secure site often means offering a dedicated IP address per tenant.

Solution

On Windows Server 2012, IIS supports Server Name Indication (SNI), which is a TLS extension to include a virtual domain as a part of SSL negotiation. What this effectively means is that the virtual domain name, or a hostname, can now be used to identify the network end point. In addition, a highly scalable WebHosting store has been created to complement SNI. The result is that the secure site density is much higher on Windows Server 2012 and it is achieved with just one IP address.

It should be noted that in order for this feature to be used, your client browsers have to support SNI. Most modern browsers support SNI; however, Internet Explorer (of any version) on Windows XP does not support SNI.

5. Continue down the screen and select your newly created certificate from the dropdown list.
6. Click OK.
7. With the site selected, on the right side of the window click “Browse {yoursite} on :443 (https)” and verify that it is working.

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

Instructions for IIS 7.5 (and earlier)

1. Change the type to https.
2. Designate a specific port for your site.
3. Enter the same hostname as you had for HTTP.
4. Continue down the screen and select your newly created certificate from the dropdown list.
5. Click OK.
6. With the site selected, on the right side of the window click “Browse {yoursite} on :{port} (https)” and verify that it is working.

Secure your Kestrel configuration

"Kestrel": {
    "Certificates": {
      "Default": {
        "Subject": "mydomain.local",
        "Store": "MY",
        "Location": "CurrentUser"
      }
    },
    "Endpoints": {
      "Default": {
        "Url": "http://mydomain.local" // HTTP fall-back
      },
      "SecureLocal": {
        "Url": "https://mydomain.local" // No certificate specified, so it will use the default
      },
      "MySecondDomain": {
        "Url": "https://second.mydomain.local",
        "Certificate": {
          "Subject": "mydomain.local",
          "Store": "MY",
          "Location": "CurrentUser",
          "AllowInvalid": (true or false whether you want to allow invalid certificates)
        }
      }
      "FrontEnd": {
        "Url": "https://mydomain.frontend.local",
        "Certificate": {
          "Subject": "mydomain-frontend.local",
          "Store": "MY",
          "Location": "CurrentUser",
          "AllowInvalid": (true or false whether you want to allow invalid certificates)
        }
      }
    }

• The “SecureLocal” endpoint doesn’t have a certificate specified and it will fall back to the default certificate.
• “MySecondDomain” shows how to set up a sub-domain using the default certificate (in part 1 I showed how to create a certificate with wildcard domains).
• “FrontEnd” shows how to set up a separate site within the same solution that uses a different certificate.
• The “AllowInvalid” setting should be set to “false” if possible. Setting it to true bypasses some of the security features you’re looking to gain by using a certificate.
• If the certificate was stored in the Local Machine instead of Current User, change the “Location” from “CurrentUser” to “LocalMachine”.

Set up HTTPS for your local Optimizely environment