Ошибка WCF «Это может быть связано с тем, что сертификат сервера не настроен должным образом с HTTP.SYS в случае HTTPS»

Question

У меня проблема с использованием вызова WCF из службы Windows к моей службе WCF, запущенной на моем веб-сервере. Этот звонок работал несколько недель, но затем внезапно перестал работать и с тех пор не работает.

Исключение, которое я получаю:

Произошла общая ошибка System.ServiceModel.CommunicationException: при выполнении HTTP-запроса произошла ошибка

и тогда он говорит

Это может быть связано с тем, что сертификат сервера не настроен должным образом с HTTP.SYS в случае HTTPS. Это также может быть вызвано несоответствием привязки безопасности между клиентом и сервером.

Безопасность, которую я использую на обоих концах, - это wsHttpBinding, без какого-либо шифрования. Он также использует HTTP, а не HTTPS, поэтому я не уверен, почему он жалуется на HTTPS.

Остальная часть внутреннего стека исключений:

SystemNet.WebException: базовое соединение было закрыто: при отправке произошла непредвиденная ошибка. ---> System.IO.IOException: невозможно записать данные в транспортное соединение: указан неверный аргумент. ---> System.Net.Sockets.SocketException: недопустимый аргумент был предоставлен в System.Net.Sockets.Socket.MultipleSend (BufferOffsetSize [], SocketFlags socketFlags) в System.Net.Sockets.NetworkStream.MultipleWrite (BufferOffsetSize [] буферы)

Я должен также отметить, что точка в моей программе, где это происходит, находится в строке «Выполнить» вызова веб-службы, то есть сразу после того, как я вызову веб-службу и передам ей свернутый DataContract объект взрывается.

Все, что делает этот сервис, - это передает большой объем XML (передаваемый как объект .NET для вызова на стороне клиента), с которым он затем выполняет некоторую работу. Вероятно, передается около 100-200 Кб XML. Я увеличил ограничения для размеров данных на обоих концах до более 6 мегабайт, но это, похоже, не помогло.

Есть идеи?

---

Дополнительная информация по этому вопросу:

Когда мы локально дублируем клиентскую среду, мы обнаруживаем, что не можем загружать большие объемы XML, если не внесем следующие изменения: 1. На сервере установите «maxRequestLength» на 100 МБ (намного выше, чем мы отправляем) 2. На клиенте мы устанавливаем значение maxItemsInObjectGraph в теге dataContractSerializer равным 2147483646.

С этими изменениями наша локальная установка успешно загружена. Тем не менее, установка клиента на его сервере все еще не удается. Интересно отметить, что после того, как мы изменили значение maxRequestLength на сервере, наша тестовая установка начала выдавать ошибку, относящуюся к параметру maxItemsInObjectGraph. В то время как на сервере нашего клиента все еще происходит ошибка «HTTP.sys».

Как я уже отмечал ранее, мы вообще не используем SSL, и есть еще 2 вызова веб-служб, которые выполняют и загружают XML таким же образом. Однако, поскольку нерабочий сервисный вызов передает больше данных, это кажется проблемой размера.

Однако, если проблема, с которой сталкивался клиент, была та же, что и у нашей тестовой установки, я не понимаю, почему сообщение об ошибке клиента не было бы связано с ошибкой ObjectGraph.

Возможно ли, что мы просто получаем общую ошибку «неверный параметр» «HTTP.sys» для каждой возможной ошибки на клиенте (т. Е. Она действительно получает ошибку objectGraph, но просто не показывает ее? )

Answer 1

У нас была эта проблема, поскольку хост-сервер был обновлен для использования TLS V1.2, и мы подключались с использованием стандартного SSL. Это было обновление, сделанное в рамках ручного тестирования сайтов. Мы видели проблему в соединении кода, но не браузеры, идущие к wsdl. Ниже разрешен код:

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

Взято отсюда: Как отключить резервный SSL и использовать только TLS для исходящих соединений в .NET? (Смягчение пуделя)

Answer 2

У меня была такая же проблема на службе, работающей на IIS 7 служба подключается к нескольким серверам поставщиков (некоторые SSL не некоторые) при добавлении нового из них (этим новым поставщиком был TLS 1.2) я получал ошибку после нескольких запросов к исходным серверам (SSL).

Чтобы подтвердить это, я просто записывал System.Net.ServicePointManager.SecurityProtocol перед каждым запросом к каждому поставщику.

Низкий и вот, после перезапуска службы (или перезапуска пула приложений) я получу вывод Ssl3, Tls, но после нескольких запросов к серверам исходного поставщика это значение изменилось на Ssl3 и запросы к службе TLS дали ошибку .

Чтобы исправить, я просто сделал то, что предложил пользователь 369142. Перед каждым запросом на новый сервер:

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

и больше ошибок нет.

Answer 3

Возникла эта проблема с истинной привязкой HTTPS и тем же исключением с «Причиной может быть то, что сертификат сервера не настроен должным образом с HTTP.SYS в случае HTTPS ...». После двойной проверки всего в коде и конфигурации кажется, что сообщение об ошибке не так вводит в заблуждение, как внутренние исключения, поэтому после быстрой проверки мы обнаружили, что порт 443 был перехвачен скайпом (на сервере dev). Я рекомендую вам взглянуть на то, что задерживает запрос (Fiddler может помочь здесь), и убедиться, что вы можете добраться до фронта службы (посмотрите .svc в вашем браузере) и его метаданных.

Удачи.

Answer 4

В моем случае мне пришлось включить SchUseStrongCrypto для .Net Это заставляет сервер устанавливать соединение с использованием TLS 1.0, 1.1 или 1.2. Без включения SchUseStrongCrypto соединение пыталось использовать SSL 3.0, которое было отключено на моей удаленной конечной точке.

Ключи реестра, позволяющие использовать надежное шифрование:

[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 5

После долгих поисков и тщетного принятия имени лорда я наконец-то получил его. Я установил TLS 1.2 на сервере, где работает моя служба wcf. Мой клиент был настроен правильно, но он был построен на .NET 4.5. 1, тогда как wcf был на .NET 4.6.1. Клиент и сервер должны иметь одинаковую версию .NET, если вы используете TLS 1.2. Надеюсь, это кому-нибудь когда-нибудь поможет: -)

Answer 6

Для нас эта ошибка была из-за того, что на компьютере разработчика, на котором запущена служба, IIS был настроен для привязки порта 443 только на 127.0.0.1.

В диспетчере IIS щелкните правой кнопкой мыши веб-сайт и выберите «Редактировать привязки». Если запись для порта 443 имеет IP-адрес 127.0.0.1, измените ее на *.

Answer 7

Измените ваше клиентское приложение на 4.5 и выше. Если вам 4,5, тогда используйте: System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 / Tls1.1 / Tls1.0, если необходимо, или вы можете обновить приложение до версии выше 4.6.1.

Answer 8

У нас почти точно такая же проблема возникла недавно, и она, как оказалось, была вызвана обновлением Microsoft KB980436 (http://support.microsoft.com/KB/980436), установленным на вызывающем компьютере. Исправление для нас, кроме прямой деинсталляции, заключалось в следуйте инструкциям на сайте базы знаний, чтобы установить DWORD UseScsvForTls в реестре на 1. Если вы видите, что это обновление установлено в вашей вызывающей системе, вы можете попробовать его.

Answer 9

У меня была эта проблема при запуске старых пакетов XP SP3 для IIS и glassfish на Amazon AWS. Amazon изменил свои настройки балансировки нагрузки по умолчанию, чтобы НЕ включать шифр DES-CBC3-SHA. Вы должны включить это на Amazon ELB, если вы хотите, чтобы более старая XP TLS 1.0 работала против ELB для HTTPS, в противном случае вы получите эту ошибку. Шифры можно изменить в ELB, перейдя на вкладку слушателя в консоли и нажав на шифр рядом с конкретным слушателем, которого вы пытаетесь заставить работать.

Answer 10

Если ваша служба WCF использует .net framework 4.0 и кто-то отключил TLS 1.0 на сервере, вы увидите это исключение. Из-за .net 4.0 не поддерживает более высокие версии TLS.

Поддерживаемые протоколы: https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.100).aspx