連載：コードから触るIIS 8

Webファームによる負荷分散（3）：HTTPSとWebファームの関連

Web Technology IIS 8 IIS 8.5 PowerShell

2014年9月16日

IISで構築したWebファーム内における複数台のサーバーでHTTPSを有効にする場合、どんな方法があるのか？各方法によるサーバー構成を、PowerShellを用いて行う方法を解説する。連載最終回。

株式会社グラニ　田中孝佳

　前回の記事では、Webファームのさまざまな機能を紹介した。今回は連載の最後として、HTTPSとWebファームの関連について紹介したい。引き続き前回までに構築したWebファームのサーバーを使って説明を進めていく。

WebファームとHTTPS

　Webファームに限らず、複数台のサーバーを水平分散している状況でHTTPSを有効にする場合、HTTPSの復号処理をどこで行うかを考慮する必要がある。

　1つは、ロードバランサーなど1台で全ての復号処理を行う方法である（図1の左側）。この場合、復号処理の負荷はこのサーバーに集中する。さらにこのサーバーからバックエンドのサーバー間は平文にあるため、プライベートネットワークなど通信経路自体が信頼できるものでないといけない。SSLアクセラレーターによる高速化などもこのパターンになる。

　もう1つは、バックエンドの全てのサーバーで個々のリクエストの復号処理を行う方法である（図1の右側）。このパターンの場合、バックエンドのサーバーそれぞれに復号の負荷がかかる。また、通信経路上はバックエンドのサーバーまで暗号化されている。

図1　復号処理を行う場所による違い（左：1台で全て処理する方法、右：全てのサーバーで処理する方法）

　この記事では、まず前者のパターンとしてリバースプロキシするサーバー（構築した3台のうちwebfarm-ctrlサーバー）で、SSL復号処理を行うように機能追加をしてみる。また、後者のパターンとして、Server Name Indication（SNI）とCentral Certificate Store（CCS）について説明する。

SSL証明書の入手

　実際にHTTPSを有効にするためには、SSLサーバー証明書が必要である。検証目的では自己署名の証明書でもよいが、実際に運用する場合には認証局から発行してもらう必要があり、大抵の場合、有償である。しかし、Class1のSSLサーバー証明書であれば、StartSSLというサービスを使うと無償で発行できる。このサービスは、ドメインもしくはeメールによる認証が必要で、認証局が確認しているのもその情報のみである。

　今回の記事で使った証明書も、このサービスを使って発行したもので、筆者が保持しているドメイン「tanaka733.net」のサブドメイン「secureapp.tanaka733.net」に対して発行したものである。以降の手順を実際に試す場合は、適宜読者が使う証明書のドメインに読み替えてほしい。

SSLサーバー証明書の展開

　では、実際にwebfarm-ctrlサーバーにSSLサーバー証明書を配備して、HTTPSを有効にしてみよう。

SSLサーバー証明書のインポート

　まず、入手した証明書をwebfarm-ctrlサーバーの適当な場所に配置する（以下のスクリプトでは、「C:\secureapp.tanaka733.net.p12」フォルダー内に置いている前提で書いている）。配置したら、以下のPowerShellスクリプトを実行して証明書をインポートしてほしい。

PowerShell

$pwd = ConvertTo-SecureString -String "P@assw0rd" -Force -AsPlainText

Import-PfxCertificate –FilePath "C:\secureapp.tanaka733.net.p12" Cert:\LocalMachine\My -Password $pwd

SSLサーバー証明書をインポートするPowerShellスクリプト

　証明書の一覧は、次のコマンドレットで確認できる。

PowerShell

Get-ChildItem -Path Cert:\LocalMachine\My

証明書一覧を確認するPowerShellスクリプト

HTTPSの有効化： HTTPS用バインディングの作成

　次に、webfarm-ctrlサーバーのIISのWebサイトに、HTTPS用のバインディングを作成する。これもPowerShellで作成できる。

　前回使ったWebサイトが「Default Web Site」という名前であるため、このWebサイトに対してバインディングを追加する。HostHedaerオプションは任意であるが、SSL証明の仕組み上、このホスト名以外でのアクセスは警告あるいは拒否される。SslFlagsオプションは後述のSNI、CCSに関連するため、そこで説明する。

PowerShell

New-WebBinding -name "Default Web Site" -Protocol https -Port 443 -HostHeader "secureapp.tanaka733.net" -SslFlags 0

既存の「Default Web Site」に対してHTTPSでポートが標準の443でリッスンするバインディングを作成するコマンド

　この状態でIISマネージャーの「Default Web Site」のバインディングが追加されているはずである。が、追加されたバインディングを開くと（以下の画面）、証明書が選択されていないのが分かる。

2の［バインド］をクリック

▼

図2　webfarm-ctrlサーバーのIISマネージャーを起動し、「Default Web Site」を選択したところ

HTTPだけでなく、HTTPSのバインディングが追加されているのが分かる（1）。［バインド］リンク（2）をクリックすると、［サイトバインド］ダイアログが表示される。ここで「https」をダブルクリックすると、［サイトバインドの編集］ダイアログが開き、［SSL 証明書］欄が「未選択」になっているのが分かる。

　ここで分かるように、SSL証明書はサイトバインディングに対して設定する。先ほどの［サイトバインドの編集］ダイアログからも選択できるが、以下のPowerShellスクリプトでも設定できる。

PowerShell

$Cert=Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*secureapp*"} | Select-Object -ExpandProperty Thumbprint

New-Item -Path IIS:\SslBindings\!443!secureapp.tanaka733.net -Thumbprint $Cert

作成したHTTPSのバインディングに対し、インポートした証明書を割り当てるスクリプト

最初のコマンドの“*secureapp*”という条件指定のように、インポートした証明書のドメインを指定するなどして、目的の証明書のみが選択されるようにする。
2行目のコマンドのpathパラメーターの「!443!secureapp.tanaka733.net」は、バインディングの「＜IPアドレス＞!＜ポート番号＞!＜HostHeader＞」という形式で指定する。この場合、IPアドレスを指定していないため空文字になっている。また、通常、バインディングは「:」を区切り文字として使うが、PowerShellで指定する場合は「!」を区切り文字として使う。

　これでHTTPSが有効になったが、アクセスする前にSSLオフロードが有効になっているかを確認しておこう。

SSLオフロード有効化の確認

　IISマネージャーの左側のツリーから「Server Farm」の「webfarm-ctrl.cloudapp.net」を選択し、中央のページにある［Routing Rules］を開いて［Enable SSL offloading］チェックボックスにチェックが付いていることを確認してほしい（図3）。付いていなければ、チェックを入れて、右側の［操作］ペインにある［適用］リンクをクリックする。これにより、SSLオフロードが有効になる。

図3　IISマネージャーのServer Farmのwebfarm-ctrl.cloudapp.netにあるRouting Rulesを開いたところ

　SSLオフロードを有効にすることで、リバースプロキシ元のwebfarm-ctrlサーバーでSSLの復号処理を行うようになる。そのため、リバースプロキシ先のwebfarm-nodeサーバーでは、HTTPSの設定をしない、今の状態のままで接続できるようになる。

HTTPSによる接続テスト

　それでは、実際に接続してみよう。

　HTTPSのバインディングで指定している「https://secureapp.tanaka733.net/」にブラウザーから接続してみると、HTTPS接続できていることが確認できる（図4）。

図4　「https://secureapp.tanaka733.net/」に接続し、アドレスバーのロックアイコンを選択したところ

認証されているサイトに暗号化してアクセスしていることが確認できる。

Server Name Indication（SNI）とCentral Certificate Store（CCS）

　全てのHTTPSの復号処理を1カ所で処理しきれない場合、リバースプロキシ先の各サーバーで復号処理を行うという方法を取ることができる。このような環境で必要なのが、「名前ベースのバーチャルホストでの証明書のバインディング」と「複数サーバーでの証明書の管理」である。これらの目的のために、IIS 8から導入されたのが、「Server Name Indication」（以下、SNI）と「Central Certificate Store」（以下、CCS）である。

SNIとは

　SNIは、RFC4366で定められているTLS拡張オプションである。IPアドレスとポートで証明書をバインディングするのではなく、名前ベースで、ホストヘッダーで指定されたホスト名に対してバインディングできる。

　SNIにより、リバースプロキシ先の複数のサーバーに対し、1つのホスト名で作成した証明書をバインディングさせることができる。また、1つのIPしか持たないサーバー上のIISに構築した複数のWebサイトに対して、それぞれ異なるホストヘッダーでバインディングさせることにより、それぞれのホストに対応した証明書でバインディングさせることができる。

　前者は負荷の高いサイトを複数のサーバーで、後者は負荷の低い複数のサイトを1つのサーバーで管理できるようになり、柔軟なリソースの利用が可能になる。

CCSとは

　これに対し、CCSは同じ証明書を複数のサーバーに適用させたい場合に、その管理を一元化させ、管理しやすくする機能である。

　CCSにより、証明書を利用したい全Webサーバーがアクセスできる共有フォルダーに証明書を配置し、管理できる。このとき証明書は、バインディングするホスト名に基づいたファイル名で配置する（例えば「secureapp.tanaka733.net」であれば、「secureapp.tanaka733.net.pfx」というファイル名。「*.tanaka733.net」に対するワイルドカード証明書であれば、「_.tanaka733.net.pfx」というファイル名）。

SNI／CCSを使うためのSslFlagsオプション指定

　さて、SNIやCCSを使う場合には、前述のPowerShellスクリプトで、New-WebBindingコマンドによりHTTPSバインディングを作成したときのSslFlagsオプションを指定する必要がある。このオプションの値は「0」～「3」までを取り、それぞれ次のようになっている。

0： SNIもCCSも使わない
1： SNIのみ使用
2： CCSのみ使用
3： CCSおよびSNIを同時に使用

　これらの値を指定すると、そのバインディングに対してSNIやCCSが利用可能になる（なお、CCSはWindowsの機能からインストールする必要がある）。

■

　以上をもって本連載は終了である。運用の自動化という面からも、コードからIISを管理するという本連載がお役に立てれば幸いである。

※以下では、本稿の前後を合わせて5回分（第7回～第11回）のみ表示しています。
　連載の全タイトルを参照するには、［この記事の連載 INDEX］を参照してください。

11. 【現在、表示中】≫ Webファームによる負荷分散（3）：HTTPSとWebファームの関連

2014年9月16日(火曜日)

連載：コードから触るIIS 8