CryptographicException 'Keyset non esiste', ma solo tramite WCF

Ho del codice che effettua una chiamata a un servizio Web di terzi che è protetto mediante la certificazione X.509.

Se chiamo direttamente il codice (usando un unit test) funziona senza problemi.

Una volta distribuito, questo codice verrà chiamato tramite un servizio WCF. Ho aggiunto un secondo test unit che chiama il servizio WCF, tuttavia questo non riesce con un CryptographicExceptionmessaggio "Keyset does not exist"quando chiamo un metodo sul servizio Web di terze parti.

Presumo che ciò sia dovuto al fatto che il mio servizio WCF tenterà di chiamare il servizio Web di terze parti utilizzando un altro utente.

Qualcuno può far luce su questo problema?

Probabilmente sarà un problema di autorizzazioni sul certificato.

Quando si esegue un unit test, si eseguiranno quelli nel proprio contesto utente, che (a seconda dell'archivio in cui si trova il certificato client ) avrà accesso alla chiave privata di quel certificato.

Tuttavia, se il servizio WCF è ospitato in IIS o come servizio Windows, è probabile che verrà eseguito con un account di servizio (servizio di rete, servizio locale o altri account con restrizioni).

Sarà necessario impostare le autorizzazioni appropriate sulla chiave privata per consentire a tale account di servizio di accedervi. MSDN ha i dettagli

Ciò è probabilmente dovuto al fatto che l'utente IIS non ha accesso alla chiave privata per il certificato. Puoi impostarlo seguendo questi passaggi ...

1. Avvia -> Esegui -> MMC
2. File -> Aggiungi / Rimuovi snapin
3. Aggiungi lo snap-in certificati
4. Seleziona Account del computer, quindi fai clic su Avanti
5. Seleziona Computer locale (impostazione predefinita), quindi fai clic su Fine
6. Nel pannello di sinistra dalla console principale, accedere a Certificati (computer locale) -> Personale -> Certificati
7. Molto probabilmente il tuo certificato sarà qui.
8. Fare clic con il tasto destro del mouse sul certificato -> Tutte le attività -> Gestisci chiavi private
9. Imposta qui le impostazioni della tua chiave privata.

Ho avuto un problema identico ieri sera. Le autorizzazioni per la chiave privata sono state impostate correttamente, apparentemente tutto andava bene tranne l'errore Keyset non esiste. Alla fine si è scoperto che il certificato è stato prima importato nell'archivio utenti corrente e poi spostato nell'archivio macchine locale. Tuttavia, ciò non ha spostato la chiave privata, che era ancora in

C: \ Documents and settngs \ Administrator ...

invece di

C: \ Documents and settngs \ Tutti gli utenti ...

Sebbene le autorizzazioni per la chiave siano state impostate correttamente, ASPNET non ha potuto accedervi. Quando abbiamo reimportato il certificato in modo che la chiave privata venga inserita nel ramo Tutti gli utenti, il problema è scomparso.

Per risolvere il "Keyset non esiste" durante la navigazione da IIS: potrebbe essere per l'autorizzazione privata

Per visualizzare e dare il permesso:

1. Esegui> mmc> sì
2. fare clic sul file
3. Fai clic su Aggiungi / rimuovi snap-in ...
4. Fare doppio clic sul certificato
5. Account del computer
6. Il prossimo
7. finire
8. Ok
9. Fai clic su Certificati (computer locale)
10. Fai clic su Personale
11. Fai clic su Certificati

Per dare il permesso:

1. Fare clic con il tasto destro sul nome del certificato
2. Tutte le attività> Gestisci chiavi private ...
3. Aggiungi e dai il privilegio (aggiungere IIS_IUSRS e assegnargli il privilegio funziona per me)

Si è verificato lo stesso problema durante il tentativo di eseguire l'app WCF da Visual Studio. Risolto eseguendo Visual Studio come amministratore.

Ho riscontrato questo problema, i miei certificati avevano la chiave privata ma stavo ottenendo questo errore ( "Keyset non esiste" )

Causa: il sito Web è in esecuzione con l'account "Servizi di rete" o con meno privilegi.

Soluzione : modificare l'identità del pool di applicazioni in "Sistema locale", ripristinare IIS e ricontrollare. Se inizia a funzionare è un problema di autorizzazione / Meno privilegio, puoi impersonare quindi utilizzare anche altri account.

Totalmente frustrante, ho avuto lo stesso problema e ho provato la maggior parte di quanto sopra. Il certificato esportato disponeva correttamente delle autorizzazioni per leggere il file C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, tuttavia risulta che non disponeva dell'autorizzazione per la cartella. Aggiunto e ha funzionato

Anch'io ho esattamente un problema simile. Ho usato il comando

findprivatekey root localmachine -n "CN="CertName" 

il risultato mostra che la chiave privata si trova nella cartella c: \ ProgramData anziché in C: \ Documents and settngs \ All users ..

Quando elimino la chiave dalla cartella c: \ ProgramData, eseguire nuovamente il comando findPrivatekey non riesce. vale a dire. non trova la chiave.

Ma se cerco la stessa chiave restituita dal comando precedente, riesco ancora a trovare la chiave

C: \ Documents and settngs \ Tutti gli utenti ..

Quindi, per quanto ne so, IIS o il WCF ospitato non trovano la chiave privata da C: \ Documents and settngs \ All users ..

Stavo ottenendo l'errore: CryptographicException 'Keyset non esiste' quando eseguo l'applicazione MVC.

La soluzione era: dare accesso ai certificati personali all'account con cui è in esecuzione il pool di applicazioni. Nel mio caso è stato aggiungere IIS_IUSRS e la scelta della posizione corretta ha risolto questo problema.

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. 

La risposta di Steve Sheldon ha risolto il problema per me, tuttavia, poiché sto scrivendo le autorizzazioni del certificato senza una GUI, avevo bisogno di una soluzione gestibile da script. Ho faticato a trovare dove era memorizzata la mia chiave privata. La chiave privata non era in -C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, alla fine ho scoperto che era effettivamente in C:\ProgramData\Microsoft\Crypto\Keys. Di seguito descrivo come l'ho scoperto:

Ho provato FindPrivateKeyma non è stato possibile trovare la chiave privata e usando PowerShell $cert.privatekey.cspkeycontainerinfo.uniquekeycontainernameera null / vuoto.

Fortunatamente, certutil -store myho elencato il certificato e mi ha fornito i dettagli di cui avevo bisogno per scrivere la soluzione.

================ Certificate 1 ================ Serial Number: 162f1b54fe78c7c8fa9df09 Issuer: CN=*.internal.xxxxxxx.net NotBefore: 23/08/2019 14:04 NotAfter: 23/02/2020 14:24 Subject: CN=*.xxxxxxxnet Signature matches Public Key Root Certificate: Subject matches Issuer Cert Hash(sha1): xxxxa5f0e9f0ac8b7dd634xx Key Container = {407EC7EF-8701-42BF-993F-CDEF8328DD} Unique container name: 8787033f8ccb5836115b87acb_ca96c65a-4b42-a145-eee62128a ##* ^-- filename for private key*## Provider = Microsoft Software Key Storage Provider Private key is NOT plain text exportable Encryption test passed CertUtil: -store command completed successfully.

Ho quindi scansionato la c\ProgramData\Microsoft\Crypto\cartella e ho trovato il file 8787033f8ccb5836115b87acb_ca96c65a-4b42-a145-eee62128a in C: \ ProgramData \ Microsoft \ Crypto \ Keys .

Dare accesso in lettura al mio account di servizio a questo file ha risolto i problemi per me

Ho trovato alcune informazioni mancanti che mi hanno aiutato a ottenere il mio servizio WCF con sicurezza a livello di messaggio oltre il "Keyset non esiste" che continuavo a eseguire nonostante concedessi le autorizzazioni a tutte le chiavi generate dagli esempi su Internet.

Alla fine ho importato la chiave privata nell'archivio di persone affidabili sul computer locale e quindi ho concesso alla chiave privata le autorizzazioni corrette.

Ciò ha riempito gli spazi vuoti per me e alla fine mi ha permesso di implementare il servizio WCF con sicurezza a livello di messaggio. Sto costruendo un WCF che deve essere conforme a HIPPA.

Ho appena reinstallato il mio certificato nel computer locale e quindi funziona correttamente

Se usi ApplicationPoolIdentity per il tuo pool di applicazioni, potresti avere problemi con la specifica dell'autorizzazione per quell'utente "virtuale" nell'editor del registro (non esiste tale utente nel sistema).

Quindi, usa subinacl - strumento da riga di comando che abilita gli ACL di registro impostati o qualcosa del genere.

Volevo solo aggiungere una risposta di controllo di sanità mentale. Stavo ottenendo lo stesso errore esatto anche dopo aver installato i certificati nei negozi giusti sui miei computer e avendo tutti i giusti privilegi di sicurezza per il client. Ho scoperto che ho confuso il mio certificato cliente e il mio certificato di servizio. Se hai provato tutto quanto sopra, ricontrollerei che tu abbia quei due diritti. Una volta che l'ho fatto, la mia applicazione ha chiamato con successo il servizio web. Ancora una volta, solo un controllo di sanità mentale.

Ricevuto questo errore durante l'utilizzo del Fedlet openAM su IIS7

La modifica dell'account utente per il sito Web predefinito ha risolto il problema. Idealmente, vorresti che questo fosse un account di servizio. Forse anche l'account IUSR. Suggerisci di cercare metodi per l'indurimento IIS per inchiodarlo completamente.

Ho raggiunto questo risultato nel mio progetto di fabric di servizio dopo che il certificato utilizzato per l'autenticazione con il nostro key vault era scaduto e ruotato, modificando l'impronta digitale. Ho ricevuto questo errore perché mi ero perso ad aggiornare l'impronta digitale nel file applicationManifest.xml in questo blocco che fa esattamente ciò che altre risposte hanno suggerito - a dato il SERVIZIO DI RETE (che tutti i miei ex eseguono come, configurazione standard per il cluster servicefabric azzurro) a accedere alla posizione del negozio di certificati LOCALMACHINE \ MY.

Nota il valore dell'attributo "X509FindValue".

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

Questa è l'unica soluzione che ha funzionato per me.

    // creates the CspParameters object and sets the key container name used to store the RSA key pair
    CspParameters cp = new CspParameters();
    cp.KeyContainerName = "MyKeyContainerName"; //Eg: Friendly name

    // instantiates the rsa instance accessing the key container MyKeyContainerName
    RSACryptoServiceProvider rsa = new RSACryptoServiceProvider(cp);
    // add the below line to delete the key entry in MyKeyContainerName
    // rsa.PersistKeyInCsp = false;

    //writes out the current key pair used in the rsa instance
    Console.WriteLine("Key is : \n" + rsa.ToXmlString(true));

Riferimento 1

Riferimento 2

This issue is got resolved after adding network service role.

CERTIFICATE ISSUES 
Error :Keyset does not exist means System might not have access to private key
Error :Enveloped data … 
Step 1:Install certificate in local machine not in current user store
Step 2:Run certificate manager
Step 3:Find your certificate in the local machine tab and right click manage privatekey and check in allowed personnel following have been added:
a>Administrators
b>yourself
c>'Network service'
And then provide respective permissions.

## You need to add 'Network Service' and then it will start working.