it-swarm.com.de

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

Ich habe ein Problem mit einem WCF-Aufruf von einem Windows-Dienst an meinen WCF-Dienst, der auf meinem Webserver ausgeführt wird. Dieser Anruf hat einige Wochen gearbeitet, dann aber plötzlich aufgehört zu arbeiten und hat seitdem nicht mehr funktioniert.

Die Ausnahme, die ich bekomme, ist:

Allgemeiner Fehler ist aufgetreten System.ServiceModel.CommunicationException: Bei der HTTP-Anforderung ist ein Fehler aufgetreten

und dann heißt es 

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

Die Sicherheit, die ich auf beiden Seiten verwende, ist wsHttpBinding ohne jegliche Art von Verschlüsselung. Es wird auch nur HTTP verwendet - nicht HTTPS, daher bin ich mir nicht sicher, warum HTTPS beschwert wird.

Der Rest des inneren Ausnahmestapels ist:

SystemNet.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Bei einem 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: Ein ungültiges Argument wurde unter System.Net.Sockets.Socket.MultipleSend (BufferOffsetSize [] Puffer, SocketFlags socketFlags) unter System.Net.Sockets.NetworkStream.MultipleWrite (BufferOffsetSize []) angegeben. Puffer)

Ich sollte auch beachten, dass der Punkt in meinem Programm, an dem dies auftritt, in der Zeile "Execute" des Aufrufs an den Web-Service liegt - das heißt, sobald ich den Web-Service anrufe und ihm das eingewickelte DataContract-Objekt übergebe in die Luft sprengen.

Dieser Dienst erhält lediglich eine große Menge von XML (wird als .NET-Objekt an den Aufruf auf der Clientseite übergeben), mit der er dann etwas arbeitet. Wahrscheinlich werden ungefähr 100 bis 200.000 XML übertragen. Ich habe die Grenzwerte für die Datengrößen an beiden Enden auf über 6 MB erhöht, aber das schien nicht zu helfen.

Irgendwelche Ideen?


Weitere Informationen zu diesem Thema:

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

Mit diesen Änderungen wird unsere lokale Installation erfolgreich hochgeladen. Die Clientinstallation auf ihrem Server schlägt jedoch weiterhin fehl. Interessant ist, dass nach der Änderung des maxRequestLength-Werts auf dem Server bei unserer Testinstallation ein Fehler aufgetreten ist, der sich speziell auf die Einstellung von maxItemsInObjectGraph bezieht. 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 Webservice-Aufrufe, die XML auf dieselbe Weise ausführen und hochladen. Da der nicht funktionierende Serviceanruf jedoch mehr Daten überträgt, scheint dies ein Größenproblem zu sein.

Wenn das Problem jedoch bei dem Client dasselbe war wie bei der Testinstallation, kann ich nicht verstehen, warum die Client-Fehlermeldung nicht mit dem ObjectGraph-Fehler zusammenhängt.

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

57
Sam Schutte

Wir hatten dieses Problem, da der Host-Server für die Verwendung von TLS V1.2 aktualisiert wurde und die Verbindung mit Standard-SSL hergestellt wurde. Dies war ein Update, das im Rahmen des Pen-Tests der Websites vorgenommen wurde. Wir haben das Problem bei der Codeverbindung gesehen, aber nicht bei Browsern, die zur wsdl ..__ gehen.

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

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

47
user369142

Ich hatte dasselbe Problem mit einem Dienst, der auf IIS 7 ausgeführt wird. Der Dienst stellt eine Verbindung zu mehreren Anbieterservern her (einige SSL nicht, einige nicht). Wenn ein neuer Server hinzugefügt wird (dieser neue Lieferant war TLS 1.2) Ich würde die Fehlermeldung erhalten, nachdem einige Anfragen an die ursprünglichen Server (SSL) gestellt wurden.

Um dies zu bestätigen, habe ich einfach den System.Net.ServicePointManager.SecurityProtocol vor jeder Anfrage an jeden Lieferanten angemeldet.

Niedrig und siehe da, nach dem Neustart des Dienstes (oder dem Neustart des Anwendungspools) würde ich die Ausgabe Ssl3, Tls erhalten, aber nach ein paar Anfragen an die ursprünglichen Anbieterserver wurde dies in Ssl3 geändert, und Anforderungen an den TLS-Dienst gaben den Fehler.

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

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

und keine fehler mehr.

18
Selwin Dedekind

Hatte dieses Problem mit einer echten HTTPS-Bindung und derselben Ausnahme mit "Dies könnte darauf zurückzuführen sein, dass das Serverzertifikat im HTTP-Fall nicht ordnungsgemäß mit HTTP.SYS konfiguriert ist ...". Nachdem wir alles in Code und config überprüft haben, scheint die Fehlermeldung nicht so irreführend wie die inneren Ausnahmen zu sein. Nach einer kurzen Überprüfung haben wir herausgefunden, dass der Port 443 über Skype (auf dem Dev-Server) angehängt wurde ). Ich empfehle Ihnen, einen Blick darauf zu werfen, was das Anhalten der Anfrage (Fiddler könnte hier helfen) und Sie können sicherstellen, dass Sie die Service-Front (sehen Sie die .svc-Datei in Ihrem Browser an) und ihre Metadaten.

Viel Glück.

9
nsides

In meinem Fall musste ich SchUseStrongCrypto für .Net .__ aktivieren. Dadurch wird der Server gezwungen, eine Verbindung mit TLS 1.0, 1.1 oder 1.2 herzustellen. Wenn SchUseStrongCrypto nicht aktiviert war, versuchte die Verbindung, SSL 3.0 zu verwenden, das an meinem Remote-Endpunkt deaktiviert war.

Registrierungsschlüssel, um die Verwendung von starker Verschlüsselung 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
6

Für uns war dieser Fehler, weil der Computer des Entwicklers, auf dem der Dienst ausgeführt wurde, IIS so konfiguriert war, dass Port 443 nur an 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 443 die IP-Adresse 127.0.0.1 hat, ändern Sie ihn in *.

5
Joe Daley

Wir hatten fast genau das gleiche Problem, das in der letzten Zeit aufgetreten ist, und es stellte sich heraus, dass das Microsoft-Update KB980436 ( http://support.Microsoft.com/KB/980436 ) auf dem aufrufenden Computer installiert wurde. Das Update für uns war, außer der vollständigen Deinstallation, das Befolgen der Anweisungen auf der KB-Site zum Festlegen des DWORD UseScsvForTls in der Registrierung auf 1. Wenn Sie feststellen, dass dieses Update in Ihrem aufrufenden System installiert ist, möchten Sie es vielleicht einmal ausprobieren .

4
atlas944

Nach langem Suchen und Entnehmen des Namens des Lords bekam ich es endlich. Ich habe TLS 1.2 auf dem Server installiert, auf dem mein WCF-Dienst ausgeführt wird wcf war auf .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 jemandem eines Tages :-)

3

Ich hatte dieses Problem, wenn ältere XP SP3-Boxen sowohl gegen IIS als auch gegen Glassfish unter Amazon AWS ausgeführt wurden. Amazon hat die Standardeinstellungen für den Lastausgleich geändert, um die DES-CBC3-SHA-Verschlüsselung NICHT zu aktivieren. Sie müssen dies auf Amazon ELB aktivieren, wenn Sie älteren TLS 1.0 XP zulassen möchten, dass sie gegen ELB für HTTPS arbeiten. Andernfalls erhalten Sie diesen Fehler. Verschlüsselungen können in ELB geändert werden, indem Sie in der Konsole auf die Registerkarte "Listener" gehen und auf die Verschlüsselung neben dem jeweiligen Listener klicken, den Sie bearbeiten möchten.

2
Fred Covely

Wenn Ihr WCF-Dienst das .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 TLS-Versionen nicht unterstützt.

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

2
user1069816

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

2
Shashank

Ich habe diese besonderen Ausnahmen gesehen, die sich auf Complex DataType-Probleme beziehen. Weitere Informationen finden Sie im folgenden Beitrag, wenn Sie Sammlungen oder Enumerationen durchgehen:

Komplexe Datentypen

1
Tanner

Unser Problem war einfach, dass die Portnummer auf dem Endpunkt falsch auf 8080 gesetzt wurde. Es wurde auf 8443 geändert und es funktionierte.

1
tntice

Versuchen Sie, den Dienst im Browser und im Https-Modus zu durchsuchen. Wenn dies nicht möglich ist, wird der Grund für diesen Fehler angezeigt. Um diesen Fehler zu beheben, müssen Sie Folgendes prüfen:

  • https-Port, prüfen Sie, ob er nicht von anderen Ressourcen (Website) verwendet wird 
  • Überprüfen Sie, ob das Zertifikat für https richtig konfiguriert ist oder nicht (Signaturautorität, selbstsigniertes Zertifikat, Verwendung mehrerer Zertifikate).
  • Überprüfen Sie die WCF-Service-Bindung und -Konfiguration für den Https-Modus
1
Ankur Bhutani

Da seit Wochen alles gut funktionierte und dann aufgehört hat, bezweifle ich, dass dies etwas mit Ihrem Code zu tun hat. Möglicherweise tritt der Fehler auf, wenn der Dienst aktiviert in IIS/ASP.NET ist, nicht wenn Ihr Code aufgerufen wird. Die Laufzeitumgebung könnte nur die Konfiguration der Website überprüfen und eine allgemeine Fehlermeldung ausgeben, 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, wird diese Fehlermeldung möglicherweise angezeigt, unabhängig davon, ob sie in Ihrem Code verwendet wird oder nicht.

1
Jacob

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

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

1
Shiraz Bhaiji

Wir hatten das gleiche Problem und in unserem Fall wurde dieses Problem gelöst, indem das Zertifikat erneut installiert und die Bindung erneut erstellt wurde. Was uns dahin führte, war die Tatsache, dass selbst eine einfache png-Bilddatei auf der Website denselben Fehler ergibt.

0
ByteArtisan

Das habe ich kürzlich erlebt:

System.ServiceModel.CommunicationException: 

Ein Fehler ist aufgetreten während HTTP-Anfrage an http://example.com/WebServices/SomeService.svc senden. Dies könnte fällig sein darauf, dass das Serverzertifikat nicht ordnungsgemäß konfiguriert ist mit HTTP.SYS im HTTPS-Fall. Dies könnte auch durch ein .__ verursacht werden. Nichtübereinstimmung der Sicherheitsbindung zwischen Client und Server. 

---> 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-Server .__ zwangsweise geschlossen. Wirt.

Ich habe von einem Administrator erfahren, dass der Anwendungspool IIS, in dem der Webdienst gehostet wurde, automatisch wiederverwendet wurde, nachdem der Speicher ausgeht. Der Fehler auf dem Client ist aufgetreten, als der Anwendungspool wiederverwendet wurde.

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

0

Das habe ich kürzlich erlebt:

System.ServiceModel.CommunicationException: 

Bei der HTTP-Anforderung an http://example.com/WebServices/SomeService.svc ist ein Fehler aufgetreten. Dies kann daran liegen, dass das Serverzertifikat im HTTP-Fall nicht ordnungsgemäß mit HTTP.SYS konfiguriert ist. Dies kann auch durch eine Nichtübereinstimmung der Sicherheitsbindung zwischen dem Client und dem 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 des Bluecoat Proxy ist abgelaufen! Daher war es nicht möglich, die externe Partei (Internet) zu erreichen.

0
MoLe

Unsere Anwendungen wurden kürzlich über ein Update der Netzwerk-Appliance (F5) von SSL zu TLS gezwungen. Dieser Fehler wurde behoben, indem die selbstsignierten Zertifikate erneut generiert wurden. Ich hoffe, das hilft jemandem in Zukunft, um das Problem zu lösen, da wir mehrere Fehler in der Wartung von Fenstern erledigt haben, bevor wir zur Lösung kommen.

0
mjw