Я использую этот код, чтобы сделать запрос по заданному URL:
private static string GetWebRequestContent(string url)
{
string sid = String.Empty;
HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create(url);
req.KeepAlive = false;
using (HttpWebResponse res = (HttpWebResponse)req.GetResponse())
{
using (StreamReader sr = new StreamReader(res.GetResponseStream()))
{
sid = sr.ReadToEnd().Trim();
}
}
return sid;
}
Я использую его для проверки устойчивости Work Load Balancer с тремя серверами за ним. Все они имеют статический файл HTM с именем sid.htm, в котором записан идентификатор сервера сервера.
Для URL-адресов с HTTP это работает нормально. Но с HTTPS это не работает. Я получаю это исключение:
The request was aborted: Could not create SSL/TLS secure channel.
На данный момент у меня есть только 2 сервера за WLB и один отдельный с общедоступным IP-адресом за брандмауэром. Запросы HTTPS работают нормально, если я попадаю на автономный сервер, но когда я нажимаю WLB, я получаю указанную выше ошибку.
Одно замечание: чтобы переключаться между обращением к одиночному серверу и WLB, я использую свой файл hosts. Записи DNS для моего домена на данный момент указывают на единственный сервер. Итак, я поместил запись в свой файл hosts, чтобы попасть в WLB. Это не должно вызывать проблем ...
Мой вопрос: Какие учетные данные / сертификаты SSL использует HttpWebRequest? Если он использует 40-битный DES или 56-битный DES, причина в том, что они отключены в WLB. Но эти сертификаты не использовались в браузерах со времен IE3 и Netscape 1 и 2.





Он отлично работает в моем браузере.
Я нашел решение через 1 минуту после того, как разместил вопрос:
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
И это означает, что HttpWebRequest использовал TLS 1.0 - я не знаю, но предполагаю, что это 40-битный DES или 56-битный DES, который отключен в WLB.
Есть кое-что, что вы могли бы рассмотреть с балансировщиком нагрузки. Те, которые мы используем, пересылают защищенный трафик HTTPS на серверы, находящиеся за ним, по незащищенному HTTP-соединению. Соединение между балансировщиком нагрузки и браузером по-прежнему является безопасным, но нет необходимости в использовании защищенного протокола между балансировщиком и веб-серверами.
Мы хотели обнаружить безопасное соединение на наших веб-серверах, но изначально никогда не видели HTTPS-соединения. Именно тогда мы поняли, что трафик за балансировщиком небезопасен. Как только мы узнали, это имело смысл.
Теперь мы перенаправляем весь безопасный трафик, поступающий в балансировщик (порт 443), на порт 81 (альтернативный HTTP), а затем перенаправляем весь обычный HTTP-трафик (порты 80 и 81) на порт 80. Затем мы можем проверить порт в Интернете. server and know 80 небезопасен, а 81 - безопасный трафик между браузером и балансировщиком, несмотря на то, что на веб-сервере используется весь HTTP.