SSL-соединение с WebService с недействительным обходным путем сертификата не работает

Question

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

Я нашел этот отличный фрагмент:

ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };

Я установил точку останова в операторе возврата, и она никогда не вызывается (пробовал тоже с отдельным методом).

IЯ также пытался установить для следующих свойств значение false:

ServicePointManager.UseNagleAlgorithm = false;
ServicePointManager.Expect100Continue = false; //tried true too
ServicePointManager.CheckCertificateRevocationList = false;

Я также пытался создать свой собственный ICertificatePolicy с CheckValidationResult, который всегда возвращает значение true и приписывает его ServicePointManager.CertificatePolicy.Это также не сработало.

Во всех этих попытках я получаю следующее:

Основное соединение было закрыто: при получении произошла непредвиденная ошибка

Я создал отдельное приложение для форм Windows всего с тремя строками:

WebReference.MySebService myWebService = new WebReference.MySebService();
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
bool result = myWebService.TestConnection(); 
//TestConnection is a method in my WebService that simply returns true.

И оно РАБОТАЛО.

Что еще можно попробовать?

Информация:

• Приложение WPF
• .NET 3.5
• Веб-сервис используется через отдельный класс
• Он отлично работает с обычным HTTP
• Не используется прокси
• Сбой как на сервере, так и с WS на localhost
• Те же три строки, которые выполняются в моем тестовом приложении, не будут работать в моем WPFapp
• Два экземпляра WebService абсолютно одинаковы (все свойства, включая URL)
• Попытка удаления и повторного добавления веб-ссылки, как в моих тестовых приложениях.

Answer 1

Подчеркнув много об этом, мы наконец-то пришли к решению.

Намек на это был во внутреннем исключении, которое раньше прошло незамеченным.Он заявил, что не смог загрузить сборку Security.

По совпадению у нас был проект с именем Security с выходной сборкой с именем Security для этого решения, что вызвало конфликт.И к нему обращались только неправильно, когда использовался SSL.

Интересно, что ни Visual Studio, ни компилятор не предупредили меня о том, что это не такая хорошая идея, и даже о том, что существует .NETсборка названа так же, как наша.

Решение было переименовать эту сборку, и все сразу заработало без ошибок.

Извлеченные уроки:

• Использовать настраиваемые именакоторый никогда не мог бы существовать, как SPONGEBOBSQUAREPANTS_Security.
• Не верьте, что Visual Studio проверит, не конфликтует ли моя сборка с чем-либо.
• Всегда проверяйте внутренние исключения, независимо от того, насколько знакомы их внешниеможет показаться.