Невозможно опубликовать https WebRequest в .net?
Привет, я столкнулся с проблемами при попытке отправить WebRequest через Https.
я получил следующие ошибки
1.-Базовое соединение было закрыто: невозможно подключиться к удаленному серверу.
2.-операция TimeOut
3-Базовое соединение было закрыто: не удалось установить безопасный канал для SSL / TLS.
Я пробовал использовать примерно 3 или 4 разных прокси моей компании и компании-клиента, и даже когда я напрямую с поставщиком интернет-услуг без ограничений, я получаю указанные выше ошибки при выполнении следующего метода
WebRequest.GetRequestStream()
это происходит за прокси или нет, запрос может быть успешно отправлен только с одного ПК, который находится за прокси. на прокси-сервере не установлен сертификат клиента.
это находится под .net framework 1.1 и запрос уже содержит сетевые учетные данные.
что могло быть?
Обновлять
внутреннее исключение 3-й ошибки следующее: Функция успешно завершена, но ее необходимо вызвать снова, чтобы завершить контекст.
согласно iisper.h документация эта ошибка принадлежит
//
// MessageId: SEC_I_CONTINUE_NEEDED
//
// MessageText:
//
// The function completed successfully, but must be called
// again to complete the context
//
#define SEC_I_CONTINUE_NEEDED ((HRESULT)0x00090312L)
на MSDN это относится к
SEC_I_CONTINUE_NEEDED Клиент должен отправить выходной токен на сервер и дождаться возвратного токена. Затем возвращенный токен передается в другой вызов InitializeSecurityContext (Schannel). Выходной токен может быть пустым.
означает ли это, что на ПК отсутствует сертификат клиента?
Ответы 4
Имя сертификата SSL, вероятно, не совпадает. Это часто бывает с самоподписанными сертификатами.
Решение состоит в том, чтобы написать свою собственную процедуру аутентификации, в которой вы либо всегда возвращаете true, либо выполняете необходимую аутентификацию, чтобы убедиться, что сертификат действителен.
// .NET 2.0+
...
ServicePointManager.ServerCertificateValidationCallback += MyValidationCallback
...
public bool MyValidationCallback(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors err)
{
return true;
}
// .NET 1.1
public class MyCertificatePolicy : ICertificatePolicy
{
public bool CheckValidationResult(ServicePoint srvPoint, X509Certificate certificate, WebRequest request, int certificateProblem)
{
return true;
}
}
...
ServicePointManager.CertificatePolicy = new MyCertificatePolicy();
...
Я уже пробовал это, но во время отладки он не останавливается на CheckValidationResult, поэтому я предполагаю, что во время рукопожатия возникла проблема. Спасибо
В C# 2.0+ кратчайший способ выразить это: ServicePointManager.ServerCertificateValidationCallback += delegate { return true; };.
Вы правы. Однако я хотел проиллюстрировать разницу между .NET 1.1 и 2.0+.
Есть целый ряд вещей, которые могут усложнить ситуацию, например несоответствия с сертификатами SSL и т. д. Но сначала вы должны выполнить базовую отладку, чтобы исключить очевидные вещи:
- Вы пробовали отправить простой веб-запрос на другие серверы? Попробуйте оба (незащищенный) http и (защищенный) https
- Вы пробовали подключиться с другого компьютера или из другой сети? Вы упомянули, что клиент находится за прокси-сервером; сначала попробуйте компьютер без прокси, чтобы исключить это.
- Вы делаете несколько веб-запросов в течение сеанса? Существует жесткое ограничение на количество открытых запросов, поэтому убедитесь, что вы закрываете их после получения WebResponse. Возможно, сделайте тестовую программу с помощью всего одного запроса.
Если это не сужает круг вопросов, то, вероятно, это что-то более сложное, с их сервером или прокси. Вы можете отслеживать исходящие сетевые пакеты с помощью такой программы, как netshark, чтобы попытаться отследить, где что-то застревает.
Я уже пробовал разные сети, как вы думаете, может быть, машина, которая может отправлять сообщения в службу, имеет сертификат клиента. Я не могу получить доступ к этой машине, и мне сказали, что у меня ее не было
это единственный запрос, который уже отлажен с теми же результатами
звучит как ограничение IP
Вы можете отслеживать HTTP-трафик с помощью Скрипач или инструмента сниффинга сетевых пакетов, такого как Эфирный Whireshark, на машине, на которой он работает, и на одной из других машин, и сравнивать результаты. Это довольно низкий уровень, но он может пролить свет на проблему.
- Если вы можете использовать telnet с разных машин на 443, то это не первые два, так как это означает, что клиентская машина получает запросы на этот порт.
В окнах это было бы
telnet <domainname> 443
и если он подключится, экран погаснет (несколько раз нажмите return, чтобы выйти)
Прокси-серверы могут или не могут действительно заботиться о вашем запросе, если он находится под HTTPS, поскольку они не могут его прочитать.
Установлены ли на других машинах сертификат клиента и цепочка сертификатов?
как я могу теперь, если на машине требуется сертификат клиента?
если вы перейдете по URL-адресу в браузере, он предложит вам сертификат, если он нужен. Если он нужен, вам придется спросить людей, которые запускают сервер, какой из них вам нужен.
публикация может быть сделана только с одного компьютера, поэтому это означает, что сертификат ssl верен.