Problème de certificat avec une nouvelle machine - les informations d'identification fournies au package ne sont pas reconnues

Question

J'installe un service Windows sur une nouvelle machine. Le service effectue diverses opérations sur SslStream sur TCP, qui utilise le certificat en question.

Le service fonctionne correctement avec le même code et le même certificat sur les deux autres machines Windows 2003. Mais, cette nouvelle machine est Windows 2003 avec un processeur 64 bits aussi.

Je rencontre ce problème lorsque j'essaie d'exécuter le service avec une identité de «compte de service». Cela fonctionne bien avec mes propres informations d'identification. (Encore une fois, cela fonctionne très bien sur les 2 autres machines avec ce compte de service)

Je n'ai pas de 'protection forte' activée lors de l'importation du certificat.

Voici la trace de la pile.

System.ComponentModel.Win32Exception: Les informations d'identification fournies à l'emballage ne sont pas reconnus au System.Net.SSPIWrapper.AcquireCredentialsHandle (SSPIInterface SecModule, paquet String, intention de CredentialUse, SecureCredential scc) à System.Net.Security.SecureChannel.AcquireCredentialsHandle (CredentialUse credUsage, secureCredential & secureCredential) à System.Net.Security.SecureChannel.AcquireClientCredentials (byte [] & empreinte numérique) à System.Net.Security.SecureChannel.GenerateToken (byte [] entrée , Int32 offset, Int32 compter, byte [] sortie &) à System.Net.Security.SecureChannel.NextMessage (byte [] le nombre des arrivants, Int32 offset, Int32)
à System.Net.Security.SslState.StartSendBlob (byte [] entrant, compte Int32, AsyncProtocolRequest asyncRequest)
à System.Net.Security.SslState.ProcessReceivedBlob (Byte [] buffer, comptage Int32, AsyncProtocolRequest asyncRequest)
à System.Net.Security.SslState.StartReadFrame (byte [] buffer , Int32 readBytes, AsyncProtocolRequest asyncRequest)
à System.Net.Security.SslState.StartReceiveBlob (byte [] tampon, AsyncProtocolRequest asyncRequest) à System.Net.Security.SslState.CheckCompletionBeforeNextReceive (message de ProtocolToken , AsyncProtocolRequest asyncRequest) à System.Net.Security.SslState.StartSendBlob (byte [] entrant, Int32 compter, AsyncProtocolRequest asyncRequest)
à System.Net.Security.SslState.ForceAuthentication (Boolean receiveFirst, byte [] buffer, AsyncProtocolRequest asyncRequest)
à System.Net.Security.SslState.ProcessAuthentication (LazyAsyncResult lazyResult) à System.Net.Security. SslStream.AuthenticateAsClient (String targetHost, X509CertificateCollection ClientCertificates, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation)

Answer 1

J'ai trouvé le problème et sa solution.

L'idée est d'accorder des autorisations au compte qui est utilisé pour l'identité du service.

Besoin d'utiliser un outil WinHttpCertCfg.exe. Ceci est utile pour les applications utilisant des certificats clients pour obtenir une autorisation.

C'est bien expliqué ici. http://support.microsoft.com/kb/901183

Merci à Feroze Daud (http://ferozedaud.blogspot.com/), qui m'a répondu sur un forum différent.

Answer 2

J'ai rencontré ce problème lors de l'exécution sous le compte ASP.NET ou lors de l'utilisation d'un service Windows (sous le compte Système local). Si vous exécutez sous ASP.NET, pour Windows 2003, vous devez utiliser l'outil WinHttpCertCfg.exe comme décrit par cdpnet ci-dessus. Windows 2008 R2 vous permet d'accéder aux droits en utilisant l'interface graphique, ce qui est une belle amélioration. Cependant, lors de l'exécution en tant que service Windows, vous devez vous assurer que le certificat figure dans le magasin de certificats personnel, en entrant dans mmc et en ajoutant le composant logiciel enfichable de certificat pour le compte de service Windows ou si vous utilisez le compte "Système local", il suffit d'obtenir le composant logiciel enfichable pour l'ordinateur local.

Voici la différence que j'ai trouvé ...

Si vous avez installé le certificat personnel à votre propre magasin de certificats d'utilisateur et copié et collé au magasin de l'ordinateur local, cela ne fonctionne pas toujours. Toutefois, si vous supprimez le certificat du magasin d'ordinateurs local, dossier personnel, vous pouvez alors cliquer avec le bouton droit sur le dossier personnel dans le magasin d'ordinateurs local, puis importer et passer par l'assistant.

Pour une raison quelconque, cela corrige et attribue les autorisations correctes pour l'utilisation du certificat. Bonne chance!

Answer 3

Je faisais ce qui est décrit ici pour un Win 2003 Serv et je n'arrivais toujours pas à le faire fonctionner à cause des mssg "informations d'identification fournies au paquet non reconnu".

J'ai essayé toutes les solutions ci-dessus sans succès.

Enfin je l'ai eu à travailler à faire ce qui suit:

1. makecert -pe -n "CN = cert" -ss mon -SR LocalMachine -a SHA1 échange -sky -eku 1.3.6.1.5.5. 7.3.1 -in "CERT", est MON -ir LocalMachine de la "Cryptographic Provider Microsoft RSA SChannel" -sy 12 Cert.cer
2. Utiliser copie MMC de personnel à racine de confiance
3. Utilisez le certificat généré (.cer) pour l'appel X509 depuis votre application de service.

POURQUOI ... qui sait ..... heureux que cela a fonctionné pour moi .... nous espérons que cela rend plus facile sur d'autres