Помилка WCF "Це може бути пов'язано з тим, що сертифікат сервера неправильно налаштовано за допомогою HTTP.SYS у випадку HTTPS"

У мене проблема з використанням виклику 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 [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, але просто не відображає її?)

У нас виникла ця проблема, оскільки хост-сервер був оновлений для використання 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? (Пом'якшення пуделя)

У мене була та сама проблема у службі, що працює на 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;

і більше ніяких помилок.

Якби виникла ця проблема із справжнім прив'язуванням HTTPS і тим самим винятком з "Це може бути пов'язано з тим, що сертифікат сервера неправильно налаштовано за допомогою HTTP.SYS у випадку HTTPS ...". Після подвійної перевірки всього в коді та конфігурації здається, що повідомлення про помилку не настільки оманливе, як внутрішні винятки, тому після швидкої перевірки ми виявили, що порт 443 був підключений через Skype (на сервері розробника). Я рекомендую вам поглянути на те, що затримує запит (тут може допомогти Fiddler), і переконайтеся, що ви можете зв’язатися із службою (переглянути .svc у своєму браузері) та її метадані.

Удачі.

У моєму випадку мені довелося увімкнути 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

Для нас ця помилка полягала в тому, що на комп'ютері розробника, на якому запущена служба, було налаштовано IIS для прив'язки порту 443 лише на 127.0.0.1.

У Менеджері IIS клацніть веб-сайт правою кнопкою миші та виберіть Редагувати прив’язки. Якщо запис для порту 443має IP-адресу 127.0.0.1, змініть його на *.

Після довгих пошуків і марного вживання імені лорда я, нарешті, зрозумів. Я встановив TLS 1.2 на сервері, де працює моя служба wcf. Мій клієнт був налаштований правильно, але він був побудований на .NET 4.5.1, тоді як wcf був у .NET 4.6.1. Як клієнт, так і сервер повинні бути в одній версії .NET, якщо ви використовуєте TLS 1.2. Сподіваюсь, колись це комусь допоможе :-)

Змініть клієнтську програму на 4,5 і вище. ЯКЩО у вас 4,5, тоді використовуйте: System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 / Tls1.1 / Tls1.0 за потребою, або ви можете оновити свою програму до вище 4.6.1.

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

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

Якщо ваша служба 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

Я бачив ці особливі винятки, пов’язані зі складними проблемами типу даних, див. Наступний пост, якщо ви обходите колекції чи переліки:

Складні типи даних

Якщо ви використовуєте режим передачі = потоковий, спробуйте змінити його на буферизований.

Якщо це не проблема, чи можете ви опублікувати свою конфігурацію.

Оскільки тижнями все прекрасно працювало, а потім припинилося, я сумніваюся, що це має щось спільне з вашим кодом. Можливо, помилка виникає, коли послугу активовано в IIS / ASP.NET, а не під час виклику вашого коду. Виконавець міг просто перевіряти конфігурацію веб-сайту та видавати загальне повідомлення про помилку, яке не має нічого спільного з послугою.

Я підозрюю, що термін дії сертифіката закінчився або що прив’язки встановлені неправильно. Якщо веб-сайт неправильно налаштовано для HTTPS, незалежно від того, використовує їх ваш код чи ні, можливо, ви отримуєте цю помилку.

Спробуйте переглянути сервіс у браузері та в режимі Https, якщо він не переглядається, це доводить причину цієї помилки. Тепер, щоб вирішити цю помилку, потрібно перевірити:

• https-порт, перевірте, чи не використовується якимись іншими ресурсами (веб-сайт)
• Перевірте, чи сертифікат для https правильно налаштований чи ні (перевірте повноваження підпису, самопідписаний сертифікат, використовуючи кілька сертифікатів)
• перевірити прив'язку та конфігурацію служби WCF для режиму Https

Наша проблема полягала в тому, що номер порту в кінцевій точці був неправильно встановлений на 8080. Змінив його на 8443, і він спрацював.

Замість явного встановлення протоколу безпеки, кращим способом є встановити web.config <compilation targetFramework = "4.5"> або вище.

Я вирішив свою проблему, оновивши свою версію .NetFramework з 4.5.2 до 4.7.2.

Зовсім недавно це випробували:

System.ServiceModel.CommunicationException:

Під час надсилання запиту HTTP до http://example.com/WebServices/SomeService.svc сталася помилка . Це може бути пов'язано з тим, що сертифікат сервера неправильно налаштовано за допомогою HTTP.SYS у випадку HTTPS. Це також може бути спричинено невідповідністю прив'язки безпеки між клієнтом та сервером.

---> System.Net.WebException: Базове підключення було закрито: під час надсилання сталася несподівана помилка.

---> System.IO.IOException: Не вдається записати дані на транспортне з'єднання: віддаленим хостом примусово закрито існуюче з'єднання.

Я дізнався від адміністратора, що пул програм IIS, на якому розміщувалася веб-служба, автоматично переробляється після закінчення пам’яті. Помилка на клієнті сталася під час переробки пулу додатків.

Збільшення обсягу пам'яті, доступного для пулу програм, вирішило негайну проблему.

Наші програми нещодавно були вимушені вимкнути SSL на TLS через оновлення ОС мережевого пристрою (F5). Ми виправили цю помилку, повторно створивши самопідписані сертифікати. Сподіваємось, це допоможе комусь у майбутньому вирішити проблему, оскільки ми провели кілька способів усунення несправностей у вікнах технічного обслуговування, перш ніж знаходити рішення.

Зовсім недавно це випробували:

System.ServiceModel.CommunicationException:

Під час надсилання запиту HTTP до http://example.com/WebServices/SomeService.svc сталася помилка . Це може бути пов'язано з тим, що сертифікат сервера неправильно налаштовано за допомогою HTTP.SYS у випадку HTTPS. Це також може бути спричинено невідповідністю прив'язки безпеки між клієнтом та сервером.

---> System.Net.WebException: Базове підключення було закрито: під час надсилання сталася несподівана помилка.

---> System.IO.IOException: Не вдається записати дані на транспортне з'єднання: віддаленим хостом примусово закрито існуюче з'єднання.

У нас закінчилась ліцензія на довірену особу. тому не вдалося зв’язатися із зовнішньою стороною (Інтернет).

У нас була та сама проблема, і в нашому випадку вона була вирішена шляхом перевстановлення сертифіката та створення прив’язки знову. Що нас привело до того, що навіть отримання простого файлу із зображенням PNG на сайті видає ту саму помилку.