Frage

Ich habe einige Code, der einen Anruf an einen Dritten Web-Service macht die X.509-Zertifizierung gesichert werden.

Wenn ich rufe Sie den Code direkt (mit einem Unit-Test) funktioniert es ohne Probleme.

Wenn eingesetzt, wird dieser Code über einen WCF-Dienst aufgerufen werden. Ich habe eine zweite Einheit Test hinzugefügt, die die WCF-Dienst aufruft, aber dies nicht gelingt mit einem CryptographicException, Nachricht "Keyset does not exist" wenn ich eine Methode auf dem Dritten Web-Service aufrufen.

Ich nehme an, dass dies, weil mein WCF-Dienst versucht werden, den Dritten Web-Service mit einem anderen Benutzer mich anzurufen.

Kann jemand Schuppen zusätzliche Licht auf dieses Problem?

War es hilfreich?

Lösung

Es wird wahrscheinlich ein Berechtigungsproblem auf dem Zertifikat sein.

Wenn Sie einen Komponententest ausgeführt Sie diejenigen, die unter Ihrem eigenen Benutzerkontext werden wollen Ausführung, die (je nachdem, was speichern Sie die Client Zertifikat ist in) haben Zugriff auf diesen privaten Schlüssel des Zertifikats.

Allerdings, wenn Ihr WCF-Dienst unter IIS oder als Windows-Dienst gehostet ist es wahrscheinlich, es wird unter einem Dienstkonto (Network Service, Service vor Ort oder ein anderes eingeschränktes Konto) ausgeführt werden.

Sie müssen die entsprechenden Berechtigungen auf den privaten Schlüssel setzen, dass das Dienstkonto Zugriff darauf zu ermöglichen. MSDN hat die Details

Andere Tipps

Dies ist höchstwahrscheinlich, weil der IIS Benutzer keinen Zugriff auf den privaten Schlüssel für das Zertifikat hat. Sie können dies mit den folgenden Schritten ...

  1. Start -> Ausführen -> MMC
  2. Datei -> Hinzufügen / Entfernen Snapin
  3. Fügen Sie die Zertifikate Snap In
  4. Wählen Sie Computerkonto, dann drücken Sie neben
  5. Wählen Sie Lokaler Computer (Standardeinstellung), dann klicken Sie auf Fertig stellen
  6. Auf der linken Tafel von Konsole-Stamm, navigieren Sie zu  Zertifikate (Lokaler Computer) -> Persönliche -> Zertifikate
  7. Ihr Zertifikat wird höchstwahrscheinlich hier.
  8. Rechtsklick auf Ihr Zertifikat -> Alle Tasks -> Verwalten privater Schlüssel
  9. Stellen Sie Ihre privaten Schlüssel Einstellungen hier.

Ich habe identische Ausgabe letzte Nacht hatte. Berechtigungen für private Schlüssel wurden richtig eingestellt, alles war anscheinend in Ordnung, außer die Keyset Fehler nicht vorhanden ist. Am Ende stellte sich heraus, dass Zertifikat auf den aktuellen Benutzerspeicher importiert wurde zuerst und zog dann auf den lokalen Computer zu speichern. Allerdings - das hat nicht den privaten Schlüssel bewegen, die sich noch in der war

C: \ Dokumente und settngs \ Administrator ...

statt

C: \ Dokumente und settngs \ Alle Benutzer ...

Altough Berechtigungen für den Schlüssel korrekt gesetzt wurden, kann ASPNET nicht darauf zugreifen. Wenn wir Zertifikat erneut importiert, so dass der private Schlüssel in der alle Benutzer Zweig platziert ist, ist das Problem verschwunden.

Zur Lösung des „Keyset existiert nicht“, wenn sie von IIS Surfen im Internet: Es kann für die private Erlaubnis sein

Um zu sehen, und geben Sie die Erlaubnis:

  1. Ausführen> mmc> ja
  2. Klicken Sie auf Datei
  3. Klicken Sie auf Add / Remove Snap-in ...
  4. Klicken Sie doppelt auf Zertifikat
  5. Computer-Konto
  6. Weiter
  7. Fertig stellen
  8. Ok
  9. Klicken Sie auf Zertifikate (Lokaler Computer)
  10. Klicken Sie auf Personal
  11. Klicken Sie auf Zertifikate

, um die Erlaubnis zu geben:

  1. Rechtsklick auf den Namen des Zertifikats
  2. Alle Aufgaben> Verwalten private Schlüssel ...
  3. Fügen und das Privileg geben (Hinzufügen IIS_IUSRS und ihm das Privileg für mich funktioniert geben)

Hat das gleiche Problem bei dem Versuch, WCF-App von Visual Studio zu laufen. Gelöst es von Visual Studio als Administrator ausgeführt wird.

Ich habe dieses Problem konfrontiert, meine Zertifikate wo private Schlüssel hat, aber ich war immer diese Fehlermeldung ( „Keyset existiert nicht“ )

Ursache: Ihre Website wird unter "Netzwerkdienste" Konto ausgeführt oder weniger Privilegien mit

.

Lösung : Ändern der Anwendungspoolidentität zu "Local System", setzen Sie IIS zurück und erneut prüfen. Wenn es zu arbeiten beginnt es Erlaubnis / Weniger Privileg Problem ist, können Sie imitieren dann andere Konten zu verwenden.

Insgesamt frustrierend, ich hatte das gleiche Problem und versucht, die meisten der oben genannten. Das exportierte Zertifikat hatte richtig Berechtigungen die Datei in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys zu lesen, aber es stellt sich heraus, dass es nicht über die Berechtigung für den Ordner hat. Hinzugefügt es und es funktioniert

Ich habe genau ähnliches Problem auch. Ich habe den Befehl

findprivatekey root localmachine -n "CN="CertName" 

das Ergebnis zeigt, dass der private Schlüssel in c: \ Programdata Ordner anstelle von C: \ Dokumente und settngs \ Alle Benutzer ..

Wenn ich den Schlüssel aus c löschen: \ Programdata Ordnern erneut aus dem findPrivatekey Befehl nicht erfolgreich ist. dh. es nicht den Schlüssel finden.

Aber wenn ich den gleichen Schlüssel von früherem Befehl zurück suche, kann ich immer noch den Schlüssel in

finden

C: \ Dokumente und settngs \ Alle Benutzer ..

So zu meinem Verständnis, IIS oder die gehostete WCF nicht den privaten Schlüssel von C zu finden: \ Dokumente und settngs \ Alle Benutzer ..

Ich war immer die Fehlermeldung: Cryptographic ‚Keyset existiert nicht‘, wenn ich die MVC-Anwendung.

Lösung war: Zugriff auf die persönlichen Zertifikate auf das Konto zu geben, dass Anwendungspool unter ausgeführt wird. In meinem Fall war es IIS_IUSRS und die Wahl der richtigen Stelle gelöst dieses Problem hinzuzufügen.

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. 

fand ich einige fehlenden Informationen, die ich mit der Nachricht Level-Sicherheit über den meinen WCF-Dienst bekommen geholfen „Keyset existiert nicht“, dass ich laufe immer wieder in trotz der Beispiele im Internet generierten Berechtigungen für alle Tasten gewähren.

Ich importierte schließlich den privaten Schlüssel in den Laden vertraute Personen auf dem lokalen Rechner und dann den privaten Schlüssel die richtigen Berechtigungen erteilt.

Das in den Zuschnitten für mich gefüllt und schließlich erlaubte mir den WCF-Dienst mit Message Level-Sicherheit zu implementieren. Ich baue eine WCF, die HIPPA konform sein müssen.

Wenn Sie Application für Ihren Anwendungspool verwenden, können Sie Problem haben mit Erlaubnis Angabe für die „virtuellen“ Benutzer in Registrierungs-Editor (es im System nicht so Benutzer ist).

So verwenden Sie subinacl - Kommandozeilen-Tool, das ermöglicht Set Registry ACL oder so etwas wie.

Ich wollte nur eine Plausibilitätsprüfung Antwort hinzuzufügen. Ich war immer der exakt gleichen Fehler auch nach der Zertifikate an die richtigen Geschäfte auf meine Maschinen zu installieren und mit allen, die richtigen Sicherheitsberechtigungen für den Kunden. Es stellte sich heraus, dass ich meine Clientcertificate und mein Service-Zertifikat gemischt. Wenn Sie alle oben versucht haben, verdoppeln würde ich überprüfen, ob Sie diese beiden gerade haben. Nachdem ich das getan hätte, rief meine Bewerbung erfolgreich den Web-Service. Wieder nur eine geistige Gesundheit Prüfung.

diesen Fehler empfangen, während die OpenAM Fedlet auf IIS7 mit

Ändern des Benutzerkontos für die Standard-Website das Problem behoben. Im Idealfall würden wollen, können Sie dies ein Dienstkonto sein. Vielleicht sogar das IUSR-Konto. Vorschlagen aufzublicken Methoden für IIS Härten es Nagel vollständig nach unten.

Ich traf dies in meinem Dienst Stoff Projekt nach dem cert abgelaufen zu authentifizieren gegen unsere Schlüssel Gewölbe verwendet und wurde gedreht, die den Fingerabdruck verändert. Ich habe diesen Fehler, weil ich die Daumenabdruck Aktualisierung in der applicationManifest.xml Datei in diesem Block verpasst hatte, die genau das tut, was andere Antworten vorgeschlagen haben - zu bestimmten NETWORK SERVICE (die alle meine exes laufen als Standard-Konfiguration für azur servicefabric Cluster) Berechtigungen Zugriff auf die Localmachine \ MY cert Speicherort.

Beachten Sie den "X509FindValue" Attributwert.

<!-- 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 -->

ich neu installiert gerade mein Zertifikat in der lokalen Maschine und dann ist es gut funktioniert

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top