Erreur WCF "Cela peut être dû au fait que le certificat de serveur n'est pas configuré correctement avec HTTP.SYS dans le cas HTTPS"
Je rencontre un problème d'utilisation d'un appel WCF d'un service Windows vers mon service WCF exécuté sur mon serveur Web. Cet appel a fonctionné pendant un certain nombre de semaines, mais a ensuite soudainement cessé de fonctionner et ne fonctionne plus depuis.
L'exception que je reçois est:
Erreur générale survenue System.ServiceModel.CommunicationException: une erreur s'est produite lors de la requête HTTP
et puis il dit
Cela peut être dû au fait que le certificat de serveur n'est pas configuré correctement avec HTTP.SYS dans le cas HTTPS. Cela pourrait également être dû à une incompatibilité de la liaison de sécurité entre le client et le serveur.
La sécurité que j'utilise aux deux extrémités est wsHttpBinding, sans aucun type de cryptage. De plus, il utilise simplement HTTP - pas HTTPS, donc je ne sais pas pourquoi il se plaint de HTTPS.
Le reste de la pile d'exceptions internes est:
SystemNet.WebException: La connexion sous-jacente a été fermée: une erreur inattendue s'est produite lors d'un envoi. ---> System.IO.IOException: Impossible d'écrire des données sur la connexion de transport: Un argument non valide a été fourni. ---> System.Net.Sockets.SocketException: un argument non valide a été fourni à System.Net.Sockets.Socket.MultipleSend (buffersOffsetSize [] tampons, SocketFlags socketFlags) à System.Net.Sockets.NetworkStream.MultipleWrite (BufferOffsetS [] tampons)
Je devrais également noter que le moment où cela se produit dans mon programme se trouve sur la ligne "Exécuter" de l'appel du service Web - c'est-à-dire dès que j'appelle le service Web et le passe à l'objet DataContract encapsulé, il explose.
Ce service ne fait que transmettre une grande quantité de XML (transmis en tant qu’objet .NET à l’appel côté client), qu’il effectue ensuite avec un certain travail. Probablement environ 100-200k de XML sont en cours de transmission. J'ai augmenté la limite de taille des données aux deux extrémités à plus de 6 Mo, mais cela n'a pas semblé aider.
Des idées?
Quelques informations supplémentaires sur ce problème:
Lorsque nous dupliquons localement l'environnement client, nous constatons qu'il est impossible de télécharger de grandes quantités de XML à moins d'apporter les modifications suivantes: 1. Sur le serveur, définissez "maxRequestLength" sur 100 Mo (valeur supérieure à celle que nous envoyons) 2. Sur le client, nous définissons la valeur de maxItemsInObjectGraph sous la balise dataContractSerializer sur "2147483646".
Avec ces modifications, notre installation locale est chargée avec succès. Cependant, l'installation du client sur son serveur échoue toujours. Il est intéressant de noter que, une fois que nous avons modifié la valeur maxRequestLength sur le serveur, notre installation de test a commencé à générer une erreur liée spécifiquement au paramètre maxItemsInObjectGraph. Alors que sur le serveur de notre client, toujours l'erreur "HTTP.sys" est toujours en cours.
Comme je l'ai déjà indiqué, nous n'utilisons pas du tout SSL. Deux autres appels de services Web exécutent et téléchargent XML de la même manière. Toutefois, étant donné que l'appel de service non opérationnel transmet plus de données, cela semble être un problème de taille.
Cependant, si le problème rencontré par le client était identique à celui de notre installation de test, je ne comprends pas pourquoi le message d'erreur du client ne serait pas lié à l'erreur ObjectGraph.
Est-il possible que nous obtenions simplement l'erreur générique "paramètre invalide" "HTTP.sys" pour chaque erreur possible sur le client (c'est-à-dire qu'elle génère également l'erreur objectGraph, mais ne la montre tout simplement pas?)
Nous avions ce problème car le serveur hôte avait été mis à jour pour utiliser TLS V1.2 et nous nous connections à l'aide du protocole SSL standard. Il s’agissait d’une mise à jour effectuée dans le cadre des tests de plume des sites. Nous avons vu le problème dans la connexion de code, mais pas les navigateurs allant à wsdl . Le code ci-dessous est résolu:
if (System.Net.ServicePointManager.SecurityProtocol == (SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls))
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;
J'ai eu le même problème sur un service exécuté sur IIS 7 Le service se connecte à plusieurs serveurs de fournisseurs (certains SSL non) Lors de l'ajout d'un nouveau d'entre eux (ce nouveau fournisseur était TLS 1.2) Je voudrais obtenir l'erreur après quelques demandes ont été faites aux serveurs d'origine (SSL).
Pour le confirmer, j'ai simplement consigné le System.Net.ServicePointManager.SecurityProtocol avant chaque demande adressée à chaque fournisseur.
Faible et après le redémarrage du service (ou du pool d'applications), j'obtiendrais le Ssl3, Tls en sortie, mais après quelques requêtes adressées aux serveurs du fournisseur d'origine, ce dernier a été remplacé par Ssl3 et les requêtes adressées au service TLS ont généré l'erreur.
Pour réparer, j'ai simplement fait ce que user369142 avait suggéré. Avant chaque demande au nouveau serveur:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;
et pas plus d'erreurs.
Vous aviez ce problème avec une véritable liaison HTTPS et la même exception avec "Cela peut être dû au fait que le certificat de serveur n'est pas configuré correctement avec HTTP.SYS dans le cas HTTPS ...". Après avoir vérifié tous les éléments du code et de la configuration, il semble que le message d'erreur ne soit pas aussi trompeur que les exceptions internes. Ainsi, après une vérification rapide, nous avons découvert que le port 443 avait été connecté par skype ). Je vous recommande de regarder ce qui bloque la demande (Fiddler pourrait vous aider ici) et de vous assurer que vous pouvez accéder au service (voyez le .svc dans votre navigateur) et ses métadonnées.
Bonne chance.
Dans mon cas, je devais activer SchUseStrongCrypto pour .Net Cela oblige le serveur à établir la connexion à l'aide de TLS 1.0, 1.1 ou 1.2. Sans SchUseStrongCrypto activé, la connexion essayait d'utiliser SSL 3.0, qui était désactivé sur mon point de terminaison distant.
Clés de registre pour permettre l'utilisation de la crypto forte:
[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
Pour nous, cette erreur était due au fait que IIS était configuré sur l'ordinateur du développeur qui exécute le service pour lier le port 443 uniquement sur 127.0.0.1.
Dans le gestionnaire IIS, cliquez avec le bouton droit sur le site Web et choisissez Modifier les liaisons. Si l'entrée pour le port 443 a l'adresse IP 127.0.0.1, remplacez-la par *.
Nous avons eu à peu près exactement le même problème survenu récemment et il s’est avéré être causé par la mise à jour KB980436 de Microsoft ( http://support.Microsoft.com/KB/980436 ) installée sur l’ordinateur appelant. Le correctif pour nous, mis à part la désinstallation pure et simple, consistait à suivre les instructions du site de la base de connaissances pour configurer le DWORD UseScsvForTls dans le registre sur 1. Si cette mise à jour est installée sur votre système d'appel, vous pouvez l'essayer. .
Après avoir longuement cherché et pris le nom du seigneur en vain, je l’ai finalement trouvé. J’ai installé TLS 1.2 sur le serveur où mon service wcf est en cours d’exécution. wcf était sur .NET 4.6.1. Si vous utilisez TLS 1.2, le client et le serveur doivent avoir la même version .NET. J'espère que ça aidera quelqu'un un jour :-)
Je rencontrais ce problème lors de l'exécution d'anciennes XP SP3 sur IIS et sur glassfish sur Amazon AWS. Amazon a modifié ses paramètres d'équilibreur de charge par défaut pour NE PAS activer le chiffrement DES-CBC3-SHA. Vous devez l'activer sur Amazon ELB si vous souhaitez autoriser l'ancien XP TLS 1.0 à fonctionner avec ELB pour HTTPS, sinon vous obtiendrez cette erreur. Les chiffrements peuvent être modifiés sur ELB en accédant à l’onglet Écouteur de la console et en cliquant sur le chiffre situé en regard de l’auditeur particulier que vous essayez de faire fonctionner.
Si votre service WCF utilise .net Framework 4.0 et qu'une personne a désactivé TLS 1.0 sur le serveur, vous verrez cette exception. En raison de .net 4.0 ne supportant pas les versions supérieures de TLS.
Protocoles pris en charge: https://msdn.Microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.100).aspx
Modifiez votre application cliente à la version 4.5 et supérieure . SI vous êtes 4.5, utilisez: System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12/Tls1.1/Tls1.0 selon vos besoins ou vous pouvez mettre à niveau votre application au-dessus de 4.6.1.
J'ai vu ces exceptions particulières liées à des problèmes de DataType complexes, consultez l'article suivant si vous transmettez des collections ou des énumérations:
Notre problème était simplement que le numéro de port sur l'ordinateur d'extrémité avait été incorrectement défini sur 8080. Changé en 8443 et cela a fonctionné.
Essayez de parcourir le service dans le navigateur et en mode Https. Si ce n’est pas le cas, cela 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érifiez si les certificats pour https sont correctement configurés ou non (contrôle de l'autorité de signature, certificat auto-signé, utilisation de plusieurs certificats)
- vérifier la liaison et la configuration du service WCF pour le mode Https
Depuis que tout fonctionnait bien pendant des semaines, puis 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 lorsque votre code est appelé. Le moteur d'exécution pourrait simplement vérifier la configuration du site Web et émettre un message d'erreur générique qui n'a rien à voir avec le service.
Je soupçonne qu'un certificat a expiré ou que les liaisons sont configurées de manière incorrecte. Si le site Web est mal configuré pour HTTPS, cette erreur peut survenir, que votre code les utilise ou non.
Si vous utilisez le mode de transfert = streamé, essayez de le mettre en mémoire tampon.
Si ce n'est pas le problème, vous pouvez poster votre configuration.
Nous avons eu le même problème et, dans notre cas, le problème a été résolu en réinstallant le certificat et en créant à nouveau la liaison. Ce qui nous a conduit là-bas était le fait que même l’obtention d’un fichier image png simple sur le site donne la même erreur.
Tout récemment connu cela:
System.ServiceModel.CommunicationException:
Une erreur est survenue lors de envoi de la requête HTTP à http://example.com/WebServices/SomeService.svc . Cela pourrait être dû au fait que le certificat de serveur n’est pas configuré correctement. avec HTTP.SYS dans le cas HTTPS. Cela pourrait aussi être causé par un non concordance de la liaison de sécurité entre le client et le serveur.
---> System.Net.WebException: la connexion sous-jacente a été fermée: une erreur inattendue s'est produite lors d'un envoi.
---> System.IO.IOException: Impossible d'écrire des données sur la connexion de transport: une connexion existante a été fermée de force par le distant Hôte.
Un administrateur m'a informé que le pool d'applications IIS hébergeant le service Web était automatiquement recyclé après une insuffisance de mémoire. L'erreur sur le client s'est produite lors du recyclage du pool d'applications.
L'augmentation de la mémoire disponible dans le pool d'applications a résolu le problème immédiat.
Tout récemment connu cela:
System.ServiceModel.CommunicationException:
Une erreur s'est produite lors de l'envoi de la requête HTTP à http://example.com/WebServices/SomeService.svc . Cela peut être dû au fait que le certificat de serveur n'est pas configuré correctement avec HTTP.SYS dans le cas HTTPS. Cela pourrait également être dû à une incompatibilité de la liaison de sécurité entre le client et le serveur.
---> System.Net.WebException: la connexion sous-jacente a été fermée: une erreur inattendue s'est produite lors d'un envoi.
---> System.IO.IOException: Impossible d'écrire des données sur la connexion de transport: une connexion existante a été fermée de force par l'hôte distant.
Notre licence du proxy bluecoat a expiré! il n'a donc pas été possible de joindre la partie externe (internet).
Nos applications ont récemment été forcées de désactiver SSL vers TLS via une mise à jour du système d'exploitation de l'appliance réseau (F5). Nous avons corrigé cette erreur en générant à nouveau les certificats auto-signés. J'espère que cela aidera quelqu'un dans le futur à résoudre le problème car nous avons passé plusieurs dépannages de maintenance à résoudre avant d'arriver à la solution.