Windows Communication Foundation (WCF) のセキュリティをプログラムするために、X.509 デジタル証明書は、クライアントとサーバーの認証、メッセージの暗号化、デジタル署名に一般的に使用されます。 このトピックでは、X.509 デジタル証明書の機能とその WCF での使用方法について簡単に説明します。また、これらの概念をさらに説明するトピック、または WCF と証明書を使用して一般的なタスクを実行する方法を示すトピックへのリンクが含まれています。
簡単に言うと、デジタル証明書は 公開キー基盤 (PKI) の一部であり、公開キー暗号化を使用して電子トランザクションに関与する各当事者の有効性を検証および認証するデジタル証明書、証明機関、およびその他の登録機関のシステムです。 証明機関は証明書を発行し、各証明書には、 サブジェクト (証明書が発行されるエンティティ)、有効期間 (証明書が有効な場合)、発行者 (証明書を発行したエンティティ)、公開キーなどのデータを含む一連のフィールドがあります。 WCF では、これらの各プロパティは Claimとして処理され、各クレームはさらに識別と権利の 2 種類に分けられます。 X.509 証明書の詳細については、「 X.509 公開キー証明書」を参照してください。 WCF の要求と承認の詳細については、「 ID モデルを使用した要求と承認の管理」を参照してください。 PKI の実装の詳細については、「 Windows Server 2012 R2 Active Directory 証明書サービスを使用したエンタープライズ PKI」を参照してください。
証明書の主な機能は、証明書の所有者の ID を他のユーザーに認証することです。 証明書には所有者の 公開キー が含まれますが、所有者は秘密キーを保持します。 公開キーを使用して、証明書の所有者に送信されたメッセージを暗号化できます。 所有者のみが秘密キーにアクセスできるため、それらのメッセージの暗号化を解除できるのは所有者だけです。
証明書は証明機関によって発行される必要があります。これは、多くの場合、証明書のサード パーティの発行者です。 Windows ドメインには、ドメイン上のコンピューターに証明書を発行するために使用できる証明機関が含まれています。
証明書を表示する
証明書を操作するには、多くの場合、証明書を表示してプロパティを調べる必要があります。 これは、Microsoft 管理コンソール (MMC) スナップイン ツールを使用して簡単に行うことができます。 詳細については、「 方法: MMC スナップインを使用して証明書を表示する」を参照してください。
証明書ストア
証明書はストアにあります。 サブストアに分割された 2 つの主要な店舗の場所が存在します。 コンピューターの管理者は、MMC スナップイン ツールを使用して両方のメジャー ストアを表示できます。 管理者以外のユーザーは、現在のユーザー ストアのみを表示できます。
ローカル コンピューター ストア。 これには、ASP.NET などのマシン プロセスによってアクセスされる証明書が含まれます。 この場所を使用して、クライアントに対してサーバーを認証する証明書を格納します。
現在のユーザー ストア。 対話型アプリケーションでは、通常、コンピューターの現在のユーザーの証明書がここに配置されます。 クライアント アプリケーションを作成する場合は、通常、サービスに対してユーザーを認証する証明書を配置します。
これら 2 つのストアは、さらにサブストアに分割されます。 WCF を使用してプログラミングする場合の最も重要なものは次のとおりです。
信頼されたルート証明機関。 このストアの証明書を使用して、証明書のチェーンを作成できます。このチェーンは、このストアの証明機関証明書までトレースできます。
Von Bedeutung
証明書が信頼されたサード パーティの証明機関から取得されていない場合でも、ローカル コンピューターは、このストアに配置された証明書を暗黙的に信頼します。 このため、発行者を完全に信頼し、その結果を理解していない限り、このストアに証明書を配置しないでください。
個人用。 このストアは、コンピューターのユーザーに関連付けられている証明書に使用されます。 通常、このストアは、信頼されたルート証明機関ストアにある証明機関の証明書の 1 つによって発行された証明書に使用されます。 または、ここで見つかった証明書が自己発行され、アプリケーションによって信頼されている可能性があります。
証明書ストアの詳細については、「 証明書ストア」を参照してください。
ストアを選択する
証明書を格納する場所の選択は、サービスまたはクライアントの実行方法とタイミングによって異なります。 次の一般的な規則が適用されます。
WCF サービスが Windows サービスでホストされている場合は、 ローカル コンピューター ストアを使用します。 ローカル コンピューター ストアに証明書をインストールするには、管理者特権が必要であることに注意してください。
サービスまたはクライアントがユーザー アカウントで実行されるアプリケーションの場合は、 現在のユーザー ストアを使用します。
ストアにアクセスする
ストアは、コンピューター上のフォルダーと同様に、アクセス制御リスト (ACL) によって保護されます。 インターネット インフォメーション サービス (IIS) によってホストされるサービスを作成すると、ASP.NET プロセスは ASP.NET アカウントで実行されます。 そのアカウントには、サービスが使用する証明書を含むストアへのアクセス権が必要です。 各メジャー ストアは既定のアクセス リストで保護されていますが、リストは変更できます。 ストアにアクセスするための別のロールを作成する場合は、そのロールにアクセス許可を付与する必要があります。 WinHttpCertConfig.exe ツールを使用してアクセス リストを変更する方法については、「 方法: 開発中に使用する一時証明書を作成する」を参照してください。
チェーントラストと認証局
証明書は階層内に作成され、各証明書は証明書を発行した CA にリンクされます。 このリンクは CA の証明書へのリンクです。 その後、CA の証明書は、元の CA の証明書を発行した CA にリンクされます。 このプロセスは、ルート CA の証明書に達するまで繰り返されます。 ルート CA の証明書は本質的に信頼されています。
デジタル証明書は、信頼 チェーンとも呼ばれるこの階層に依存してエンティティを認証するために使用されます。 MMC スナップインを使用して証明書のチェーンを表示するには、任意の証明書をダブルクリックし、[ 証明書のパス ] タブをクリックします。証明機関の証明書チェーンのインポートの詳細については、「 方法: 署名の検証に使用する証明機関の証明書チェーンを指定する」を参照してください。
注
発行者は、信頼されたルート証明機関の証明書ストアに発行者の証明書を配置することで、信頼されたルート証明機関を指定できます。
チェーン信頼を無効にする
新しいサービスを作成するときに、信頼されたルート証明書によって発行されていない証明書を使用している場合や、発行元の証明書自体が信頼されたルート証明機関ストアにない可能性があります。 開発目的でのみ、証明書の信頼チェーンをチェックするメカニズムを一時的に無効にすることができます。 これを行うには、 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) と Subject フィールドの値を比較することです。両方の DNS は一致する必要があります。 たとえば、サービスの URI が http://www.contoso.com/endpoint/ されている場合、[ 件名 ] フィールドには www.contoso.com値も含まれている必要があります。
フィールドには複数の値を含めることができます。各フィールドには、値を示す初期化がプレフィックスとして付けられています。 最も一般的な初期化は、 CN = www.contoso.comなどの共通名の "CN" です。
[サブジェクト] フィールドを空白にすることもできます。この場合、[サブジェクトの別名] フィールドには DNS 名の値を含めることができます。
また、証明書の [目的 ] フィールドの値には、"サーバー認証" や "クライアント認証" などの適切な値が含まれている必要があることにも注意してください。
[クライアント証明書]
通常、クライアント証明書はサード パーティの証明機関によって発行されません。 代わりに、現在のユーザーの場所の個人用ストアには、通常、"クライアント認証" という目的でルート機関によってそこに配置された証明書が含まれます。 クライアントは、相互認証が必要な場合に、このような証明書を使用できます。
オンライン失効とオフライン失効
証明書の有効性
すべての証明書は、有効期間と呼ばれる特定の期間のみ 有効です。 有効期間は、X.509 証明書の 有効期間開始日 フィールドと 有効期間終了日 フィールドによって定義されます。 認証時に証明書がチェックされ、証明書がまだ有効期間内であるかどうかを判断します。
証明書失効リスト
有効期間中はいつでも、証明機関は証明書を取り消すことができます。 これは、証明書の秘密キーの侵害など、さまざまな理由で発生する可能性があります。
この場合、失効した証明書から派生したチェーンも無効になり、認証手順中は信頼されません。 失効している証明書を確認するために、各発行者は、時刻および日付スタンプ付きの 証明書失効リスト (CRL) を発行します。 リストは、オンライン失効またはオフライン失効を使用して、次のクラスの RevocationMode または DefaultRevocationMode プロパティを、 X509RevocationMode 列挙値 ( X509ClientCertificateAuthentication、 X509PeerCertificateAuthentication、 X509ServiceCertificateAuthentication、および IssuedTokenServiceCredential クラス) のいずれかに設定することで確認できます。 すべてのプロパティの既定値は Online。
モードは、revocationMode内の<認証>属性とendpointBehaviors内の<認証>属性の両方を使用して構成で設定することもできます。
SetCertificate メソッド
WCF では、多くの場合、サービスまたはクライアントがメッセージの認証、暗号化、またはデジタル署名に使用する証明書または証明書のセットを指定する必要があります。 これは、X.509 証明書を表すさまざまなクラスの SetCertificate メソッドを使用してプログラムで行うことができます。 次のクラスでは、 SetCertificate メソッドを使用して証明書を指定します。
SetCertificateメソッドは、ストアの場所とストア、証明書のフィールドを指定する "find" 型 (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 列挙値の 1 つ ( FindByTimeValidなど) を設定することもできます。
構成内の証明書
構成を使用して証明書を設定することもできます。 サービスを作成する場合は、証明書を含む資格情報が <serviceBehaviors> で指定されます。 クライアントをプログラミングする場合、証明書は <endpointBehaviors> で指定されます。
証明書をユーザー アカウントにマップする
IIS と Active Directory の機能は、証明書を Windows ユーザー アカウントにマップする機能です。 この機能の詳細については、「証明書を ユーザー アカウントにマップする」を参照してください。
Active Directory マッピングの使用の詳細については、「 ディレクトリ サービス マッピングを使用したクライアント証明書のマッピング」を参照してください。
この機能を有効にすると、MapClientCertificateToWindowsAccount クラスの X509ClientCertificateAuthentication プロパティを true に設定できます。 構成では、次のコードに示すように、>属性をtrueに設定できます。
<serviceBehaviors>
<behavior name="MappingBehavior">
<serviceCredentials>
<clientCertificate>
<authentication certificateValidationMode="None" mapClientCertificateToWindowsAccount="true" />
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
X.509 証明書を Windows ユーザー アカウントを表すトークンへのマッピングは特権の昇格と見なされます。これは、マップされると、Windows トークンを使用して保護されたリソースにアクセスできるためです。 そのため、ドメイン ポリシーでは、マッピング前に X.509 証明書がそのポリシーに準拠している必要があります。 SChannel セキュリティ パッケージでは、この要件が適用されます。
.NET Framework 3.5 以降のバージョンを使用する場合、WCF は、証明書が Windows アカウントにマップされる前に、ドメイン ポリシーに準拠していることを確認します。
WCF の最初のリリースでは、ドメイン ポリシーを参照せずにマッピングが行われます。 そのため、最初のリリースで実行したときに動作した古いアプリケーションは、マッピングが有効になっていて、X.509 証明書がドメイン ポリシーを満たしていない場合に失敗する可能性があります。