J'installe un service Windows sur une nouvelle machine. Le service effectue diverses opérations sur SSLStream sur TCP, qui utilise le certificat dans le problème.
Le service a fonctionné bien avec le même code et le même certificat sur d'autres machines Windows 2003. Mais, cette nouvelle machine est Windows 2003 avec un processeur 64 bits également.
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 références. (Encore une fois, cela fonctionne bien sur les 2 autres machines avec ce compte de service)
Je n'ai pas "une protection solide" activée lors de l'importation du certificat.
Voici la trace de la pile.
système.componentmodel.win32Exception: Les informations d'identification fournies à la Le paquet n'a pas été reconnu à System.net.sSpiWrapper.acQuireCredentialShandle (SSPIInterface Secmodule, package à cordes, Intention de CredentiCeUtilisée, SecureCréentielle SCC) à System.net.security.securechanannel.acquirecredentialShandle (CredentitionUelle Credusage, SecureCredential & sécurisé) à System.net.security.securechannel.acquireclientCredentials (octets [] & empreinte thumb System.net.security.securechannel.GenerateToken (octet [] Entrée, Int32 Offset, Int32 Count, Byte [] & Sortie) à System.net.security.securechannel.nextMessage (octet [] Incoming, Int32 Décalage, Int32 Count)
à System.net.security.sslstate.startsendblob (octet [] Nombre entrant, int32, Asyncprotocolrequest asyncrequest)
à System.net.security.sslstate.processReceedEvedblob (octet [] tampon, int32 compte, Asyncprotocolrequest asyncrequest)
à System.net.security.sslstate.startreadframe (octet [] tampon, int32 readbytes, Asyncprotocolrequest asyncrequest)
à System.net.security.sslstate.startreceiveblob (octet [] tampon, asyncprotocolrequest asyncrequest) à System.net.security.sslstate.CheckComplettionBeforenexTreceive (Protocoltoken Message, asyncprotocolrequest asyncrequest) à System.net.security.sslstate.startsendblob (octet [] Nombre entrant, int32, Asyncprotocolrequest asyncrequest)
à System.net.security.sslstate.forCeuthentification (Boolean ReceiveFirst, byte [] tampon, Asyncprotocolrequest asyncrequest)
à System.net.Security.sslstate.Processauthentication (LazyasyncResult Lazyresult) à System.net.security.sslstream.authenticateasclient (chaîne Targethost, X509CertificatCollection ClientCertificats, SSLProtocols EnabledSlprotocols, Boolean CheckCertificateErtère)
4 Réponses :
J'ai trouvé le problème et sa solution.
L'idée est d'accorder des autorisations au compte utilisé pour l'identité de service.
besoin d'utiliser une outil winhttpcercfg.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.
J'ai eu ce problème à la fois lorsqu'il est exécuté 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 à l'aide de l'interface graphique, qui est une bonne amélioration.
Toutefois, lorsque vous utilisez un service Windows, vous devez vous assurer que le certificat est dans le magasin de certificats personnels, 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», obtenez simplement le composant logiciel enfichable pour l'ordinateur local.
Voici la différence que j'ai trouvée ...
Si vous aviez installé le certificat personnel à votre propre boutique de certificats d'utilisateur et copié et collé au magasin d'ordinateur local, cela ne fonctionne pas toujours. Toutefois, si vous supprimez le certificat à partir du magasin d'ordinateur local, un dossier personnel, vous pouvez ensuite cliquer avec le bouton droit de la souris sur le dossier personnel de l'ordinateur local, puis importer et passer par l'assistant.
Pour une raison quelconque, cela la corrige et attribue les autorisations correctes pour l'utilisation du certificat. Bonne chance!
Supprimer et la réinstaller à l'ordinateur local au lieu de l'utilisateur local l'a fait pour moi. Il semble que cela n'installe qu'après également les autres certificats de la chaîne, peut-être que c'est ce qui manque lorsque vous ne copiez que de l'utilisateur local à l'ordinateur local.
Je faisais ce qui est décrit ici pour un service Win 2003 et ne pouviez toujours pas le faire fonctionner à cause des "Critiques de références fournies à l'emballage non reconnues".
J'ai essayé toutes les solutions ci-dessus sans succès.
Enfin, je l'ai eu pour travailler en faisant ce qui suit:
Pourquoi ... qui sait ..... heureux ça a fonctionné pour moi .... espérons que cela facilite la tâche des autres
J'ai utilisé la solution de ce fil - " Les informations d'identification fournies au package n'ont pas été reconnues "Erreur lors de l'authentification de serveur avec certificat généré à l'aide de Bouncycastle .
SIGNELLEMENT DIT:
Regardez le premier résultat de la recherche: Google.com/... "
J'avais regardé ce fil de forum, Wim. Et il explique correctement ce qui se passe ici. La raison pour laquelle cela ne fonctionnerait pas pour moi était que je devais résoudre ce problème pour un «compte de service» qui ne peut pas être utilisé pour vous connecter à la machine et installer le certificat sous cette identité. Mais la bonne façon de le résoudre pour «Everbody» est mentionné dans l'article suivant que j'ai posté dans «Réponse».