証明書の使用
Windows Communication Foundation (WCF) のセキュリティをプログラミングする場合、一般に X.509 デジタル証明書を使用して、クライアントとサーバーの認証、暗号化、およびメッセージのデジタル署名を行います。 ここでは、X.509 デジタル証明書の機能および WCF でのそれらの機能の使用方法について簡単に説明します。また、これらの概念の詳細を説明するトピックや、WCF と証明書を使用した一般的なタスクの実行方法が記載されたトピックへのリンクも示します。
簡単に言うと、デジタル証明書は、"公開キー基盤 (PKI: Public Key Infrastructure)" の一部です。PKI は、デジタル証明書、証明機関、およびその他の登録機関から成るシステムです。登録機関では、公開キー暗号化を使用して、電子取引に関与する各当事者の有効性の検証と認証を行います。 証明機関は証明書を発行します。各証明書には、"サブジェクト" (証明書の発行先のエンティティ)、有効期間 (証明書が有効な場合)、発行者 (証明書を発行したエンティティ)、公開キーなどのデータが含まれた一連のフィールドがあります。 WCF では、これらの各プロパティは Claim (クレーム) として処理されます。各クレームは、さらに ID と権限の 2 種類に分けられます。 X.509 証明書の詳細については、「X.509 Public Key Certificates」(X.509 公開キー証明書) を参照してください。 WCF におけるクレームと承認の詳細については、「ID モデルを使用したクレームと承認の管理」を参照してください。 PKI の実装の詳細については、「Windows Server 2012 R2 Active Directory 証明書サービスでのエンタープライズ PKI」を参照してください。
証明書の第一の機能は、他者に対して証明書の所有者の ID を認証することです。 証明書は所有者の "公開キー" を含んでおり、所有者が秘密キーを保持しています。 公開キーを使用して、証明書の所有者に送信されるメッセージを暗号化できます。 秘密キーにアクセスできるのは所有者だけであるため、所有者だけが暗号化されたメッセージを復号化できます。
証明書は、証明機関によって発行される必要があります。多くの場合、証明機関はサード パーティの証明書発行者です。 Windows ドメインでは、そのドメインのコンピューターに対して証明書を発行する際に使用できる証明機関が含まれています。
証明書を表示する
証明書を使用するには、多くの場合、証明書を表示し、プロパティを確認する必要があります。 Microsoft 管理コンソール (MMC: Microsoft Management Console) スナップイン ツールを使用すると、これを簡単に行うことができます。 詳細については、「 方法: MMC スナップインを使用して証明書を参照する」をご覧ください。
証明書ストア
証明書はストアに格納されています。 2 つの主要なストアがあり、さらにサブストアに分かれています。 コンピューターの管理者は、MMC スナップイン ツールを使用して、両方の主要なストアを表示できます。 管理者以外のユーザーは、現在のユーザー ストアだけを表示できます。
ローカル コンピューター ストア: このストアには、コンピューター プロセス (ASP.NET など) がアクセスする証明書が格納されます。 クライアントに対してサーバーを認証するための証明書は、ここに格納します。
現在のユーザー ストア: コンピューターの現在のユーザーの証明書は、通常、対話型アプリケーションによってここに配置されます。 クライアント アプリケーションを作成する場合、サービスに対してユーザーを認証するための証明書は、通常、ここに配置します。
上記の 2 つのストアは、さらにサブストアに分かれています。 サブストアの中で、WCF でプログラミングするときに最も重要なものは次のとおりです。
信頼されたルート証明機関: このストア内の証明書を使用して、証明書チェーンを作成できます。証明書チェーンをさかのぼることで、このストア内の任意の証明機関証明書に到達できます。
重要
証明書が信頼されたサードパーティ証明機関から発行されたものではない場合でも、ローカル コンピューターは、このストアに配置された証明書を暗黙で信頼します。 したがって、発行者を完全に信頼し、かつ信頼することの結果を理解していない限り、このストアに証明書を配置しないでください。
個人: このストアは、コンピューターのユーザーに関連付けられた証明書に使用されます。 通常、このストアは、信頼されたルート証明機関ストアにある証明機関証明書のいずれかによって発行された証明書に使用されます。 また、自己発行され、アプリケーションから信頼された証明書が格納されている場合もあります。
証明書ストアの詳細については、「Certificate Stores」(証明書ストア) を参照してください。
ストアを選択する
証明書を格納する場所の選択は、サービスまたはクライアントの実行方法や実行する状況によって異なります。 次の一般規則が適用されます。
WCF サービスが Windows サービスでホストされる場合は、ローカル コンピューター ストアを使用します。 ローカル コンピューター ストアに証明書をインストールするには、管理特権が必要です。
サービスまたはクライアントがユーザー アカウントで実行されるアプリケーションである場合は、現在のユーザー ストアを使用します。
ストアにアクセスする
ストアは、コンピューター上の一種のフォルダーであり、アクセス制御リスト (ACL: Access Control List) によって保護されています。 インターネット インフォメーション サービス (IIS: Internet Information Services) によってホストされたサービスを作成すると、ASP.NET アカウントで ASP.NET プロセスが実行されます。 このアカウントは、サービスが使用する証明書を格納するストアにアクセス可能である必要があります。 各主要ストアは既定のアクセス リストで保護されていますが、これらのリストは変更できます。 ストアにアクセスする別のロールを作成した場合、そのロールにアクセス許可を付与する必要があります。 WinHttpCertConfig.exe ツールを使用してアクセス リストを変更する方法については、「方法: 開発中に使用する一時的な証明書を作成する」を参照してください。
信頼チェーンと証明機関
証明書は、各証明書がその発行元の CA にリンクされる階層構造で作成されます。 このリンクは CA の証明書へのリンクになります。 次に、CA の証明書は元の CA の証明書を発行した CA にリンクします。 ルート CA の証明書に到達するまでこのプロセスが繰り返されます。 ルート CA の証明書は本質的に信頼されています。
デジタル証明書を使用する場合、この階層 ("信頼チェーン" とも呼ばれます) に依存してエンティティを認証します。 証明書のチェーンを表示するには、MMC スナップインを使用して、証明書をダブルクリックし、 [証明書パス] タブをクリックします。証明機関の証明書チェーンをインポートする方法の詳細については、「方法 : 署名の検証に使用する証明機関の証明書チェーンを指定する」を参照してください。
Note
証明書を "信頼されたルート証明機関" 証明書ストアに配置することにより、その証明書の発行者を信頼されたルート証明機関として指定できます。
信頼チェーンを無効にする
新しいサービスの作成時には、信頼されたルート証明書によって発行されていない証明書を使用できます。また、発行する証明書が、信頼されたルート証明機関ストアになくてもかまいません。 開発だけを目的としている場合は、証明書の信頼チェーンをチェックする機構を一時的に無効にできます。 これを行うには、CertificateValidationMode プロパティを PeerTrust または PeerOrChainTrust に設定します。 これらのモードにより、証明書を自己発行するか (ピア信頼)、信頼チェーンに含めるかを指定できます。 このプロパティは、次のどのクラスでも設定できます。
構成を使用して、このプロパティを設定することもできます。 検証モードを指定するには、次の要素を使用します。
カスタム認証
CertificateValidationMode プロパティを使用すると、証明書の認証方法をカスタマイズすることもできます。 既定では、レベルは ChainTrust に設定されています。 Custom 値を使用するには、CustomCertificateValidatorType 属性を証明書の検証に使用するアセンブリと型に設定することも必要です。 カスタム検証を作成するには、抽象 X509CertificateValidator クラスから継承する必要があります。
カスタム認証システムを作成する場合、オーバーライドする最も重要なメソッドは Validate メソッドです。 カスタム認証の例については、「X.509 証明書検証」のサンプルを参照してください。 詳細については、「カスタム資格情報と資格情報の検証」を参照してください。
PowerShell の New-SelfSignedCertificate コマンドレットを使用して証明書チェーンを構築する
PowerShell の New-SelfSignedCertificate コマンドレットを使用すると、X.509 証明書および秘密キーと公開キーのペアが作成されます。 秘密キーをディスクに保存し、新しい証明書の発行と署名に使用できるため、チェーンになった証明書の階層をシミュレートできます。 このコマンドレットは、サービスの開発時に支援ツールとして使用することだけを目的としています。実際の展開に使用する証明書の作成には使用しないでください。 WCF サービスの開発時に、New-SelfSignedCertificate コマンドレットを使用して信頼チェーンを構築するには、次の手順のようにします。
New-SelfSignedCertificate コマンドレットを使用して、一時的なルート証明機関 (自己署名) 証明書を作成します。 秘密キーをディスクに保存します。
この新しい証明書を使用して、公開キーを含む別の証明書を発行します。
信頼されたルート証明機関ストアに、ルート証明機関証明書をインポートします。
詳しい手順については、「方法: 開発中に使用する一時的な証明書を作成する」を参照してください。
使用する証明書の選択
証明書に関する一般的な質問は、どの証明書を使用するかということとその理由に関するものです。 その答えは、クライアントとサービスのどちらをプログラミングするかによって異なります。 以下に一般的なガイドラインを示します (これらの質問に対する包括的な答えではありません)。
サービス証明書
サービス証明書の第一の目的は、クライアントに対してサーバーを認証することです。 クライアントがサーバーを認証するときの最初のチェックの 1 つとして、"サブジェクト" フィールドの値とサービスへのアクセスに使用する URI (Uniform Resource Identifier) が比較されます。この場合、双方の DNS が一致する必要があります。 たとえば、サービスの URI が http://www.contoso.com/endpoint/ の場合、サブジェクト フィールドにも値 www.contoso.com が含まれている必要があります。
このフィールドには複数の値を含めることができますが、各値の先頭にはその値を示す初期化コードが付加されます。 通常、初期化コードは共通名 (Common Name) を表す "CN" です。たとえば、CN = www.contoso.com のようになります。 "サブジェクト" フィールドを空白にすることもできます。この場合、"サブジェクト代替名" フィールドに値として DNS 名を含めることができます。
また、証明書の "目的" フィールドの値に、適切な値 ("サーバー認証" や "クライアント認証" など) を含める必要があります。
[クライアント証明書]
通常、クライアント証明書はサードパーティ証明機関によって発行されません。 通常は、"クライアント認証" という目的で、ルート証明機関によって、この証明書が現在のユーザー ストアの個人ストアに配置されます。 相互認証が必要な場合、クライアントはこのような証明書を使用できます。
オンラインの失効とオフラインの失効
証明書の有効性
すべての証明書は、"有効期間" と呼ばれる一定の期間にのみ有効です。 有効期間は、X.509 証明書の "有効期間の開始" フィールドと "有効期間の終了" フィールドによって定義されています。 認証時に、証明書がまだ有効期間内かどうかを確認するためのチェックが行われます。
証明書の失効リスト
有効期間中であっても、証明機関が証明書を失効させる場合があります。 これは、証明書の秘密キーの侵害など、さまざまな理由によって行われます。
証明書が失効した場合、失効した証明書から発生した下位のチェーンも無効になり、認証手順において信頼されなくなります。 失効した証明書を検出するために、各発行者は日時が記された"証明書失効リスト" (CRL) を発行します。 このリストは、オンラインの失効またはオフラインの失効を使用してチェックできます。これを使用するには、RevocationMode、DefaultRevocationMode、X509RevocationMode、および X509ClientCertificateAuthentication の各クラスの X509PeerCertificateAuthentication プロパティまたは X509ServiceCertificateAuthentication プロパティを IssuedTokenServiceCredential 列挙値のいずれかに設定します。 すべてのプロパティの既定値は、Online です。
(<serviceBehaviors> の) <authentication> と (<endpointBehaviors> の) <authentication> の両方の revocationMode 属性を使用することにより、構成でモードを設定することもできます。
SetCertificate メソッド
WCF では、認証、暗号化、またはメッセージのデジタル署名を行うために、多くの場合、サービスまたはクライアントが使用する証明書または証明書のセットを指定する必要があります。 これは、X.509 証明書を表すさまざまなクラスの SetCertificate メソッドを使用することで、プログラムによって実行できます。 SetCertificate メソッドを使用して証明書を指定するクラスは次のとおりです。
SetCertificate メソッドを使用するには、ストアの場所とストア、証明書のフィールドを指定する "検索" の種類 (x509FindType パラメーター)、および該当のフィールドで検索する値を指定します。 たとえば、次のコードでは、ServiceHost インスタンスを作成し、SetCertificate メソッドを使用して、クライアントに対してサービスを認証する際に使用するサービス証明書を設定しています。
Uri baseAddress = new Uri("http://cohowinery.com/services");
ServiceHost sh = new ServiceHost(typeof(CalculatorService), baseAddress );
sh.Credentials.ServiceCertificate.SetCertificate(
StoreLocation.LocalMachine, StoreName.My,
X509FindType.FindBySubjectName, "cohowinery.com");
Dim baseAddress As New Uri("http://cohowinery.com/services")
Dim sh As New ServiceHost(GetType(CalculatorService), baseAddress)
sh.Credentials.ServiceCertificate.SetCertificate( _
StoreLocation.LocalMachine, StoreName.My, _
X509FindType.FindBySubjectName, "cohowinery.com")
同じ値を持つ複数の証明書
ストアには、同じサブジェクト名が含まれた複数の証明書が格納されていることがあります。 つまり、x509FindType に FindBySubjectName または FindBySubjectDistinguishedName を指定したときに、複数の証明書に同じ値が含まれていると、必要な証明書を区別することができないため、例外がスローされます。 この状況は、x509FindType を FindByThumbprint に設定することによってある程度防ぐことができます。 拇印フィールドには一意の値が含まれるため、このフィールドを使用することで、ストア内の特定の証明書を検索できます。 ただし、この方法には欠点があります。証明書が失効したり、更新されたりした場合、拇印も失われてしまうため、SetCertificate メソッドは失敗します。 また、証明書が有効でなくなると、認証が失敗します。 このような状況が発生する可能性を軽減する方法として、x590FindType パラメーターを FindByIssuerName に設定し、発行者の名前を指定します。 特定の発行者が必要ではない場合は、その他の X509FindType 列挙値のいずれか (FindByTimeValid など) を設定することもできます。
構成での証明書
証明書は、構成を使用して設定することもできます。 サービスを作成する場合、<serviceBehaviors> で証明書をはじめとする資格情報を指定します。 クライアントをプログラミングする場合は、<endpointBehaviors> で証明書を指定します。
証明書をユーザー アカウントにマップする
IIS と Active Directory には、証明書を Windows ユーザー アカウントにマップできる機能があります。 この機能の詳細については、「Map certificates to user accounts」(ユーザー アカウントへの証明書のマッピング) を参照してください。
Active Directory のマッピングを使用する方法の詳細については、「Mapping Client Certificates with Directory Service Mapping」(ディレクトリ サービスのマッピングによるクライアント証明書のマッピング) を参照してください。
この機能が有効になっている場合、MapClientCertificateToWindowsAccount クラスの X509ClientCertificateAuthentication プロパティを 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 3.5 以降のバージョンを使用している場合は、Windows アカウントにマッピングされる前に、証明書がドメイン ポリシーに準拠していることが WCF によって確認されます。
WCF の最初のリリースでは、ドメイン ポリシーを参照せずにマッピングが実行されます。 そのため、マッピングが有効になっており、X.509 証明書がドメイン ポリシーを満たしていない場合は、最初のリリースの下で実行しているときには動作していた古いアプリケーションが動作しなくなる可能性があります。