CryptographicException 'Keyset non esiste', ma solo tramite WCF

StackOverflow https://stackoverflow.com/questions/602345

  •  03-07-2019
  •  | 
  •  

Domanda

Ho un po 'di codice che effettua una chiamata a un servizio Web di terze parti protetto mediante la certificazione X.509.

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

Quando 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 CryptographicException , il messaggio " Keyset non esiste " quando chiamo un metodo sul terzo servizio web party.

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

Qualcuno può far luce su questo problema?

È stato utile?

Soluzione

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).

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

Altri suggerimenti

Ciò è molto probabile perché 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 premi avanti
  5. Seleziona Computer locale (impostazione predefinita), quindi fai clic su Fine
  6. Nel pannello di sinistra da Console Root, vai a  Certificati (computer locale) - > Personale - > Certificati
  7. Molto probabilmente il tuo certificato sarà qui.
  8. Fai clic con il pulsante 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 ...

anziché

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

Anche se le autorizzazioni sulla chiave sono 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 set di chiavi di & # 8220; non esiste & # 8221; durante la navigazione da IIS: Potrebbe essere per l'autorizzazione privata

Per visualizzare e dare l'autorizzazione:

  1. Esegui > > MMC, sì
  2. fai clic sul file
  3. Fai clic su Aggiungi / rimuovi snap-in & # 8230;
  4. Fai doppio clic sul certificato
  5. Account computer
  6. Avanti
  7. Fine
  8. Ok
  9. Fai clic su Certificati (computer locale)
  10. Fai clic su Personale
  11. Fai clic su Certificati

Per dare l'autorizzazione:

  1. Fare clic con il tasto destro sul nome del certificato
  2. Tutte le attività > Gestisci chiavi private & # 8230;
  3. Aggiungi e dai il privilegio (l'aggiunta di IIS_IUSRS e il conferimento del 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 tuo sito web funziona con " Servizi di rete " account o con meno privilegi.

Soluzione : modifica l'identità del pool di applicazioni in " Sistema locale " ;, ripristina IIS e ricontrolla. 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 aveva correttamente le autorizzazioni per leggere il file in C: \ ProgramData \ Microsoft \ Crypto \ RSA \ MachineKeys , tuttavia si scopre 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 cancello la chiave dalla cartella c: \ ProgramData, esegui 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 in

C: \ Documents and settngs \ All users ..

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.

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 ho continuato a incontrare nonostante le autorizzazioni concesse a tutte le chiavi generate dagli esempi su Internet.

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

Questo 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.

Se usi ApplicationPoolIdentity per il tuo pool di applicazioni, potresti avere problemi con la specifica dell'autorizzazione per quella "quotazione virtuale"; utente 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 integrità. Stavo ottenendo lo stesso errore esatto anche dopo aver installato i certificati nei negozi giusti sui miei computer e avere tutti i giusti privilegi di sicurezza per il client. Ho scoperto che ho confuso il mio certificato client e il mio certificato di servizio. Se hai provato tutto quanto sopra, vorrei ricontrollare che hai 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 riscontrato questo problema nel mio progetto di fabric di servizio dopo che il certificato utilizzato per l'autenticazione con il nostro key vault è scaduto ed è stato ruotato, modificando l'impronta digitale. Ho ricevuto questo errore perché non avevo aggiornato l'aggiornamento dell'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 " X509FindValue " valore dell'attributo. 

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

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top