WCF-Fehler "Dies kann daran liegen, dass das Serverzertifikat im HTTPS-Fall nicht ordnungsgemäß mit HTTP.SYS konfiguriert ist."

Ich habe ein Problem bei der Verwendung eines WCF-Aufrufs von einem Windows-Dienst an meinen WCF-Dienst, der auf meinem Webserver ausgeführt wird. Dieser Anruf funktioniert seit einigen Wochen, funktioniert dann aber plötzlich nicht mehr und hat seitdem nicht mehr funktioniert.

Die Ausnahme, die ich bekomme, ist:

Allgemeiner Fehler aufgetreten System.ServiceModel.CommunicationException: Beim Ausführen der HTTP-Anforderung ist ein Fehler aufgetreten

und dann heißt es

Dies kann daran liegen, dass das Serverzertifikat im HTTPS-Fall nicht ordnungsgemäß mit HTTP.SYS konfiguriert ist. Dies kann auch durch eine Nichtübereinstimmung der Sicherheitsbindung zwischen Client und Server verursacht werden.

Die Sicherheit, die ich an beiden Enden verwende, ist wsHttpBinding ohne jegliche Verschlüsselung. Es wird auch nur HTTP verwendet - nicht HTTPS, daher bin ich mir nicht sicher, warum es sich über HTTPS beschwert.

Der Rest des inneren Ausnahmestapels ist:

SystemNet.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Beim Senden ist ein unerwarteter Fehler aufgetreten. ---> System.IO.IOException: Daten können nicht in die Transportverbindung geschrieben werden: Es wurde ein ungültiges Argument angegeben. ---> System.Net.Sockets.SocketException: Bei System.Net.Sockets.Socket.MultipleSend (BufferOffsetSize [] -Puffer, SocketFlags-SocketFlags) bei System.Net.Sockets.NetworkStream.MultipleWrite (BufferOffsetSize] wurde ein ungültiges Argument angegeben Puffer)

Ich sollte auch beachten, dass der Punkt in meinem Programm, an dem dies auftritt, in der Zeile "Ausführen" des Aufrufs des Webdienstes liegt - das heißt, sobald ich den Webdienst aufrufe und ihm das verpackte DataContract-Objekt übergebe in die Luft sprengen.

Alles, was dieser Dienst tut, ist die Übergabe einer großen Menge an XML (als .NET-Objekt an den Aufruf auf der Clientseite übergeben), mit der er dann einige Arbeiten ausführt. Wahrscheinlich werden ungefähr 100-200k XML übertragen. Ich habe die Grenzwerte für die Datengrößen an beiden Enden auf über 6 Megabyte erhöht, aber das schien nicht zu helfen.

Irgendwelche Ideen?

Weitere Informationen zu diesem Thema:

Wenn wir die Client-Umgebung lokal duplizieren, stellen wir fest, dass wir keine großen Mengen an XML hochladen können, wenn wir nicht die folgenden Änderungen vornehmen: 1. Setzen Sie auf dem Server die "maxRequestLength" auf 100 MB (viel höher als beim Senden). 2. Ein Im Client setzen wir den Wert von maxItemsInObjectGraph unter dem Tag dataContractSerializer auf "2147483646".

Mit diesen Änderungen wird unsere lokale Installation erfolgreich hochgeladen. Die Installation des Clients auf seinem Server schlägt jedoch weiterhin fehl. Interessant ist, dass unsere Testinstallation nach der Änderung des Werts für maxRequestLength auf dem Server einen Fehler auslöste, der sich speziell auf die Einstellung maxItemsInObjectGraph bezog. Während auf dem Server unseres Clients immer noch der ursprüngliche Fehler "HTTP.sys" auftritt.

Wie bereits erwähnt, verwenden wir überhaupt kein SSL, und es gibt zwei weitere Webdienstaufrufe, die XML auf dieselbe Weise ausführen und hochladen. Da der nicht funktionierende Serviceabruf jedoch mehr Daten überträgt, scheint dies ein Größenproblem zu sein.

Wenn jedoch das Problem, das der Client hat, das gleiche war, das unsere Testinstallation hatte, verstehe ich nicht, warum die Client-Fehlermeldung nicht mit dem ObjectGraph-Fehler zusammenhängt.

Ist es möglich, dass wir nur den generischen Fehler "Ungültiger Parameter" "HTTP.sys" für jeden möglichen Fehler auf dem Client erhalten (dh es wird wirklich auch der Fehler objectGraph angezeigt, aber nur nicht angezeigt?)

Wir hatten dieses Problem, da der Hostserver für die Verwendung von TLS V1.2 aktualisiert wurde und wir eine Verbindung mit Standard-SSL herstellten. Dies war ein Update, das im Rahmen von Pen-Tests der Websites durchgeführt wurde. Wir haben das Problem in der Codeverbindung gesehen, aber keine Browser, die zur WSDL gehen. Der folgende Code wurde behoben:

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

Von hier aus: Wie deaktiviere ich den SSL-Fallback und verwende nur TLS für ausgehende Verbindungen in .NET? (Pudelminderung)

Ich hatte das gleiche Problem bei einem Dienst, der unter IIS 7 ausgeführt wird. Der Dienst stellt beim Hinzufügen eines neuen Servers (einige SSL, andere nicht) eine Verbindung zu mehreren Anbieterservern her (dieser neue Anbieter war TLS 1.2). Nach einigen Anfragen wurde der Fehler angezeigt auf den ursprünglichen Servern (SSL) gemacht.

Um dies zu bestätigen, habe ich einfach System.Net.ServicePointManager.SecurityProtocolvor jeder Anfrage bei jedem Lieferanten protokolliert .

Niedrig und siehe da, nach dem Neustart des Dienstes (oder nach dem Neustart des Anwendungspools) würde ich die Ausgabe erhalten, Ssl3, Tlsaber nach einigen Anfragen an die ursprünglichen Lieferantenserver wurde dies geändert Ssl3und Anfragen an den TLS-Dienst gaben den Fehler.

Um das Problem zu beheben, habe ich einfach das getan, was user369142 vorgeschlagen hat. Vor jeder Anfrage an den neuen Server:

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

und keine fehler mehr.

Hatte dieses Problem mit einer echten HTTPS-Bindung und der gleichen Ausnahme mit "Dies könnte daran liegen, dass das Serverzertifikat im HTTPS-Fall nicht ordnungsgemäß mit HTTP.SYS konfiguriert ist ...". Nachdem wir alles in Code und Konfiguration überprüft haben, scheint die Fehlermeldung nicht so irreführend zu sein wie die inneren Ausnahmen. Nach einer kurzen Überprüfung haben wir festgestellt, dass der Port 443 über Skype (auf dem Dev-Server) angeschlossen war. Ich empfehle Ihnen, einen Blick darauf zu werfen, was die Anfrage aufhält (Fiddler könnte hier helfen) und sicherzustellen, dass Sie die Service-Front (siehe .svc in Ihrem Browser) und deren Metadaten erreichen.

Viel Glück.

In meinem Fall musste ich SchUseStrongCrypto.Net aktivieren. Dies zwingt den Server, eine Verbindung mit TLS 1.0, 1.1 oder 1.2 herzustellen. OhneSchUseStrongCrypto Aktivierung versuchte die Verbindung, SSL 3.0 zu verwenden, das auf meinem Remote-Endpunkt deaktiviert war.

Registrierungsschlüssel, um die Verwendung einer starken Krypto zu ermöglichen:

[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

Für uns war dieser Fehler darauf zurückzuführen, dass auf dem Computer des Entwicklers, auf dem der Dienst ausgeführt wird, IIS so konfiguriert war, dass Port 443 nur auf 127.0.0.1 gebunden wird.

Klicken Sie im IIS-Manager mit der rechten Maustaste auf die Website und wählen Sie Bindungen bearbeiten. Wenn der Eintrag für Port 443eine IP-Adresse hat 127.0.0.1, ändern Sie diese in *.

Nachdem ich viel gesucht und den Namen des Lords vergeblich genommen hatte, bekam ich ihn endlich. Ich habe TLS 1.2 auf dem Server installiert, auf dem mein wcf-Dienst ausgeführt wird. Mein Client wurde korrekt konfiguriert, aber er wurde auf .NET 4.5.1 erstellt, während der wcf war unter .NET 4.6.1. Sowohl Client als auch Server müssen dieselbe .NET-Version haben, wenn Sie TLS 1.2 verwenden. Ich hoffe es hilft irgendwann jemandem :-)

Ändern Sie Ihre Client-Anwendung auf 4.5 und höher. Wenn Sie 4.5 sind, verwenden Sie: System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 / Tls1.1 / Tls1.0 nach Bedarf, oder Sie können Ihre Anwendung auf über 4.6.1 aktualisieren.

In letzter Zeit trat fast genau das gleiche Problem auf, das durch die Installation des Microsoft-Updates KB980436 ( http://support.microsoft.com/KB/980436 ) auf dem aufrufenden Computer verursacht wurde. Abgesehen von der vollständigen Deinstallation haben wir die Anweisungen auf der KB-Site befolgt, um das UseScsvForTls-DWORD in der Registrierung auf 1 zu setzen. Wenn Sie sehen, dass dieses Update in Ihrem aufrufenden System installiert ist, können Sie es ausprobieren .

Ich hatte dieses Problem beim Ausführen älterer XP SP3-Boxen gegen IIS und Glassfish unter Amazon AWS. Amazon hat die Standardeinstellungen für den Load Balancer so geändert, dass die DES-CBC3-SHA-Verschlüsselung NICHT aktiviert wird. Sie müssen dies auf Amazon ELB aktivieren, wenn Sie älteren XP TLS 1.0 erlauben möchten, gegen ELB für HTTPS zu arbeiten. Andernfalls wird dieser Fehler angezeigt. Chiffren können in ELB geändert werden, indem Sie in der Konsole auf die Registerkarte Listener gehen und neben dem Listener, den Sie zum Laufen bringen möchten, auf Chiffre klicken.

Wenn Ihr WCF-Dienst .net Framework 4.0 verwendet und jemand TLS 1.0 auf dem Server deaktiviert hat, wird diese Ausnahme angezeigt. Aufgrund von .net 4.0 werden die höheren Versionen von TLS nicht unterstützt.

Unterstützte Protokolle: https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.100).aspx

Ich habe diese besonderen Ausnahmen im Zusammenhang mit komplexen DataType-Problemen gesehen. Weitere Informationen finden Sie im folgenden Beitrag, wenn Sie Sammlungen oder Aufzählungen weitergeben:

Komplexe Datentypen

Wenn Sie den Übertragungsmodus = gestreamt verwenden, ändern Sie ihn in gepuffert.

Wenn dies nicht das Problem ist, können Sie Ihre Konfiguration veröffentlichen.

Da alles wochenlang gut funktionierte und dann aufhörte, bezweifle ich, dass dies irgendetwas mit Ihrem Code zu tun hat. Möglicherweise tritt der Fehler auf, wenn der Dienst aktiviert wird in IIS / ASP.NET , nicht, wenn Ihr Code aufgerufen wird. Die Laufzeit könnte lediglich darin bestehen, die Konfiguration der Website zu überprüfen und eine allgemeine Fehlermeldung auszulösen, die nichts mit dem Dienst zu tun hat.

Mein Verdacht ist, dass ein Zertifikat abgelaufen ist oder dass die Bindungen falsch eingerichtet sind. Wenn die Website für HTTPS falsch konfiguriert ist, unabhängig davon, ob Ihr Code sie verwendet oder nicht, wird möglicherweise dieser Fehler angezeigt.

Versuchen Sie, den Dienst im Browser und im HTTP-Modus zu durchsuchen. Wenn er nicht durchsuchbar ist, ist dies der Grund für diesen Fehler. Um diesen Fehler zu beheben, müssen Sie Folgendes überprüfen:

• https-Port, prüfen Sie, ob er nicht von anderen Ressourcen verwendet wird (Website)
• Überprüfen Sie, ob das Zertifikat für https ordnungsgemäß konfiguriert ist oder nicht (überprüfen Sie die Signaturberechtigung, das selbstsignierte Zertifikat und verwenden Sie mehrere Zertifikate).
• Überprüfen Sie die Bindung und Konfiguration des WCF-Dienstes für den HTTP-Modus

Unser Problem war einfach, dass die Portnummer auf dem Endpunkt fälschlicherweise auf 8080 eingestellt war. Sie wurde in 8443 geändert und funktionierte.

Anstatt das Sicherheitsprotokoll explizit festzulegen, ist es besser, die Datei web.config <compilation targetFramework = "4.5"> oder höher festzulegen.

Ich habe mein Problem gelöst, indem ich meine .NetFramework-Version von 4.5.2 auf 4.7.2 aktualisiert habe.

Erst kürzlich erlebt dies:

System.ServiceModel.CommunicationException:

Beim Senden der HTTP-Anforderung an http://example.com/WebServices/SomeService.svc ist ein Fehler aufgetreten . Dies kann daran liegen, dass das Serverzertifikat im HTTPS-Fall nicht ordnungsgemäß mit HTTP.SYS konfiguriert ist. Dies kann auch durch eine Nichtübereinstimmung der Sicherheitsbindung zwischen Client und Server verursacht werden.

---> System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Beim Senden ist ein unerwarteter Fehler aufgetreten.

---> System.IO.IOException: Daten können nicht in die Transportverbindung geschrieben werden: Eine vorhandene Verbindung wurde vom Remote-Host zwangsweise geschlossen.

Ich habe von einem Administrator erfahren, dass der IIS-Anwendungspool, in dem der Webdienst gehostet wurde, automatisch wiederverwendet wird, nachdem nicht genügend Speicher vorhanden ist. Der Fehler auf dem Client trat auf, als der Anwendungspool wiederverwendet wurde.

Durch Erhöhen des für den Anwendungspool verfügbaren Speichers wurde das unmittelbare Problem behoben.

Unsere Anwendungen wurden kürzlich über ein Betriebssystem-Update der Network Appliance (F5) von SSL zu TLS gezwungen. Wir haben diesen Fehler behoben, indem wir die selbstsignierten Zertifikate neu generiert haben. Ich hoffe, dies hilft jemandem in Zukunft, das Problem zu beheben, da wir mehrere Wartungsfenster zur Fehlerbehebung aufgewendet haben, bevor wir zur Lösung gekommen sind.

Erst kürzlich erlebt dies:

System.ServiceModel.CommunicationException:

Beim Senden der HTTP-Anforderung an http://example.com/WebServices/SomeService.svc ist ein Fehler aufgetreten . Dies kann daran liegen, dass das Serverzertifikat im HTTPS-Fall nicht ordnungsgemäß mit HTTP.SYS konfiguriert ist. Dies kann auch durch eine Nichtübereinstimmung der Sicherheitsbindung zwischen Client und Server verursacht werden.

---> System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Beim Senden ist ein unerwarteter Fehler aufgetreten.

---> System.IO.IOException: Daten können nicht in die Transportverbindung geschrieben werden: Eine vorhandene Verbindung wurde vom Remote-Host zwangsweise geschlossen.

Unsere Lizenz für den Bluecoat-Proxy ist abgelaufen! es war also nicht möglich, die externe Partei (Internet) zu erreichen.

Wir hatten das gleiche Problem und in unserem Fall wurde es behoben, indem das Zertifikat neu installiert und die Bindung erneut erstellt wurde. Was uns dorthin führte, war die Tatsache, dass selbst das Abrufen einer einfachen PNG-Bilddatei auf der Website den gleichen Fehler verursacht.