Erreur WCF "Cela pourrait être dû au fait que le certificat du serveur n'est pas configuré correctement avec HTTP.SYS dans le cas de HTTPS"

Question

Je rencontre un problème en utilisant un appel WCF à partir d'un service Windows vers mon service WCF fonctionnant sur mon serveur web. Cet appel fonctionnait depuis plusieurs semaines, puis soudainement a cessé de fonctionner, et n'a pas fonctionné depuis.

L'exception que je reçois est :

Erreur Générale Système System.ServiceModel.CommunicationException : Une erreur s'est produite lors de la requête HTTP

et ensuite il dit :

Cela pourrait être dû au fait que le certificat du serveur n'est pas configuré correctement avec HTTP.SYS dans le cas du HTTPS. Cela pourrait également être causé par un désaccord de liaison de sécurité entre le client et le serveur.

La sécurité que j'utilise des deux côtés est wsHttpBinding, sans aucun type de chiffrement. Et cela utilise juste HTTP - pas HTTPS, donc je ne comprends pas pourquoi il se plaint du 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 de l'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 chez System.Net.Sockets.Socket.MultipleSend(BufferOffsetSize[] buffers, SocketFlags socketFlags) chez System.Net.Sockets.NetworkStream.MultipleWrite(BufferOffsetSize[] buffers)

Je dois également noter que le point dans mon programme où ceci se produit est sur la ligne "Execute" de l'appel au service web - c'est-à-dire, dès que j'appelle le service web et lui passe l'objet DataContract encapsulé, tout explose.

Tout ce que ce service fait, c'est recevoir une grande quantité de XML (transmise comme un objet .NET à l'appel du côté client), avec lequel il effectue des traitements. Probablement environ 100-200 ko de XML sont transmis. J'ai augmenté les limites des tailles de données des deux côtés à plus de 6 mégas, mais cela n'a pas semblé aider.

Des idées ?

---

Quelques informations supplémentaires sur ce problème :

Quand nous dupliquons l'environnement client localement, nous constatons que nous ne pouvons pas télécharger de grandes quantités de XML à moins de faire les changements suivants : 1. Sur le serveur, définir le "maxRequestLength" à 100 Mo (bien plus élevé que ce que nous envoyons) 2. Sur le client, nous définissons la valeur de maxItemsInObjectGraph sous la balise dataContractSerializer à "2147483646".

Avec ces changements, notre installation locale se télécharge avec succès. Cependant, l'installation du client sur leur serveur échoue toujours. Ce qui est intéressant à noter est qu'une fois que nous avons modifié la valeur de maxRequestLength sur le serveur, notre installation de test a commencé à afficher une erreur spécifiquement liée au réglage maxItemsInObjectGraph. Alors que sur le serveur du client, l'erreur originale "HTTP.sys" se produit toujours.

Comme je l'ai mentionné précédemment, nous n'utilisons pas du tout SSL, et il y a 2 autres appels de services web qui exécutent et téléchargent du XML de la même manière. Cependant, étant donné que l'appel de service non fonctionnel transmet plus de données, cela semble être un problème de taille.

Cependant, si le problème rencontré par le client était le même que celui de notre installation de test, je ne comprends pas pourquoi le message d'erreur du client ne serait pas lié à l'erreur de l'ObjectGraph.

Est-il possible que nous recevions simplement l'erreur générique "paramètre non valide" "HTTP.sys" pour chaque erreur possible du client (c'est-à-dire qu'il reçoit vraiment l'erreur de l'ObjectGraph aussi, mais ne l'affiche tout simplement pas ?)

Answer 1

Nous avons eu ce problème car le serveur hôte avait été mis à jour pour utiliser TLS V1.2 et nous nous connectons en utilisant le SSL standard. Ceci était une mise à jour effectuée dans le cadre des tests d'intrusion des sites. Nous avons constaté le problème dans la connection de code, mais pas sur les navigateurs allant vers le wsdl. Le code ci-dessous a résolu :

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

Extrait d'ici : Désactiver le repli SSL et utiliser uniquement TLS pour les connexions sortantes en .NET ? (Mitigation de Poodle)

Answer 2

J'ai rencontré le même problème sur un service s'exécutant sur IIS 7 le service se connecte à plusieurs serveurs de fournisseurs (certains en SSL, certains non) lors de l'ajout d'un nouveau fournisseur (ce nouveau fournisseur utilisait TLS 1.2), j'obtenais une erreur après quelques requêtes effectuées aux serveurs d'origine (SSL).

Pour confirmer cela, j'ai simplement journalisé le System.Net.ServicePointManager.SecurityProtocol avant chaque requête à chaque fournisseur.

À ma grande surprise, après avoir redémarré le service (ou redémarré le pool d'applications), je voyais en sortie Ssl3, Tls mais après quelques requêtes aux serveurs d'origine, cela passait à Ssl3 et les requêtes au service TLS donnaient une erreur.

Pour résoudre ce problème, j'ai simplement suivi la suggestion de l'utilisateur369142. Avant chaque requête au nouveau serveur :

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

et plus d'erreurs.

Answer 3

Dans mon cas, j'ai dû activer SchUseStrongCrypto pour .Net. Cela force le serveur à établir une connexion en utilisant TLS 1.0, 1.1 ou 1.2. Sans SchUseStrongCrypto activé, la connexion tentait d'utiliser SSL 3.0, qui était désactivé à mon extrémité distante.

Clés de registre pour activer l'utilisation de la cryptographie 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

Answer 4

J'ai eu ce problème avec une véritable liaison HTTPS et la même exception avec "Cela pourrait être dû au fait que le certificat du serveur n'est pas correctement configuré avec HTTP.SYS dans le cas HTTPS...". Après avoir tout vérifié dans le code et la configuration, il semble que le message d'erreur soit moins trompeur que les exceptions internes, donc après une rapide vérification, nous avons découvert que le port 443 était utilisé par Skype (sur le serveur de développement). Je vous recommande de jeter un œil à ce qui bloque la requête (Fiddler pourrait aider ici) et assurez-vous de pouvoir accéder au service à l'avant (visionnez le .svc dans votre navigateur) et à ses métadonnées.

Bonne chance.

Answer 5

Pour nous, cette erreur était due au fait que l'ordinateur du développeur exécutant le service avait configuré IIS 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, changez-la en *.