SharePoint ホスト アプリ環境の証明書を作成する

  • Article

こんにちは、SharePoint サポートの 森　健吾 (kenmori) です。
今回の投稿では、SharePoint 用アプリの環境を構築するにあたり、証明書の作成方法について下記質疑応答をふまえてご説明します。

質問事項
下記 Technet の推奨の通り、SharePoint (Contoso.com) と SharePoint 用アプリ (ContosoApps.com) のように構築しました。
この構成では、ブラウザーから SharePoint Web アプリケーションをホストする IIS サイトへのアクセスとして、https://contoso.com と https://apps-xxx.contosoapps.com などの複数ドメインからなる URL が想定されます。
Technet には *.contosoapps.com に対してワイルドカード証明書を発行する旨の記載がありますが、これだと SharePoint 側 (contoso.com) が証明書エラーになります。

タイトル : SharePoint 用アプリの環境を構成する (SharePoint 2013)
アドレス : https://technet.microsoft.com/ja-JP/library/fp161236(v=office.15).aspx

<以下抜粋>
アプリをホストするには、ドメイン ネーム サービス (DNS) に新しいドメイン名を構成する必要があります。セキュリティ向上のために、ドメイン名は SharePoint サイトをホストするドメインのサブドメインにしないでください。たとえば、SharePoint サイトが Contoso.com にある場合は、ドメイン名として App.Contoso.com ではなく ContosoApps.com を使用することを検討してください。

ドメインはワイルドカードの形式 (*.ContosoApps.com など) で追加する必要があります。インストール済みの各アプリには固有のサブドメインがあるため、個々の証明書の代わりにワイルドカード証明書が必要です。

当然、これらの両方のアドレスを発行先にしたワイルド カード証明書は作成できません。Technet に記載されたドメイン名の推奨構成には誤りがありますでしょうか。それとも、何かいい方法があるのでしょうか？

弊社見解

Technet に記載されている通り、SharePoint に対して SharePoint アプリ URL をサブ ドメインにすることは、セキュリティ上の注意事項があります。そのため、弊社はアプリに SharePoint とは全く異なる一意のドメイン名を使用することを推奨します。

一般的に、アプリ URL を SharePoint サイトのサブ ドメインとして設定した場合、悪意のあるアプリによって Cookie 情報が読み取られ、最悪の場合は情報漏えい等の危険性が発生する場合がございます。

タイトル : SharePoint 2013 用アプリを計画する
アドレス : https://technet.microsoft.com/ja-JP/library/fp161237(v=office.15).aspx

<以下抜粋>
そのホスト名で実行する他のアプリケーションに、 Cookie に格納された機密情報があり、それが保護されていない可能性があるからです。コードでは、同じドメインの下にある異なるドメインの間で Cookie を設定したり読み取ったりすることができます。悪意のある開発者が、SharePoint 用アプリのコードを使用して、SharePoint 用アプリのサブドメインからルート ドメインにある Cookie の情報を設定したり読んだりする可能性があります。悪質なアプリがその Cookie 情報にアクセスした場合、情報が漏えいする恐れがあります。

Internet Explorer では、SharePoint サイトが使用している設定を適用することで、この問題に対応します。ただし、それでも、他のドメインから分離したドメインをアプリに使用することをお勧めします。たとえば、SharePoint サイトが Contoso.com にある場合は、Apps.Contoso.com を使用しないようにします。代わりに、Contoso-Apps.com のような一意の名前を使用します。これは、サブドメインを使用するビジネス上の理由がある場合でもサブドメインを使用してはならない、という意味ではありません。ただし、可能性のあるあらゆるセキュリティ リスクを検討してください。

これらの状況から、お客様環境に存在する情報を保護するためにも、アプリ URL のドメインを SharePoint URL のドメインと異なる一意のものにして保護することをお勧めします。

補足

SharePoint Online では、ワイルドカード証明書 *.sharepoint.com を使用して公開しています。
これは上記の推奨構成に反し、SharePoint 側が tenant.sharepoint.com 、アプリ側が apps-*.sharepoint.com という形式にて、第 2 層までのアドレス (*.sharepoint.com) を共通の構成としています。
SharePoint Online では、この構成で公開するにあたり Cookie を明示的に保護するなど、SharePoint On Premises に対して実装していない最善のセキュリティ対策を別途組み込んでいます。

マイクロソフトでは、共通のドメイン名を含める構成を完全に禁止する立場はとっていません。
ただし、セキュリティ リスクを最小限に防ぐためには、ワイルドカード証明書に合わせて SharePoint およびアプリのドメインを構成するよりも、推奨構成のように SharePoint およびアプリのドメイン名を異なるもので構成した上で、下記の通りサブジェクト代替名を指定した新しいワイルドカード証明書を発行するほうが堅牢となります。

 

対処策

証明書にサブジェクト代替名 (Subject Alternative Name (略. SAN)) を指定して発行することで、1 枚の証明書で SharePoint およびアプリ URL の双方を信頼させることができます。
以下にエンタープライズ証明機関 (CA) によるドメイン証明書を作成して使用する構築手順の一例を記載します。 


(証明書をダブルクリックで開き、[詳細] タブを見た際の表示)

1. SharePoint Server において証明書の要求ファイル (*.req) を作成する

1. [ファイル名を指定して実行] にて certmgr.msc を実行します。
2. "個人" - "証明書" と展開し、"証明書" で右クリックし [すべてのタスク] - [詳細設定操作] - [カスタム要求の作成] をクリックします。
3. ウィザードで、[次へ] をクリックします。
4. "カスタム要求" - "登録ポリシーなしで続行する" を選択し、[次へ] をクリックします。
5. "テンプレート" で "(テンプレートなし) レガシ キー" を選択し、"要求の形式" を "PKCS #10" として、[次へ] をクリックします。
6. "証明書情報" にて、カスタム要求の [詳細] をクリックして展開し、[プロパティ] をクリックします。
7. "証明書のプロパティ" ダイアログにて、最初に [秘密キー] タブをクリックします。
8. "キーの種類" を展開し、"Exchange" を選択します。
9. "キーのオプション" を展開し、キーのサイズを 4096 と指定します。(任意で構いませんが一般的な推奨は 4096 以上となります。)
10. "秘密キーをエクスポート可能にする" にチェックを入れます。
11. "証明書のプロパティ" ダイアログにて、次に [拡張機能] タブをクリックします。
12. "拡張キー使用法" を展開し、"サーバー認証" を選択して [追加 > ] をクリックします。
13. "証明書のプロパティ" ダイアログにて、次に [サブジェクト] タブをクリックします。
14. "サブジェクト名" セクションにて "共通名" を選択し、"値" にプライマリ ドメイン名 (例. contoso.com) を指定して [追加 > ] をクリックします。
15. "別名" セクションにて、"種類" に "DNS" を指定し、値にアプリ ドメインをワイルドカード付で指定 (例. *.contosoapps.com) します。
16. 複数種類の別名を用意したい場合は、上記手順 15 を繰り返します。

 

17. "証明書のプロパティ" ダイアログにて、最後に [全般] タブをクリックします。
18. "フレンドリ名" に証明書の区別しやすい名前を指定します。
19. [OK] をクリックします。
20. "証明書の登録" ウィザードに戻り [次へ] をクリックします。
21. [参照...] ボタンをクリックして、*.req ファイルの保存先として任意の場所を指定します。
22. [完了] をクリックします。

2. エンタープライズ CA の前提条件を設定する

1. エンタープライズ CA 端末にログインします。
2. サーバー マネージャにて [役割] を選択し、[役割サービスの追加] をクリックします。
3. "証明機関 Web 登録" がインストールされていない場合は追加ください。
4. コマンド プロンプトを管理者で起動します。
5. 以下のコマンドを実行して、サブジェクト代替名の設定を許可する構成を行います。

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

3. エンタープライズ CA にて要求ファイルから証明書を作成する
1. 証明機関 Web 登録の画面 (https://adcsserver/certsrv) にアクセスします。
2. [証明書を要求する] をクリックします。
3. [証明書の要求の詳細設定] をクリックします。
4. [Base 64 エンコード CMC または PKCS #10 ファイルを使用して証明書の要求を送信するか、または Base 64 エンコード PKCS #7 ファイルを使用して更新の要求を送信する。] をクリックします。
5. 手順 1. で作成した *.req ファイルをテキストエディタで開き、内容を"保存された要求" のテキストエリアにすべて貼りつけます。
6. "証明書テンプレート" に "Web サーバー" を指定します。
7. [送信 >] をクリックします。
8. Base 64 エンコードされた証明書をダウンロードしてください。

4. 証明書を IIS にインポートし、IIS サイトにバインドする
1. ダウンロードした証明書を任意の場所にインストール (例. 個人) します。
2. certmgr.msc を開き、インストールされた証明書を右クリックし、[すべてのタスク] - [エクスポート] をクリックします。
3. "証明書のエクスポート ウィザード" にて [次へ] をクリックします。
4. "はい、秘密キーをエクスポートします" を選択し、[次へ] をクリックします。
5. "エクスポート ファイル形式" にて [次へ] をクリックします。
6. "パスワード" にチェックを入れ、パスワードを設定します。
7. 証明書のエクスポート先を指定して [次へ] をクリックします。
8. [完了] をクリックします。
9. IIS にアクセスします。
10. Web サーバーを選択し、[サーバー証明書] をダブルクリックして開きます。
11. [インポート] をクリックして、上記手順 8. までに取得した *.pfx ファイルをインポートします。

ここでインポートした証明書を IIS Web サイトのバインドにご指定ください。

補足
上記の操作はエンタープライズ CA を使用した対処策となりますので、インターネット上でサブジェクト代替名 (SAN) を使用した証明書を発行する方法については、ご利用いただく証明機関にお問い合わせください。

今回の投稿は以上になります。