0

IX509PrivateKey を使用して X.509 証明書要求のキーを作成し (「NT AUTHORITY\NETWORK SERVICE」として)、Create メソッドがアクセス拒否を生成しています (C# からディスパッチ インターフェイスを P/Invoke しています)。であるため、HRESULT は .NET 例外に変換されます)。Process Monitor は、キー ファイルへのアクセスが拒否されたことも示します (キー ファイルは作成中です)。

実際のコードは次のとおりです。

        IX509PrivateKey privateKey = new CX509PrivateKey() as IX509PrivateKey;
        privateKey.Length = request.KeyLength;
        privateKey.ExportPolicy = X509PrivateKeyExportFlags.XCN_NCRYPT_ALLOW_EXPORT_FLAG;
        privateKey.KeySpec = X509KeySpec.XCN_AT_SIGNATURE;
        privateKey.KeyUsage = X509PrivateKeyUsageFlags.XCN_NCRYPT_ALLOW_ALL_USAGES;
        privateKey.MachineContext = true;
        privateKey.Create();
        return privateKey;

代わりに (MachineContext を false に設定して) ユーザー キー セットを作成すると、「アクセスが拒否されました」ではなく「ファイルが見つかりません」と表示されます。しかし、ProcMon には何も表示されません。キーファイルへのアクセスは試みません。

Process Monitor で、「ネットワーク サービス」がキー ファイルにアクセスできないことが判明したため、IX509PrivateKey::SecurityDescriptor プロパティを使用して設定しました。「Network Service」は実際にキーファイルにアクセスできましたが、Createからアクセスが拒否され、ProcMonはファイルへのアクセスが拒否されたことを示していました.

ありとあらゆるアイデアのための多くのTIA。

4

1 に答える 1

1

この問題の原因は特定されています。

IX509PrivateKey::Create への呼び出しが Web サービス内で発生していました。その結果、IUSR のなりすましで発生していました。間違ったユーザーを有効にする ACL を編集しました。難読化されたユーザー アカウントに対してのみ、単純なアクセス拒否であることが判明しました。この状態は ProcMon で確認できます。ProcMon の [詳細] 列には、呼び出しが偽装されたユーザー アカウントで行われたことが明確に示されます ([詳細出力] を有効にする必要がある場合があります)。

呼び出しが行われるユーザー アカウントと CA へのアクセスをより厳密に制御するために、要求をプロセス外に移動しました。登録 API 呼び出しは、独自の Windows サービスから行われ、WCF (net.tcp) を介して IIS で実行されている Web サービスに公開されます。それが他の人への私の推奨事項です。IMO によると、IIS 内での呼び出しを制御できないことは、別の「可動部分」を持つリスクよりも重要です。

于 2012-07-05T16:20:45.980 に答える