SharePoint Server 2013 は SSL を構成することが推奨されています。
このバージョンの SharePoint は OAuth 2.0 をサポートしており、Exchange Server (タスク同期など)や Office Web Apps Server, Lync Server, クラウド上の自動翻訳サービス (SharePoint の Machine Translation Services) などと連携する際にこれを使用しますが、そもそも OAuth 2.0 を使う HTTP 通信では SSL を使う必要があります。とはいえ、Exchange Server や Office Web Apps Server と連携させる場合は、SSL をバイパスできるため、SharePoin Server 2013 では必須とまではなっていません。
SSL での通信を行うよう構成した場合、SharePoint 2013 から新たに導入されたSharePoint アプリを利用する際に基盤管理者が悩むのが IIS の証明書の構成です。SharePoint アプリはセキュリティ リスクを考慮し、SharePoint アプリが動作するためのドメインを SharePoint の URL ドメインとは異なるものにするよう構成する必要があります。たとえば、contoso.com というドメイン名を使用している場合は、apps-contoso.com というように、全く異なるドメイン名にします。となると、SharePoint 上でホストされるアプリの場合は、実質的にはアプリを起動したサイトのサブサイトとなり、SSL を通常通り構成していると、証明書エラーの問題が発生します。
日本マイクロソフト社が公開している、Japan SharePoint Support Team Blog では、SharePoint アプリ 用の証明書の作成方法について次の記事で説明しています。
この記事で紹介されているのは、Webサーバーに適用するデジタル証明書にサブジェクト代替名を指定したワイルドカード証明書を使用するというアプローチです。
これ以外のアプローチでは、SharePoint アプリ用に SharePoint Webアプリケーションを新規に作成する必要があり、ホストヘッダー名を付けて構成します。この場合、証明書の構成には、2つ方法があります。
- SharePoint Web アプリケーションをホストする IIS サイトの IPアドレスを、既存のIISサイトのIPアドレスとは異なるものにする
- SharePoint Web アプリケーションをホストする IIS サイトは単一のIPアドレスにし、Server Name Indication を使用する
IIS は複数サイト作成する必要がある場合は、単一のIPアドレス、ポート番号で構成したいしようと思うとホストヘッダーを指定すれば済みます。ところが、SSL の証明書は FQDN ごとに IP アドレスを個別に設定しなければ、サイトごとに異なる証明書を指定することができません。そのため、IPアドレスを IISサイトごとに個別指定する必要があるわけです。しかし、これは IIS 7.5 までの話です。IIS 8.0 以降では、Server Name Indication (SNI) を利用できるようになっているため、単一のIPアドレスであっても対応できるようになっています。
SNI を使う場合は、たとえば、次のような構成が可能です(※私の検証環境がベースです)。
SNI を使用する場合は、上図の通り、IISサイトのバインド編集画面でホスト名を指定した上で、「サーバー名表示を要求する」チェックボックスをオンにします。
この構成例では、それぞれのデジタル証明書のサブジェクトは次のように構成しています。
[SharePoint -80]
[SharePoint - Apps]
ちなみに、Access Services 2013 も SharePoint アプリです。SharePoint アプリをユーザーに利用される必要がある基盤を担当する方々は、こうしたアプローチがあることを念頭に構成していただくとよいと思います。
コメント