Visual Studio не может добавить ресурс WSDL в Windows Vista или более поздней версии через обратный прокси-сервер Apache - PullRequest
1 голос
/ 11 мая 2011

На этом я сошел с ума.

К вашему сведению, я работаю в инфраструктуре, а не в разработке .net, поэтому я очень мало знаю о WCF и почти ничего не знаю о Visual Studio как среде, но я не думаю, что именно в этом проблема.

У нас есть служба WCF, работающая на нескольких серверах IIS 7.5 во внутренней сети. Это доступно внешнему миру через обратный прокси-сервер на Apache 2.2.15 в Fedora 11. Обратный прокси-сервер управляет балансировкой нагрузки между серверами IIS, а также SSL.

Служба WCF настроена на использование безопасности транспортного уровня, а серверы IIS имеют самозаверяющие сертификаты SSL. Обратный прокси-сервер не проверяет подлинность серверов IIS, и единственная причина, по которой мы имеем SSL на серверах IIS, в первую очередь, заключается в том, что WSDL предоставит правильный URL-адрес местоположения.

Мы думали, что у нас все отлично работает, но есть одно досадное и решающее исключение: WSDL не может быть добавлен в качестве ссылки на службу в Visual Studio на компьютерах с Windows Vista или более поздней версией. На машине с XP это нормально, но все, что позже выдает следующую ошибку:

Произошла ошибка при загрузке '[URL]. Время операции истекло Метаданные содержат ссылку, которая не может быть решена: '[URL]'. Ошибка произошло при выполнении HTTP-запроса на [URL]. Это может быть связано с тот факт, что сертификат сервера неправильно настроен с HTTP.SYS в случае HTTPS. Это также может быть вызвано несоответствием безопасности связывание между клиентом и сервер. Основная связь была закрыто: произошла непредвиденная ошибка на отправку. Получил неожиданный EOF или 0 байтов из транспортного потока. Если услуга определена в текущее решение, попробуйте построить решение и добавление услуги ссылка снова.

WSDL доступен через браузер или обычный SOAP на любом компьютере и без каких-либо жалоб на SSL. Проблема возникает только в Visual Studio.

Первоначальный поиск в Google показал, что это может быть проблема с набором шифров, который использует VS, предполагая, что VS в Vista или более поздней версии по умолчанию будет пытаться использовать TLS1.0 в соединениях HTTPS, и если промежуточное устройство не поддерживает это протокол, он просто отбросит запрос. Это, безусловно, не тот случай. Обратный прокси-сервер явно предпочитает TLS1.0, и даже при просмотре WSDL через браузер он помечается как использующий TLS1.0 для соединения.

Указав прокси на другие работающие службы WCF на разных серверах IIS, возникает та же ошибка, из-за чего я предполагаю, что она вращается вокруг конфигурации обратного прокси. Проблема в том, что он, похоже, одинаково настроен на другой обратный прокси-сервер, выполняющий ту же задачу в другом месте.

Вероятно, существует проблема транспортного уровня, связанная с тем, как VS устанавливает HTTPS-соединения в разных операционных системах, но я просто не знаю достаточно об этом, чтобы рискнуть предположить, что это может быть. У кого-нибудь есть предложения?

1 Ответ

0 голосов
/ 11 мая 2011

Ну, это было неловко.

Я уверен, что есть какой-то неписанный космический закон, который приводит к тому, что я нахожу невероятно простое решение проблемы, над которой я работал в течение нескольких дней, через десять минут после публикации его в StackOverflow.

Директива ServerName в конфигурации виртуального хоста не соответствует URL. Он действительно соответствовал сертификату (у которого есть альтернативное имя субъекта, поэтому он не выдавал никаких предупреждений SSL), но это было не то имя, с которым я обращался к нему.

Я предполагаю, что есть некое расширение TLS1.0, которое использует VS, которое обеспечивает это, которое не используется браузерами или клиентами SOAP. Это, вероятно, полезная информация для всех, кто пытается это сделать с помощью сертификата с альтернативными именами субъектов. Иначе бы не подошло.

...