Using IP SSL

 

Applies To: Windows Azure Pack

Warning

If you have implemented IP based SSL using VIP Mapping or Local Address Mappings with IPv6 addresses please do not upgrade to Windows Azure Pack: Websites Update 6 unless you migrate to IPv4 before applying the update. This scenario is not supported in this update however will be supported in a future update.

IP SSL is a certificate security mode for clients (old browsers, operating systems, or mobile devices) that do not support Server Name Indication. In this mode, a certificate for a specific DNS hostname is mapped to a dedicated virtual IP address.

In Windows Azure Pack: Websites, a number of specific steps occur when a user performs IP SSL related actions in the management portal for tenants:

  1. When a user uploads a certificate within the portal, the portal validates the certificate file (pfx) provided, and saves it to the database as an encrypted byte array (blob).

  2. When a user enables IP SSL within the portal for a specific hostname, Windows Azure Pack: Websites:

    1. Retrieves the certificate’s pfx blob from the database, secures it with a new password, and uploads the pfx file into a folder accessible to every IIS on every FrontEnd server.

    2. Creates a matching IP address and port number IIS binding for that specific hostname on every FrontEnd server.

    If an external upfront load balancer is used to load balance traffic between the FrontEnd servers, Windows Azure Pack: Websites:

    1. Maps a dedicated public virtual IP address on the external upfront load balancer to every IP address and port binding related to this hostname.

    2. Returns a public virtual IP address to the end users so they can update their DNS records.

Important

Windows Azure Pack: Websites Update 4 implements step 2 differently than Update 6. If your Update 4 environment already has sites with IP SSL enabled, read all sections in this document. If you are implementing IP SSL for the first time with Update 6, read the sections “VIP Mappings vs Local Address Mappings”.

VIP mappings vs local address mappings

There are two ways to map DNS host names: virtual IP address (VIP) mappings and local address mappings.

From a tenant point of view local address mappings will look the same as VIP mappings. Details of how traffic is load balanced between FrontEnd servers are not exposed to the tenants, they only see the virtual IP address to use in DNS record.

VIP mappings

In IP SSL mode, a certificate for a specific DNS hostname is mapped to a dedicated virtual IP Address. However, for IP SSL to work, dedicated and unique addresses must use IP sockets, represented by IP address and port number combinations, not just the IP address. All browsers and other client software use port 443 for SSL by default. Therefore, Windows Azure Pack: Websites must use the default port 443 combined with a unique IP address when the address is exposed publically. Therefore internally, behind a load balancer it is possible and more convenient to use non-standard ports combined with private IP addresses.

If the FrontEnds are behind an upfront load balancer, the only supported method is to use unique virtual IP addresses with port 443 on the upfront load balancer and map it to non-standard ports (not 443) on the FrontEnds. This is called VIP Mappings.

VIP mappings example

Public DNS records

IP address

Hostname

192.168.1.101

Hostname1

192.168.1.102

Hostname2

Upfront load balancer mappings

VIP

Maps to

192.168.1.101:443

10.1.1.1:3001

10.1.1.2:3001

10.1.1.3:3001

192.168.1.102:443

10.1.1.1:3002

10.1.1.2:3002

10.1.1.3:3002

FrontEnd1 IIS bindings

IP address and port number

Hostname

10.1.1.1:3001

Hostname1

10.1.1.1:3002

Hostname2

FrontEnd2 IIS bindings

IP address and port number

Hostname

10.1.1.2:3001

Hostname1

10.1.1.2:3002

Hostname2

FrontEnd3 IIS bindings

IP address and port number

Hostname

10.1.1.3:3001

Hostname1

10.1.1.3:3002

Hostname2

The WAP Administrator must create mappings between external the Load Balancer VIP with port 443 and the private FrontEnd IP addresses and non-standard ports. In this example all traffic that comes to 192.168.1.1:443 must be forwarded to all FrontEnds with private IP addresses and port 3001.

Note that the Windows Azure Pack administrator can use a non-standard port for http traffic and configure the upfront load balancer to forward all traffic that came to 192.168.1.1:80 to all FrontEnds with private IP addresses port 4001 (for example). Windows Azure Pack: Websites will create the IIS binding and serve that traffic.

After the mapping has been configured on the upfront load balancer, the cluster IP addresses must be entered in the IP SSL section of the management portal for administrators as per the instructions in the Configure Windows Azure Pack: Web Sites.

The tenant can see the virtual IP Addresses in use for the domain name associated with their Website by selecting View Virtual IP Addresses on the dashboard tab in the tenant portal as illustrated in the diagram below.

Local address mappings

For FrontEnds that are addressable from the Internet, IIS bindings with public virtual IP addresses and port 443 must be created by the administrator on the FrontEnds using the management portal. This is called Local Address Mappings and is illustrated in the table below. The only supported topology is to have the same virtual IP address configured on every FrontEnd for each hostname. Every FrontEnd server must have these VIPs locally configured. To achieve this, a Windows Network Load Balancer (NLB) cluster must be deployed and all FrontEnd servers must be joined to it. All virtual IP addresses for use with IP SSL must be added as cluster IP addresses.

Local address mapping addressable from the internet

Public DNS records

IP address

Hostname

192.168.1.101

Hostname1

192.168.1.102

Hostname2

Windows NLB cluster members

FrontEnd1 IIS bindings

IP address and port number

Hostname

192.168.1.101:443

Hostname1

192.168.1.102:443

Hostname2

FrontEnd2 IIS bindings

IP address and port number

Hostname

192.168.1.101:443

Hostname1

192.168.1.102:443

Hostname2

FrontEnd3 IIS bindings

IP address and port number

Hostname

192.168.1.101:443

Hostname1

192.168.1.102:443

Hostname2

The administrator must create a Windows NLB cluster and add a number of cluster IP addresses equal to the number of internet-facing IP addresses that can be used for IP SSL bindings. Then, all FrontEnds must be joined to the new Windows NLB cluster.

After clustered IP addresses have been configured, they must be entered in the IP SSL section of the management portal for administrators as per the instructions in the article Configure Windows Azure Pack: Web Sites.

Local address mapping with a single FrontEnd

For non-production environments or for environments that do not require high availability, local address mapping can be achieved with a single FrontEnd.

Local address mapping with a single FrontEnd

Public DNS records

IP address

Hostname

192.168.1.101

Hostname1

192.168.1.102

Hostname2

FrontEnd1 IIS bindings

IP address and port number

Hostname

192.168.1.101:443

Hostname1

192.168.1.102:443

Hostname2

IP SSL recommendations

Use the following recommendations to decide which IP SSL topology is best for your deployment.

IP SSL method

Use for

VIP mapping (recommended)

High traffic, enterprise-level deployments with high availability requirements.

Local address mapping

Low to mid-range traffic deployment workloads.

Single FrontEnd

Lab and proof-of-concept deployments only.

IP SSL differences between Update 4 and Update 6

The differences between the Update 4 and Update 6 implementations of IP SSL are enumerated in the following sections.

Update 4 IP SSL implementation

  1. Pfx certificate files were stored on a central share available to FrontEnd servers.

  2. IIS IP address and port number bindings created for specific a hostname on every FrontEnd were not guaranteed to use the same port or IP address. For example, in the diagram “Port-based bindings – V2U4”, in hostname 1 both ports 3001 and 3302 are used on different FrontEnds.

  3. The topology for local addresses with port 443 on FrontEnds behind upfront load balancers was supported (see “Local address behind upfront load balancer – pre V2U6” diagram). It is not supported in Update 6 or later.

  4. The topology for local addresses with port 443 on FrontEnds with IP addresses addressable from the Internet was supported (see “Local address routable from Internet – pre V2U6” diagram). This is still supported in Update 6 but requires migration to Windows NLB or use of single FrontEnd.

  5. In Update 4, when an upfront load balancer is used, the Windows Azure Pack system administrator must modify an extensibility script to configure the upfront load balancer mappings between a single VIP and multiple IP SSL bindings on the FrontEnds. For example, the “VIP Mappings – pre V2U6” table below shows mappings between VIP 192.168.1.101:443 and 10.1.1.1:3001, 10.1.1.2:3002, 10.1.1.3:3001. Those mapping were not pre-created on upfront load balancer in update 4. The Administrator had to modify an extensibility script, specifically for the upfront load balancer, and this script created new mappings on the upfront load balancer every time user enabled IP SSL in tenant portal.

    The extensibility script was called by Windows Azure Pack when an IP SSL enabled hostname and IIS bindings are configured on the FrontEnds. Binding data (IP addresses and ports) and hostnames were passed as parameters to the script. Script code (authored by Administrator) took those parameters and created upfront load balancer mappings using script language or API methods understandable by specific upfront load balancer.

Update 6 IP SSL implementation

  1. Pfx certificates are stored in a local folder on every FrontEnd server.

  2. Mappings between external load balancer VIPs and IIS bindings on FrontEnds must be created by the administrator before users start enabling IP SSL for their hostnames. This is a fundamental difference with Update 4. VIP mappings must be created ahead of use as opposed to being called by an on-demand script.

    For example, in the table “VIP Mappings – After Upgrade to V2U6” the mapping between VIP 192.168.1.101:443 and port 3001 on all FrontEnds is created by the administrator on the upfront load balancer. Then the VIP mappings must be entered into management portal for administrators in order for WAP to allocate VIP mapping to every hostname with IP SSL enabled.

  3. Because of the VIP mapping concept, at the IIS binding level the ports (and in the case of Windows NLB IP addresses) are guaranteed to be the same for specific hostname.

IP SSL upgrade examples

Your IP SSL examples will be automatically upgraded from Update 4 to functionality to Update 6 functionality as described below.

Example 1

The scenario illustrated in the table “VIP mappings –before Update 6” will be upgraded to the scenario illustrated in the “VIP mappings – after Upgrade 6” table.

VIP mappings – before Update 6

Public DNS records

IP address

Hostname

192.168.1.101

Hostname1

192.168.1.102

Hostname2

Upfront load balancer mappings

VIP

Maps to

192.168.1.101:443

10.1.1.1:3001

10.1.1.2:3002

10.1.1.3:3001

192.168.1.102:443

10.1.1.1:3002

10.1.1.2:3003

10.1.1.3:3002

FrontEnd1 IIS bindings

IP address and port number

Hostname

10.1.1.1:3001

Hostname1

10.1.1.1:3002

Hostname2

FrontEnd2 IIS bindings

IP address and port number

Hostname

10.1.1.2:3002

Hostname1

10.1.1.2:3003

Hostname2

FrontEnd3 IIS bindings

IP address and port number

Hostname

10.1.1.3:3001

Hostname1

10.1.1.3:3002

Hostname2

VIP mappings – after Update 6

Public DNS records

IP address

Hostname

192.168.1.101

Hostname1

192.168.1.102

Hostname2

Upfront load balancer mappings

VIP

Maps to

192.168.1.101:443

10.1.1.1:3001

10.1.1.2:3002 -> 10.1.1.2:3001

10.1.1.3:3001

192.168.1.102:443

10.1.1.1:3002

10.1.1.2:3003 -> 10.1.1.2:3002

10.1.1.3:3002

FrontEnd1 IIS bindings

IP address and port number

Hostname

10.1.1.1:3001

Hostname1

10.1.1.1:3002

Hostname2

FrontEnd2 IIS bindings

IP address and port number

Hostname

10.1.1.2:3002 -> 3001

Hostname1

10.1.1.2:3003 -> 3002

Hostname2

FrontEnd3 IIS bindings

IP address and port number

Hostname

10.1.1.3:3001

Hostname1

10.1.1.3:3002

Hostname2

In the tables above, before the upgrade different ports were used across IIS bindings for a specific hostname on all FrontEnd servers. Therefore, the upgrade script chose the most often used ports (3001 for hostname1 and 3002 for hostname2) and created a VIP mapping to use them.

The old configuration assumed different ports would be used on FrontEnd2. After the upgrade, FrontEnd2 is reconfigured and ready to serve IP SSL for hostname1 on port 3001 and for hostname2 on port 3002.

The only step remaining is to reconfigure the upfront load balancer to correctly forward traffic:

  • From 192.168.1.1:443 to 10.1.1.2:3001.

  • From 192.168.1.2:443 to 10.1.1.2:3002.

The upfront load balancer already has the correct load balancing settings for those VIP regarding other FrontEnds.

Example 2

The scenario illustrated in the table “Local address mapping addressable from the internet – before Update 6” will be upgraded to the scenario illustrated in the “Local address mapping addressable from the internet – after Update 6” table.

Local address mapping addressable from the internet – before Update 6

Public DNS records

IP address

Hostname

192.168.1.101

Hostname1

192.168.1.103

Hostname1

192.168.1.105

Hostname1

192.168.1.102

Hostname2

192.168.1.104

Hostname2

192.168.1.106

Hostname2

FrontEnd1

VIP

Hostname

192.168.1.101:443

Hostname1

192.168.1.102:443

Hostname2

FrontEnd2

VIP

Hostname

192.168.1.103:443

Hostname1

192.168.1.104:443

Hostname2

FrontEnd3

VIP

Hostname

192.168.1.105:443

Hostname1

192.168.1.106:443

Hostname2

Local address mapping addressable from the internet – after Update 6

Public DNS records

IP address

Hostname

192.168.1.101

Hostname1

192.168.1.102

Hostname2

Windows NLB cluster

FrontEnd1

IP address and port number

Maps to

192.168.1.101:443

Hostname1

192.168.1.102:443

Hostname2

FrontEnd2

IP address and port number

Maps to

192.168.1.103:443 -> 192.168.1.101:443

Hostname1

192.168.1.104:443 -> 192.168.1.102:443

Hostname2

FrontEnd3

IP address and port number

Maps to

192.168.1.105:443 -> 192.168.1.101:443

Hostname1

192.168.1.106:443 -> 192.168.1.102:443

Hostname2

In the tables above, before the upgrade each FrontEnd uses a different IP address. All IP addresses are addressable from Internet and the administrator must create a DNS record for each.

The upgrade procedure chooses a single IP address for a specific hostname and removes all others. After the upgrade only FrontEnd1 can serve IP SSL requests for hostname1 and hostname2.

After the upgrade, the administrator must manually:

  • Remove any unneeded DNS records.

  • Add a Windows NLB cluster and required cluster IP addresses.

Unsupported scenario for upgrade

The scenario illustrated in the table below “Local address behind upfront load balancer – before Update 6” is not supported for upgrade. It is recommended that you manually migrate to “VIP Mappings – before Update 6” before you upgrade.

Local address behind an upfront load balancer – before Update 6

Public DNS records

IP address

Hostname

192.168.1.101

Hostname1

192.168.1.102

Hostname1

Upfront load balancer

VIP

Maps to

192.168.1.101:443

10.1.1.1:443

10.1.1.2:443

10.1.1.3:443

192.168.1.102:443

10.1.1.11:443

10.1.1.12:443

10.1.1.13:443

FrontEnd1

IP address and port number

Maps to

10.1.1.1:443

Hostname1

10.1.1.11:443

Hostname2

FrontEnd2

IP address and port number

Maps to

10.1.1.2:443

Hostname1

10.1.1.12:443

Hostname2

FrontEnd3

IP address and port number

Maps to

10.1.1.3:443

Hostname1

10.1.1.13:443

Hostname2