証明書の使用
Windows Communication Foundation (WCF) のセキュリティをプログラミングする場合、一般に X.509 デジタル証明書を使用して、クライアントとサーバーの認証、メッセージのエンコード、およびメッセージのデジタル署名を行います。ここでは、証明書の機能および WCF でのそれらの機能の使用方法について簡単に説明します。また、これらの概念の詳細を説明するトピックや、WCF と証明書を使用した一般的なタスクの実行方法が記載されたトピックへのリンクも示します。
簡単に言うと、デジタル証明書は、"公開キー基盤 (PKI: Public Key Infrastructure)" の一部です。PKI は、デジタル証明書、証明機関、およびその他の登録機関から成るシステムです。登録機関では、公開キー暗号化を使用して、電子取引に関与する各当事者の有効性の検証と認証を行います**。証明機関は証明書を発行します。各証明書には、"サブジェクト" (証明書の発行先のエンティティ)、有効期間、発行者、公開キーなどのデータが含まれた一連のフィールドがあります**。WCF では、これらの各プロパティは Claim (クレーム) として処理されます。各クレームは、さらに ID と権限の 2 種類に分けられます。詳細な情報については、次のページを参照してください。 「ID モデルを使用したクレームと承認の管理」を参照してください。PKI 実装詳細については、 、「Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure」を参照してください。
証明書の第一の機能は、他者に対してサブジェクトの ID を認証することです。また、証明書はサブジェクトの "公開キー" を含んでおり、サブジェクトが秘密キーを保持しています**。だれでもこの公開キーを使用してメッセージを暗号化できます。ただし、メッセージを復号化するには両方のキーが必要です。したがって、秘密キーの所有者だけがメッセージを復号化できます。公開キーを使用して、証明書の所有者へのメッセージを暗号化できます。秘密キーにアクセスできるのは所有者だけであるため、所有者だけが暗号化されたメッセージを復号化できます。
証明書は、証明機関によって発行される必要があります。多くの場合、証明機関はサードパーティの証明書発行者です。Windows ドメインでは、そのドメインのコンピュータに対して証明書を発行する際に使用できる証明機関が含まれています。
証明書詳細については、 、「証明書」を参照してください。
証明書の表示
証明書を使用するには、多くの場合、証明書を表示し、プロパティを確認する必要があります。Microsoft 管理コンソール (MMC: Microsoft Management Console) スナップイン ツールを使用すると、これを簡単に行うことができます。詳細な情報については、次のページを参照してください。 「方法 : MMC スナップインを使用して証明書を参照する」を参照してください。ツールの使い方に関する他のドキュメントについては、「Httpcfg の概要」を参照してください。
証明書ストア
証明書はストアに格納されています。2 つの主要なストアがあり、さらにサブストアに分かれています。コンピュータの管理者は、MMC スナップイン ツールを使用して、両方の主要なストアを表示できます。管理者以外のユーザーは、現在のユーザー ストアだけを表示できます。
- ローカル コンピュータ ストア : このストアには、コンピュータ プロセス (ASP.NET など) がアクセスする証明書が格納されます。クライアントに対してサーバーを認証するための証明書は、ここに格納します。
- 現在のユーザー ストア : コンピュータの現在のユーザーの証明書は、通常、対話型アプリケーションによってここに配置されます。クライアント アプリケーションを作成する場合、サービスに対してユーザーを認証するための証明書は、通常、ここに配置します。
上記の 2 つのストアは、さらにサブストアに分かれています。サブストアの中で、WCF でプログラミングするときに最も重要なものは次のとおりです。
信頼されたルート証明機関 : このストア内の証明書を使用して、証明書チェーンを作成できます。証明書チェーンをさかのぼることで、このストア内の任意の証明機関証明書に到達できます。
.gif "ms731899.Important(ja-jp,VS.90).gif")
メモ :証明書が信頼されたサードパーティ証明機関から発行されたものではない場合でも、ローカル コンピュータは、このストアに配置された証明書を暗黙で信頼します。したがって、発行者を完全に信頼し、かつ信頼することの結果を理解していない限り、このストアに証明書を配置しないでください。 個人 : このストアは、コンピュータのユーザーに関連付けられた証明書に使用されます。通常、このストアは、信頼されたルート証明機関ストアにある証明機関証明書のいずれかによって発行された証明書に使用されます。また、自己発行され、アプリケーションから信頼された証明書が格納されている場合もあります。
証明書ストア詳細については、 、「証明書ストア」を参照してください。
ストアの選択
証明書を格納する場所の選択は、サービスまたはクライアントの実行方法や実行する状況によって異なります。次の一般規則が適用されます。
- サービスが Windows サービス (NETWORK SERVICE アカウントでユーザー インターフェイスを表示せずに "サーバー" モードで実行されるサービス) の場合は、ローカル コンピュータ ストアを使用します。ローカル コンピュータ ストアに証明書をインストールするには、管理者特権が必要です。
- ユーザー アカウントで実行されるアプリケーションにサービスまたはクライアントを組み込む場合は、現在のユーザー ストアを使用します。****
ストアへのアクセス
ストアは、コンピュータ上の一種のフォルダであり、アクセス制御リスト (ACL: Access Control List) によって保護されています。インターネット インフォメーション サービス (IIS: Internet Information Services) によってホストされたサービスを作成すると、ASP.NET アカウントで ASP.NET プロセスが実行されます。このアカウントは、サービスが使用する証明書を格納するストアにアクセス可能である必要があります。各主要ストアは既定のアクセス リストで保護されており、これらのリストを変更することはできません。ストアにアクセスする別のロールを作成した場合、そのロールにアクセス許可を付与する必要があります。WinHttpCertConfig.exe ツールを使用してアクセス リストを変更する方法については、「方法 : 開発中に使用する一時的な証明書を作成する」を参照してください。IIS でクライアント証明書を使用する方法詳細については、 、「ASP.NET Web アプリケーションで認証用のクライアント証明書を使用して Web サービスを呼び出す方法」を参照してください。
信頼チェーンと証明機関
デジタル証明書を使用する場合、信頼チェーンに依存してエンティティを認証します。このチェーンは、最上位にあるルート証明機関から下位に向かって形成されます。証明書のチェーンを表示するには、MMC スナップインを使用して、証明書をダブルクリックし、[証明書パス] タブをクリックします。証明書チェーンの最上位にあるルート証明機関の証明書は、自己発行されます。つまり、証明書の発行者と発行先のエンティティが同じであるということです。証明機関の証明書チェーンをインポートする方法詳細については、 、「方法 : 署名の検証に使用する証明機関の証明書チェーンを指定する (WCF)」を参照してください。
.gif "ms731899.note(ja-jp,VS.90).gif") メモ : |
|---|
| 証明書を "信頼されたルート証明機関" 証明書ストアに配置することにより、その証明書の発行者を信頼されたルート証明機関として指定できます。 |
信頼チェーンの無効化
新しいサービスの作成時には、信頼されたルート証明書によって発行されていない証明書を使用できます。また、発行する証明書が、信頼されたルート証明機関ストアになくてもかまいません。開発だけを目的としている場合は、証明書の信頼チェーンをチェックする機構を一時的に無効にできます。これを行うには、CertificateValidationMode プロパティを PeerTrust または PeerOrChainTrust に設定します。これらのモードにより、証明書を自己発行するか (ピア信頼)、信頼チェーンに含めるかを指定できます。このプロパティは、次のどのクラスでも設定できます。
構成を使用して、このプロパティを設定することもできます。検証モードを指定するには、次の要素を使用します。
- <authentication> of <serviceCertificate> Element
- <peerAuthentication> Element
- <messageSenderAuthentication> element
カスタム認証
CertificateValidationMode プロパティを使用すると、証明書の認証方法をカスタマイズすることもできます。既定では、レベルは ChainTrust に設定されています。Custom 値を使用するには、CustomCertificateValidatorType 属性を証明書の検証に使用するアセンブリと型に設定することも必要です。カスタム検証を作成するには、抽象 X509CertificateValidator クラスから継承する必要があります。
カスタム認証システムを作成する場合、オーバーライドする最も重要なメソッドは Validate メソッドです。カスタム認証の例については、「X.509 Certificate Validator」のサンプルを参照してください。詳細な情報については、次のページを参照してください。 「カスタム資格情報と資格情報の検証」を参照してください。
Makecert.exe を使用した証明書チェーンの構築
証明書作成ツール (Makecert.exe) では、X.509 証明書および秘密キーと公開キーのペアを作成します。秘密キーをディスクに保存し、新しい証明書の発行と署名に使用できるため、チェーンになった証明書の階層をシミュレートできます。このツールは、サービスの開発時に支援ツールとして使用することだけを目的としています。実際の展開に使用する証明書の作成には使用しないでください。WCF サービスの開発時に、Makecert.exe を使用して信頼チェーンを構築するには、次の手順に従います。
Makecert.exe を使用して証明書チェーンを構築するには
MakeCert.exe ツールを使用して、(自己発行された) 一時的なルート証明機関証明書を作成します。秘密キーをディスクに保存します。
この新しい証明書を使用して、公開キーを含む別の証明書を発行します。
信頼されたルート証明機関ストアに、ルート証明機関証明書をインポートします。
手順の詳細については、「方法 : 開発中に使用する一時的な証明書を作成する」を参照してください。
使用する証明書の選択
証明書に関する一般的な質問は、どの証明書を使用するかということとその理由に関するものです。その答えは、クライアントとサービスのどちらをプログラミングするかによって異なります。以下に一般的なガイドラインを示します (これらの質問に対する包括的な答えではありません)。
サービス証明書
サービス証明書の第一の目的は、クライアントに対してサーバーを認証することです。クライアントがサーバーを認証するときの最初のチェックの 1 つとして、"サブジェクト" フィールドの値とサービスへのアクセスに使用する URI (Uniform Resource Identifier) が比較されます。この場合、双方の DNS が一致する必要があります。たとえば、サービスの URI が "https://www.contoso.com/endpoint/" の場合、"サブジェクト" フィールドにも値 "www.contoso.com" が含まれている必要があります****。
このフィールドには複数の値を含めることができますが、各値の先頭にはその値を示す初期化コードが付加されます。通常、初期化コードは共通名 (Common Name) を表す "CN" です。たとえば、"CN = www.contoso.com" のようになります。"サブジェクト" フィールドを空白にすることもできます。この場合、"サブジェクト代替名" フィールドに値として DNS 名を含めることができます****。
また、証明書の "目的" フィールドの値に、適切な値 ("サーバー認証" や "クライアント認証" など) を含める必要があります****。
クライアント証明書
通常、クライアント証明書はサードパーティ証明機関によって発行されません。通常は、"クライアント認証" という目的で、ルート証明機関によって、この証明書が現在のユーザー ストアの個人ストアに配置されます。クライアントは、相互認証が必要なときにこのような証明書を使用できます。
オンラインの失効とオフラインの失効
証明書の有効期間
すべての証明書は、"有効期間" と呼ばれる一定の期間にのみ有効です**。有効期間は、X.509 証明書の "Valid from" フィールドと "Valid to" フィールドによって定められています****。認証時に、証明書がまだ有効期間内かどうかを確認するためのチェックが行われます。
証明書失効リスト
有効期間中であっても、証明機関が証明書を失効させる場合があります。これは、証明書の秘密キーの侵害など、さまざまな理由によって行われます。
証明書が失効した場合、失効した証明書から発生した下位のチェーンも無効になり、認証手順において信頼されなくなります。失効した証明書を検出するために、各発行者は日時が記された証明書失効リスト (CRL) を発行します。このリストは、オンラインの失効またはオフラインの失効を使用してチェックできます。これを使用するには、X509ClientCertificateAuthentication、X509PeerCertificateAuthentication、X509ServiceCertificateAuthentication、および IssuedTokenServiceCredential の各クラスの RevocationMode プロパティまたは DefaultRevocationMode プロパティを X509RevocationMode 列挙値のいずれかに設定します。すべてのプロパティの既定値は、Online です。
(serviceBehaviors sectionの) <authentication> of <clientCertificate> Element と (endpointBehaviors sectionの) <authentication> of <clientCertificate> Element の revocationMode 属性を使用することにより、構成でモードを設定することもできます。
SetCertificate メソッド
WCF では、認証、暗号化、またはメッセージのデジタル署名を行うために、多くの場合、サービスまたはクライアントが使用する証明書または証明書のセットを指定する必要があります。これは、X.509 証明書を表すさまざまなクラスの SetCertificate メソッドを使用することで、プログラムによって実行できます。SetCertificate メソッドを使用して証明書を指定するクラスは次のとおりです。
| クラス | メソッド |
|---|---|
SetCertificate メソッドを使用するには、ストアの場所とストア、証明書のフィールドを指定する "検索" の種類 (x509FindType パラメータ)、および該当のフィールドで検索する値を指定します。たとえば、次のコードでは、ServiceHost インスタンスを作成し、SetCertificate メソッドを使用して、クライアントに対してサービスを認証する際に使用するサービス証明書を設定しています。
同じ値が含まれた複数の証明書
ストアには、同じサブジェクト名が含まれた複数の証明書が格納されていることがあります。つまり、x509FindType を FindBySubjectName または FindBySubjectDistinguishedName に指定したときに、複数の証明書に同じ値が含まれていると、必要な証明書を区別することができないため、例外がスローされます****。この状況は、x509FindType を FindByThumbprint に設定することによってある程度防ぐことができます。サムプリント フィールドには一意の値が含まれるため、このフィールドを使用することで、ストア内の特定の証明書を検索できます。ただし、この方法には欠点があります。証明書が失効したり、更新されたりした場合、サムプリントも失われてしまうため、SetCertificate メソッドは失敗します。また、証明書が有効でなくなると、認証が失敗します。このような状況が発生する可能性を軽減する方法として、x590FindType パラメータを FindByIssuerName に設定し、発行者の名前を指定します。特定の発行者が必要ではない場合は、その他の X509FindType 列挙値のいずれか (FindByTimeValid など) を設定することもできます。
構成における証明書
証明書は、構成を使用して設定することもできます。サービスを作成する場合、serviceBehaviors sectionで証明書をはじめとする資格情報を指定します。クライアントをプログラミングする場合は、endpointBehaviors sectionで証明書を指定します。
ユーザー アカウントへの証明書の割り当て
IIS と Active Directory には、証明書を Windows ユーザー アカウントに割り当てることができる機能があります。この機能詳細については、 、「ユーザー アカウントへの証明書のマッピング」を参照してください。
Active Directory のマッピングを使用する方法詳細については、 、「ディレクトリ サービス マッピングによるクライアント証明書のマッピング」を参照してください。
この機能が有効になっている場合、X509ClientCertificateAuthentication クラスの MapClientCertificateToWindowsAccount プロパティを true に設定できます。構成では、次のコードに示すように、<authentication> 要素の mapClientCertificateToWindowsAccount 属性を true に設定できます。
<serviceBehaviors>
<behavior name="MappingBehavior">
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="None" mapClientCertificateToWindowsAccount="true" />
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
Windows ユーザー アカウントを表すトークンに X.509 証明書を割り当てると、Windows トークンを使用して保護されたリソースにアクセスできるため、この割り当てが特権の昇格と見なされます。したがって、割り当てを行う前に、ドメイン ポリシーにそのポリシーに準拠する X.509 証明書が必要となります。この要件は、SChannel のセキュリティ パッケージによって適用されます。
.NET Framework Version 3.5 以降を使用している場合は、Windows アカウントにマッピングされる前に、証明書がドメイン ポリシーに準拠していることが WCF によって確認されます。
WCF の最初のリリースでは、ドメイン ポリシーを参照せずに割り当てが実行されます。そのため、マッピングが有効になっており、X.509 証明書がドメイン ポリシーを満たしていない場合は、最初のリリースの下で実行しているときには動作していた古いアプリケーションが動作しなくなる可能性があります。
関連項目
リファレンス
System.ServiceModel.Channels
System.ServiceModel.Security
System.ServiceModel
X509FindType