CryptographicException 'キーセットが存在しません' (WCF 経由のみ)

https://stackoverflow.com/questions/602345

03-07-2019
|

質問

X.509 証明書を使用して保護されたサードパーティの Web サービスを呼び出すコードがいくつかあります。

(単体テストを使用して) コードを直接呼び出すと、問題なく動作します。

デプロイすると、このコードは WCF サービス経由で呼び出されます。WCF サービスを呼び出す 2 番目の単体テストを追加しましたが、これは次のエラーで失敗します。 CryptographicException, 、メッセージ "Keyset does not exist" サードパーティの Web サービスのメソッドを呼び出すとき。

これは、WCF サービスが自分とは異なるユーザーを使用してサードパーティの Web サービスを呼び出そうとしているためだと思われます。

誰かこの問題について追加の光を当てられますか?

解決

おそらく証明書の権限に問題があると考えられます。

単体テストを実行するときは、独自のユーザーコンテキストで単体テストを実行することになります。 クライアント 証明書が含まれている場合)、その証明書の秘密キーにアクセスできます。

ただし、WCF サービスが IIS でホストされている場合、または Windows サービスとしてホストされている場合は、サービスアカウント (ネットワークサービス、ローカルサービス、またはその他の制限されたアカウント) で実行される可能性があります。

サービスアカウントが秘密キーにアクセスできるようにするには、秘密キーに適切なアクセス許可を設定する必要があります。MSDN には詳細

他のヒント

これはおそらく、IISユーザーが証明書の秘密キーにアクセスできないためです。次の手順に従って設定できます...

開始-＆gt;実行-＆gt; MMC
ファイル-＆gt;スナップインの追加と削除
証明書スナップインを追加
[コンピューターアカウント]を選択して、次のヒット
[ローカルコンピューター]（デフォルト）を選択し、[完了]をクリックします
コンソールルートの左パネルで、証明書（ローカルコンピューター）-＆gt;個人-＆gt;証明書
ほとんどの場合、証明書はここにあります。
証明書を右クリック-＆gt;すべてのタスク-＆gt;秘密鍵の管理
ここで秘密鍵の設定を行います。

昨夜も同じ問題がありました。秘密キーのアクセス許可が正しく設定され、キーセットが存在しないというエラーを除き、すべてが明らかに問題ありませんでした。最終的に、証明書は最初に現在のユーザーストアにインポートされ、次にローカルマシンストアに移動されたことが判明しました。ただし、秘密鍵は移動しませんでした。これはまだ

C：\ Documents and settngs \ Administrator ...

の代わりに

C：\ Documents and settngs \ All users ...

キーのアクセス許可は正しく設定されていますが、ASPNETはアクセスできませんでした。秘密鍵が[すべてのユーザー]ブランチに配置されるように証明書を再インポートすると、問題はなくなりました。

＆＃8220;キーセットが存在しないことを解決するには＆＃8221; IISから閲覧する場合： 個人の許可が必要な場合があります

表示して権限を付与するには：

実行＆gt; mmc＆gt;はい
ファイルをクリック
[スナップインの追加/削除]をクリックします
証明書をダブルクリック
コンピューターアカウント
次へ
完了
OK
証明書（ローカルコンピューター）をクリックします
個人をクリックします
証明書をクリック

許可を与えるには：

証明書の名前を右クリック
すべてのタスク＆gt;秘密鍵の管理＆＃8230;
特権を追加して付与する（IIS_IUSRSを追加し、特権を付与することで動作します）

Visual StudioからWCFアプリを実行しようとしたときに同じ問題が発生しました。 Visual Studioを管理者として実行して解決しました。

私はこの問題に直面しました。私の証明書には秘密キーがありますが、このエラーが発生しました(「キーセットが存在しません」)

原因： Web サイトは「ネットワークサービス」アカウントで実行されているか、権限が低いです。

解決:アプリケーションプール ID を「ローカルシステム」に変更し、IIS をリセットして再度確認します。機能し始めた場合は、権限/権限の不足の問題であるため、他のアカウントを使用して偽装することもできます。

まったくイライラして、私は同じ問題を抱え、上記のほとんどを試しました。エクスポートされた証明書には、 C：\ ProgramData \ Microsoft \ Crypto \ RSA \ MachineKeys 内のファイルを読み取る権限が正しくありましたが、フォルダーに対する権限がなかったことがわかりました。追加して動作しました

私もまったく同様の問題を抱えています。コマンドを使用しました

findprivatekey root localmachine -n "CN="CertName"

結果は、秘密鍵がC：\ Documentsおよびsettngs \ All usersではなくc：\ ProgramDataフォルダーにあることを示しています。

c：\ ProgramDataフォルダーからキーを削除すると、再度findPrivatekeyコマンドを実行しても成功しません。すなわち。キーが見つかりません。

ただし、前のコマンドで返された同じキーを検索しても、

でキーを見つけることができます

C：\ Documents and settngs \ All users ..

そのため、IISまたはホストされているWCFは、C：\ Documentsおよびsettngs \ Allユーザーから秘密キーを見つけていません。

MVCアプリケーションを実行すると、エラーが発生しました：CryptographicException 'Keyset does not exist'

解決策は、アプリケーションプールが実行されているアカウントに個人証明書へのアクセスを許可することでした。私の場合、IIS_IUSRSを追加し、適切な場所を選択することでこの問題は解決しました。

RC on the Certificate - > All tasks -> Manage Private Keys -> Add->  
For the From this location : Click on Locations and make sure to select the Server name. 
In the Enter the object names to select : IIS_IUSRS and click ok.

「キーセットが存在しません」というメッセージレベルのセキュリティでWCFサービスを取得するのに役立つ情報が不足していることがわかりました。インターネット上の例から生成されたすべてのキーにアクセス許可を付与しているにもかかわらず、私は走り続けました。

ようやくローカルマシンの信頼できる人のストアに秘密鍵をインポートし、秘密鍵に正しい権限を付与しました。

これにより、空白が埋められ、最終的にメッセージレベルのセキュリティでWCFサービスを実装できました。 HIPPAに準拠する必要があるWCFを作成しています。

アプリケーションプールにApplicationPoolIdentityを使用している場合、その「仮想」に対する許可の指定に問題がある可能性があります。レジストリエディターのユーザー（システムにはそのようなユーザーはありません）。

したがって、 subinacl を使用します。これは、レジストリACLの設定などを有効にします。

健全性チェックの回答を追加したいだけです。マシンの適切なストアに証明書をインストールし、クライアントに対するすべての適切なセキュリティ権限を取得した後でも、まったく同じエラーが発生していました。 clientCertificateとサービス証明書を混同したことがわかりました。上記のすべてを試してみた場合、これら2つがまっすぐになっていることを再確認します。それを行うと、アプリケーションはWebサービスを正常に呼び出しました。繰り返しますが、単なる健全性チェッカーです。

IIS7でopenAM Fedletを使用中にこのエラーを受け取りました

デフォルトのWebサイトのユーザーアカウントを変更すると、問題は解決しました。理想的には、これをサービスアカウントにしたいでしょう。おそらくIUSRアカウントでも。 IISの強化方法を調べて、完全に特定することをお勧めします。

Key Vaultに対する認証に使用された証明書の有効期限が切れ、ローテーションされた後、サービスファブリックプロジェクトでこれにヒットしました。これにより、changed印が変更されました。このエラーが発生したのは、このブロックのapplicationManifest.xmlファイルのthumb印の更新を見逃していたためです。 LOCALMACHINE \ MY証明書ストアの場所にアクセスします。

＆quot; X509FindValue＆quot;に注意してください。属性値。

<!-- this block added to allow low priv processes (such as service fabric processes) that run as NETWORK SERVICE to read certificates from the store -->
  <Principals>
    <Users>
      <User Name="NetworkService" AccountType="NetworkService" />
    </Users>
  </Principals>
  <Policies>
    <SecurityAccessPolicies>
      <SecurityAccessPolicy ResourceRef="AzureKeyvaultClientCertificate" PrincipalRef="NetworkService" GrantRights="Full" ResourceType="Certificate" />
    </SecurityAccessPolicies>
  </Policies>
  <Certificates>
    <SecretsCertificate X509FindValue="[[THIS KEY ALSO NEEDS TO BE UPDATED]]" Name="AzureKeyvaultClientCertificate" />
  </Certificates>
  <!-- end block -->

ローカルマシンに証明書を再インストールしたばかりで、正常に動作しています

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow