Objekt existiert bereits in RSACryptoServiceProvider

8

Ich habe den Quellcode von einer Anwendung in eine andere kopiert, die beide auf demselben Rechner laufen. Ich verwende auch die gleiche Zeichenfolge für containerName in beiden Anwendungen.

Was verhindert, dass meine neue Anwendung den Schlüssel liest, der in der anderen Anwendung gespeichert wurde? Alle anderen Dinge sind gleich, angemeldetes Benutzerkonto etc.

%Vor%     
CHI Coder 007 21.01.2011, 20:45
quelle

4 Antworten

7

Haben Sie versucht, Berechtigungen für Jeder zu erteilen, z. B. für Dateien in "Dokumente und Einstellungen \ All Users \ Anwendungsdaten \ Microsoft \ Crypto \ RSA \ Machine Keys", wie dort beschrieben:

Ссылка

    
Pavel Morshenyuk 21.01.2011 22:07
quelle
6

Eine andere Lösung besteht darin, den Zugriff auf alle nach Code zu ermöglichen:

%Vor%     
Webmixer 02.09.2011 12:38
quelle
2

Ich stieß auf dieses Problem, weil mein WCF-Dienst keine Berechtigung zum Zugriff auf den Keystore hatte. Ich bin an dem Problem vorbeigekommen, indem ich den Anweisungen gefolgt habe, um dem Benutzer ASPNET Lesezugriff zu gewähren, den ich hier fand: Ссылка

    
Chris 01.03.2011 14:21
quelle
0

Ich bin kürzlich auf dieses Problem mit mehreren bereitgestellten IIS-Sites auf einem einzelnen Server (Windows 2008 R2) gestoßen. In unserer Umgebung werden die einzelnen Sites in verschiedenen Anwendungspools ausgeführt. In einigen Fällen können diese Pools jedoch mit derselben Identität versehen werden.

Unsere Anwendung erstellt einen Schlüssel, wenn dieser nicht existiert, und speichert ihn in einem Container mit einem Namen, der auf der aktuellen Identität basiert. Die erste bereitgestellte Site funktionierte immer. Wenn wir jedoch eine andere Site in einen anderen App-Pool mit der gleichen Identität implementierten, schlug die zweite fehl.

Es stellt sich heraus, dass Windows beim Speichern des Schlüssels vollen Zugriff auf den Benutzer "IIS APPPOOL \ AppPoolName" und nicht die Identität, die wir dem Pool zugewiesen haben, bietet.

Unsere Lösung bestand also darin, dem Container explizite Berechtigungen für die aktuelle Identität zu geben (ähnlich der Antwort von @ Webmixer, der einzige Unterschied besteht in CryptoKeyAccessRule ):

%Vor%     
Steve Czetty 09.09.2014 16:58
quelle