2011-02-02 28 views
3

"証明書 'CN = tempcert'には、鍵交換が可能な秘密鍵が必要です。 HTTPを使用してWin7上でWCFサービスを実行します。 "NetworkService"を使用するようにアプリケーションプールを変更します。ローカルマシンを使用してサーバー証明書をインストールしました。証明書は、証明書MMCの[ローカルコンピュータ/個人/証明書]に表示されます。証明書をダブルクリックすると、秘密鍵があることが示されます。 FindPrivateKeyユーティリティを実行し、C:\ ProgramData \ Microsoft \ Crypto \ RSA \ MachineKeysフォルダの秘密キーを検出したことを示します。私はMMCの証明書アドインに入り、NETWORK SERVICEアカウントに完全な権限を与えました。次に、Windowsエクスプローラのフォルダに移動し、NETWORK SERVICEにフォルダと特定のキーファイルに対する完全な権限があることを確認しました。しかし、WCFサービスを実行するたびに、秘密鍵が見つからないというエラーが出ます。他に何ができるのか分かりません。WCFサービスの秘密キーへのアクセス許可を取得できません。

答えて

4

証明書を作成するときに-sky exchangeを指定する必要があります。

makecert -sk SignedByCA -iv TempCA.pvk -n "CN=localhost" -ic 
    TempCA.cer SignedByCA.cer -sr LocalMachine -ss My -sky exchange -pe 
4

私もこれで苦労しました。クイックフィックスはありません。 "-sky exchange"はこのエラーの原因になる可能性がありますが、自己署名証明書を作成する際に "-sky exchange"が設定されていて、このエラーが発生しました。プライベートキーのアクセス権と証明書の場所など、この問題を引き起こす可能性のあるその他の問題があります。

WindowsサービスとしてごWCFホストを実行しているとき/場合、これが適用でき

:私は手動でWCFサービスを開始した場合、私の場合には、秘密鍵 に

アクセス権を、それが継承されました私の(管理グループ)ユーザーアカウントの権利とWCFサービスは証明書を見つけることに問題はありませんでした。しかし、Windowsサービスを使用してWCFホストを起動すると、サービスの権利が継承され、この同じエラーが発生しました。

私の場合、サービスマネージャウィンドウで、自分のサービスを実行しているアカウントが「ローカルシステム」と表示されます。これは実際には「NT AUthority/System」を意味します。だから私は、そのアカウントに秘密鍵コンテナへのアクセス権をそのアカウントに与える必要がありました。 「みんな」は驚くほど十分ではありませんでした。ファイルフォルダへのアクセス権を設定するのと同じように、MMCまたはFindPrivatekey.exeを使用してキーコンテナに権利を割り当て、ファイルエクスプローラを使用して権利を設定することができます。

店舗立地-another要因 また、私の場合、私は下で実行されたアカウントはありませんので、使用のあった、私の本命を見つけ、「LOCALMACHINE」または「CurrentUserに」店舗へのアクセス権を持っていませんでした。サービスは、MMCを使用して証明書を「サービス(サービス名)」にインポート(またはコピー)したときにのみ動作し始めました。

このようにすることができます.MMCを開き、リストから[証明書]を選択します。私のユーザアカウント(CurrentUser)、サービスアカウント(あなたはどのサービスを選択するか)、コンピュータアカウント(LocalMachine)の3つのオプションが表示されます。サービスアカウントを選択して、WCFホストを実行するサービスを選択するだけです。

ここで私の答えは完全な「方法」ではなく、この問題で苦労している人にとって役立つヒントです。私のドキュメンテーションのために書いた「方法」は10ページでした。

+0

CSP(レガシーCryptoAPI)とKSP(CNG、CryptoNextGen)の違いにも注意してください。いくつかの古いアプリはKSP/CNGとうまくやっていません。 – Nic

2

MMC> [ファイル]> [管理]>> [すべてのタスク]をクリックし右>証明書を見つけ、次にOK>コンピュータアカウント>次へ>仕上げ>スナップイン>証明書>追加

を追加/削除プライベートキー

証明書を使用しているユーザーまたはサービスを追加し、完全な制御を許可します。

あなたはすべてのセットがサービスを再起動:)と、それは私もこの例外を得ていた

0

動作するはずです。内部例外を調べると、System.Security.Cryptography.CryptographicException: Invalid provider type specified. Windows Server 2008で.NET 3.5でCNG証明書を使用していましたが、この記事(https://msdn.microsoft.com/en-us/library/aa738624(v=vs.100).aspx)はサポートされていないと強調表示されています。

使用している証明書の種類を確認するには、Certutil -store myコマンドを実行し、プロバイダフィールドを探します。

  • それはのMicrosoft拡張暗号化プロバイダーv1.0のを言えば - それはCSP証明書です。
  • Microsoftソフトウェアキーストアプロバイダ - それはCNG(KSP)証明書です。

とにかく、この情報が同じ問題のある人に役立つことを願っています。

+0

ああ、私の修正は、CSPを使っていた新しい証明書をロールすることでした。 – gottlieb76

関連する問題