Share via

サービス通信証明書

  • [アーティクル]

フェデレーション サーバーは、WCF メッセージ セキュリティを使用するシナリオでサービス通信証明書を使用する必要があります。

サービス通信証明書の要件

サービス通信証明書が AD FS で機能するには、次の要件を満たす必要があります。

  • サービス通信証明書には、サーバー認証拡張キー使用法 (EKU) 拡張機能が含まれる必要があります。

  • サービス通信証明書からルート CA 証明書までのチェーン内のすべての証明書について、証明書失効リスト (CRL) にアクセスできる必要があります。 このフェデレーション サーバーを信頼するすべてのフェデレーション サーバー プロキシと Web サーバーでは、ルート CA も信頼している必要があります。

  • サービス通信証明書で使用されるサブジェクト名は、フェデレーション サービスのプロパティ内のフェデレーション サービス名と一致している必要があります。

サービス通信証明書の展開に関する考慮事項

すべてのフェデレーション サーバーが同じ証明書を使用するように、サービス通信証明書を構成します。 フェデレーション Web シングル サインオン (SSO) 設計を展開する場合は、パブリック CA によって発行されたサービス通信証明書を使用することをお勧めします。 そのような証明書は、IIS マネージャー スナップインで要求してインストールできます。

テスト ラボ環境のフェデレーション サーバーでは、自己署名されたサービス通信証明書を問題なく使用できます。 ただし、運用環境では、パブリック CA からサービス通信証明書を取得することをお勧めします。

ライブ展開に自己署名されたサービス通信証明書を使用してはならない理由は次のとおりです。

  • 自己署名 SSL 証明書は、リソース パートナー組織内の各フェデレーション サーバーの信頼されたルート ストアに追加する必要があります。 自己署名証明書だけでは攻撃者がリソース フェデレーション サーバーを侵害できるようにはなりませんが、自己署名証明書を信頼すると、コンピューターの攻撃対象領域が増えます。 証明書署名者を信頼できない場合は、セキュリティの脆弱性につながる恐れがあります。

  • 自己署名されたサービス通信証明書により、ユーザー エクスペリエンスが悪化します。 クライアントがフェデレーション リソースにアクセスしようとすると、セキュリティ アラート プロンプトを受け取り、次のようなメッセージが表示されます: "このセキュリティ証明書は、信頼する会社から発行されていません"。自己署名証明書は信頼されていないので、これは予期されるメッセージです。

    Note

    必要な場合は、グループ ポリシー を使用して、AD FS サイトへのアクセスを試みる各クライアント コンピューター上の信頼されたルート ストアに、自己署名証明書を手動で格納することで、この状況を回避できます。

  • CA には、秘密キーのアーカイブ、更新、失効など、自己署名証明書では提供されない、証明書ベースの追加機能が用意されています。