Erreur WCF "cela pourrait être dû au fait que le certificat du serveur N'est pas configuré correctement avec HTTP.SYS dans L'affaire HTTPS"

nous avons eu ce problème car le serveur hôte avait été mis à jour pour utiliser TLS V1.2 et nous nous connections en utilisant le standard SSL. Il s'agit d'une mise à jour faite dans le cadre des tests en stylo des sites. Nous avons vu le problème dans la connexion de code, mais pas les navigateurs allant à la wsdl. Ci-dessous code résolu:

if (System.Net.ServicePointManager.SecurityProtocol == (SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls))
    System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

tiré de ici: comment désactiver la fonction de repli SSL et utiliser uniquement TLS pour les connexions sortantes dans .NET? (Caniche atténuation)

j'ai Eu le même problème sur un service en cours d'exécution sur IIS 7 le service se connecte à plusieurs serveurs fournisseurs (certains SSL certains non) lorsque j'en ajoutais un nouveau (ce nouveau fournisseur était TLS 1.2), j'obtenais l'erreur après quelques requêtes sur les serveurs originaux (SSL).

pour confirmer cela, j'ai simplement enregistré le System.Net.ServicePointManager.SecurityProtocol avant chaque demande à chaque fournisseur.

faible et voici après le redémarrage du service (ou redémarrer le application pool) j'obtiendrais la sortie Ssl3, Tls mais après quelques requêtes aux serveurs fournisseurs d'origine cela changea en Ssl3 et les requêtes au service TLS donnèrent l'erreur.

pour corriger j'ai simplement fait ce que l'utilisateur 369142 suggéré. Avant chaque requête au nouveau serveur:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;

et plus d'erreurs.

avait ce problème avec une vraie liaison HTTPS et la même exception avec" cela pourrait être dû au fait que le certificat du serveur n'est pas configuré correctement avec HTTP.SYS dans L'affaire HTTPS...". Après une double vérification du code et de la configuration, il semble que le message d'erreur ne soit pas aussi trompeur que les exceptions internes, donc après une vérification rapide, nous avons découvert que le port 443 était accroché par skype (sur le serveur dev). Je vous recommande de jeter un oeil à ce qui retient la demande (Fiddler pourrait vous aider ici) et assurez-vous que vous pouvez atteindre le front de service (voir le .svc dans votre navigateur) et ses métadonnées.

bonne chance.

pour nous, cette erreur était due au fait que L'ordinateur du développeur qui exécutait le service avait configuré IIS pour lier le port 443 sur 127.0.0.1 seulement.

dans IIS Manager, cliquez avec le bouton droit de la souris sur le site web et choisissez Modifier les liens. Si l'entrée pour le Port 443 a L'adresse IP 127.0.0.1 , changez-la en * .

nous avons eu à peu près ce même problème se produire récemment et il s'est avéré être causé par Microsoft update KB980436 ( http://support.microsoft.com/KB/980436 ) installé sur l'ordinateur appelant. Le correctif pour nous, autre que sa désinstallation pure et simple, était de suivre les instructions sur le site KB pour mettre le DWORD UseScsvForTls dans le Registre à 1. Si vous voyez que cette mise à jour est installée dans votre système d'appel, vous pouvez lui donner une chance.

après avoir cherché et pris le nom du Seigneur en vain, je l'ai finalement eu.J'ai installé TLS 1.2 sur le serveur où mon service wcf est en cours d'exécution.Mon client a été configuré correctement mais l'it a été construit sur .NET 4.5.1 alors que la wcf était sur .NET 4.6.1. Le client et le serveur doivent être dans la même Version .NET si vous utilisez TLS 1.2. J'espère que cela aide quelqu'un un jour:-)

si votre service WCF utilise .net framework 4.0 et que quelqu'un a désactivé TLS 1.0 sur le serveur, alors vous verrez cette exception. En raison de .net 4.0 ne supporte pas les versions supérieures de TLS.

protocoles supportés: https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols (v = 100).aspx

dans mon cas, j'ai dû activer SchUseStrongCrypto pour .Net Cela force le serveur à faire la connexion en utilisant TLS 1.0, 1.1 ou 1.2. Sans SchUseStrongCrypto activé la connexion essayait D'utiliser SSL 3.0, qui a été désactivé à mon terminal distant.

clés de Registre pour permettre l'utilisation de crypto fort:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

j'ai vu ces exceptions particulières liées à des questions complexes de type de données, voir le post suivant si vous êtes en train de passer autour des collections ou des énums:

Types De Données Complexes

si vous utilisez le mode de transfert = streamé, essayez de le changer en tampon.

si ce n'est pas le problème, Pouvez-vous afficher votre configuration.

comme tout fonctionnait bien pendant des semaines puis s'est arrêté, je doute que cela ait quelque chose à voir avec votre code. Peut-être que l'erreur se produit lorsque le service est activé dans IIS/ASP.NET, pas quand votre code est appelé. Le runtime pourrait simplement vérifier la configuration du site web et lancer un message d'erreur générique qui n'a rien à voir avec le service.

je crains qu'un certificat a expiré ou que le les fixations sont mal configurées. Si le site web est mal configuré pour HTTPS, que votre code l'utilise ou non, vous pourriez avoir cette erreur.

essayez de parcourir le service dans le navigateur et dans le mode Https, si ce n'est pas brow-sable alors il prouve la raison de cette erreur. Maintenant, pour résoudre cette erreur, vous devez vérifier :

• port https, Vérifiez s'il n'est pas utilisé par d'autres ressources (site web)
• vérifier si le certificat pour https est correctement configuré ou non (Vérifier le pouvoir de signature, le certificat auto signé, en utilisant plusieurs certificats )
• vérifier la liaison de service WCF et la configuration pour le mode Https

j'ai eu ce problème quand j'ai lancé des boîtes plus anciennes XP SP3 contre IIS et glassfish sur Amazon AWS. Amazon a modifié les paramètres de l'équilibrage de charge par défaut pour ne pas activer le chiffrement DES-CBC3-SHA. Vous devez activer cela sur amazon ELB si vous voulez permettre à XP TLS 1.0 plus ancien de fonctionner contre ELB pour HTTPS sinon vous obtenez cette erreur. Les chiffreurs peuvent être changés sur ELB en allant dans l'onglet listener dans la console et en cliquant sur cipher à côté de l'écouteur particulier que vous essayez de faire fonctionner.

vient d'en faire l'expérience:

Système

.ServiceModel.CommunicationException:

une erreur s'est produite alors que faire la requête HTTP à http://example.com/WebServices/SomeService.svc . Cela pourrait être dû le fait que le certificat du serveur n'est pas configuré correctement avec HTTP.SYS dans L'affaire HTTPS. Cela pourrait également être causé par une inadéquation de la liaison de sécurité entre le client et le serveur.

- - - > système.Net.WebException: la connexion sous-jacente a été fermée: une erreur inattendue s'est produite sur un envoi.

- - - > système.IO.IOException: impossible d'écrire des données à la connexion de transport: une connexion existante a été fermée de force par la télécommande hôte.

j'ai appris d'un administrateur que le pool d'applications IIS qui hébergeait le service web recyclé automatiquement après à court de mémoire. L'erreur sur le client s'est produite lorsque le pool d'application a été recyclé.

L'augmentation de la mémoire disponible pour le pool d'applications a résolu le problème immédiat.

nos applications ont récemment été forcées de quitter SSL pour TLS via une mise à jour OS network appliance (F5). Nous avons corrigé cette erreur en recréant les certificats auto-signés. Espérons que cela aidera quelqu'un dans le futur à résoudre le problème que nous avons dépensé plusieurs Windows de dépannage de maintenance avant d'arriver à la solution.

vient d'en faire l'expérience:

.ServiceModel.CommunicationException:

une erreur s'est produite lors de la requête HTTP à http://example.com/WebServices/SomeService.svc . Cela pourrait être dû au fait que le certificat du serveur n'est pas configuré correctement avec HTTP.SYS dans L'affaire HTTPS. Cela pourrait aussi être causé par un décalage de la liaison de sécurité entre le client et le serveur.

- - - > système.Net.WebException: la connexion sous-jacente a été fermée: une erreur inattendue s'est produite sur un envoi.

- - - > système.IO.IOException: impossibilité d'écrire des données à la connexion de transport: une connexion existante a été fermée de force par l'hôte distant.

notre licence du mandataire bluecoat a expiré! il n'était donc pas possible d'atteindre le parti externe (internet).

nous avons eu le même problème et, dans notre cas, il a été résolu en rétablissant le certificat et en créant de nouveau la reliure. Ce qui nous a menés là était le fait que même l'obtention d'un simple fichier image png sur le site donne la même erreur.

modifiez votre application client à 4.5 et plus. Si vous êtes 4.5 alors utiliser: System.Net.ServicePointManager.SecurityProtocol = Système.Net.SecurityProtocolType.Tls12 / Tls1.1 / Tls1.0 si nécessaire ou vous pouvez mettre à jour votre application à 4.6.1 ci-dessus.