Не удалось установить доверительные отношения для безопасного канала SSL/TLS-SOAP


У меня есть простой вызов веб-службы, созданный приложением .NET (C#) 2.0 windows, через прокси-сервер веб-службы, созданный Visual Studio, для веб-службы, также написанной на C# (2.0). Это работало в течение нескольких лет, и продолжает делать это в дюжине или около того мест, где он работает.

новая установка на новом сайте сталкивается с проблемой. При попытке вызвать веб-службу, он терпит неудачу с сообщением:

не удалось установить доверительные отношения для SSL / TLS secure канал

URL веб-службы использует SSL (https://) - но это работает в течение длительного времени (и продолжает делать это) из многих других мест.

куда смотреть? Может ли это быть проблема безопасности между Windows и .NET, которая уникальна для этой установки? Если да, то где я могу установить доверительные отношения? Я заблудился!

15 291

15 ответов:

мысли (основанные на боли в прошлом):

  • есть ли у вас DNS и прямой видимости на сервер?
  • вы используете правильное имя из сертификата?
  • сертификат все еще действителен?
  • плохо настроенный балансировщик нагрузки все испортил?
  • новая сервер машина имеет часы установлены правильно (т. е. Так, что время UTC правильно [игнорировать местное время, это в значительной степени не имеет значения]) - это конечно, имеет значение для WCF, поэтому может повлиять на обычное мыло?
  • есть ли проблема с цепочкой доверия сертификатов? если вы перейдете с сервера на службу soap, вы можете получить SSL?
  • связано с вышеизложенным-сертификат был установлен в правильное место? (вам может понадобиться копия в доверенных корневых центрах сертификации)
  • правильно ли установлен прокси-сервер на уровне компьютера? (что отличается от прокси пользователя); см. proxycfg для XP / 2003 (не уверен в Vista и т. д.)

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

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

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

//Trust all certificates
System.Net.ServicePointManager.ServerCertificateValidationCallback =
    ((sender, certificate, chain, sslPolicyErrors) => true);

// trust sender
System.Net.ServicePointManager.ServerCertificateValidationCallback
                = ((sender, cert, chain, errors) => cert.Subject.Contains("YourServerName"));

// validate cert by calling a function
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);

// callback used to validate the certificate in an SSL conversation
private static bool ValidateRemoteCertificate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors policyErrors)
{
    bool result = false;
    if (cert.Subject.ToUpper().Contains("YourServerName"))
    {
        result = true;
    }

    return result;
}

очень простое решение" поймать все " заключается в следующем:

System.Net.ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };

решение от Себастьяна-кастальди немного более подробно.

лично мне больше всего нравится следующее решение:

using System.Security.Cryptography.X509Certificates;
using System.Net.Security;

... затем, прежде чем сделать запрос на получение ошибки, выполните следующие действия

System.Net.ServicePointManager.ServerCertificateValidationCallback = delegate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors) { return true; };

нашел это после консультаций Луки

Если вы используете Windows 2003, вы можете попробовать это:

Открыть Консоль Управления Microsoft (Start -- > Run -- > mmc.exe);

выберите Файл -- > Добавить / удалить оснастку;

на вкладке автономный выберите Добавить;

выберите оснастку "сертификаты" и нажмите кнопку Добавить;

в Мастере выберите компьютер Учетная запись, а затем выберите локальный Компьютер. Нажмите кнопку Готово, чтобы завершить волшебник;

закрыть диалоговое окно добавить / удалить оснастку;

перейдите к сертификатам (локальным Компьютер) и выбрать магазин, чтобы импорт:

Если у вас есть корневой сертификат CA для компании, которая выпустила сертификат, выберите доверенный корень Сертификационные Органы;

Если у вас есть сертификат сам сервер, выбирай других людей

щелкните правой кнопкой мыши магазин и выберите Все Задачи - > Импорт

следуйте указаниям Мастера и обеспечить файл сертификата у вас есть;

после этого просто перезапустите IIS и попробуйте повторный вызов веб-службы.

ссылка: http://www.outsystems.com/NetworkForums/ViewTopic.aspx?Topic=Web-Services:-Could-not-establish-trust-relationship-for-the-SSL/TLS-...

Если вы не хотите слепо доверять всем и сделать исключение доверия только для определенных хостов, следующее решение более подходит.

public static class Ssl
{
    private static readonly string[] TrustedHosts = new[] {
      "host1.domain.com", 
      "host2.domain.com"
    };

    public static void EnableTrustedHosts()
    {
      ServicePointManager.ServerCertificateValidationCallback = 
      (sender, certificate, chain, errors) =>
      {
        if (errors == SslPolicyErrors.None)
        {
          return true;
        }

        var request = sender as HttpWebRequest;
        if (request != null)
        {
          return TrustedHosts.Contains(request.RequestUri.Host);
        }

        return false;
      };
    }
}

тогда просто вызовите Ssl.EnableTrustedHosts при запуске приложения.

Microsoft средство диагностики SSL может помочь определить проблему.

обновление ссылка была исправлена.

Люк написал довольно хорошую статью об этом .. довольно прямолинейно .. дайте это попробовать

Луки

причина (цитата из его статьи (минус проклиная)) ".. Проблема с приведенным выше кодом заключается в том, что он не работает, если Ваш сертификат недействителен. Почему я должен отправлять сообщения на веб-страницу с недействительным сертификатом SSL? Потому что я дешевый, и я не хотел платить Verisign или один из других ** - * s для сертификата к моему тестовый ящик, поэтому я сам подписал его. Когда я отправил запрос, я получил прекрасное исключение, брошенное на меня:

System. Net. WebException основное соединение было закрыто. Не удалось установить доверительные отношения с удаленным сервером.

Я не знаю о вас, но для меня это исключение выглядело как что-то, что было бы вызвано глупой ошибкой в моем коде, которая приводила к сбою сообщения. Поэтому я продолжал искать, настраивать и делать все виды странная вещь. Только после того, как я погуглил ***N вещь, я узнал, что поведение по умолчанию после встречи с недопустимым сертификатом SSL-это бросить это самое исключение. .."

Я только что столкнулся с этой проблемой. Мое решение состояло в том, чтобы обновить системное время, вручную синхронизируясь с серверами времени. Для этого вы можете:

  • щелкните правой кнопкой мыши на часах в панели задач
  • выберите Adjust Date/Time
  • выберите Internet Time tab
  • клик Change Settings
  • выберите Update Now

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

У меня была похожая проблема .NET приложение в Internet Explorer.

Я решил проблему, добавив сертификат (сертификат VeriSign Class 3 в моем случае) в сертификаты доверенных редакторов.

перейдите в Свойства обозревателя - > контент - > издатели и импортируйте его

вы можете получить сертификат при экспорте из:

Свойства Обозревателя - > Содержимое - > Сертификаты - > Промежуточные Центры Сертификации - > Verisign Class 3 Public Primary Центр Сертификации-G5

попробуйте это:

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

обратите внимание, что вы должны работать по крайней мере с 4.5 .NET framework

у меня была эта ошибка работает против веб-сервера с url, как:

a.b.domain.com

но для этого не было сертификата, поэтому я получил DNS под названием

a_b.domain.com

просто положить намек на это решение здесь, так как это вышло на первое место в google.

для тех, у кого есть эта проблема через клиентскую сторону VS, как только успешно добавлена ссылка на службу и попытка выполнить первый вызов получила это исключение: "Базовое соединение было закрыто: не удалось установить доверительные отношения для безопасного канала SSL / TLS" Если вы используете (как в моем случае) URL-адрес конечной точки с IP-адресом и получили это исключение, то вам, вероятно, потребуется повторно добавить ссылку на службу, выполнив следующие действия:

  • откройте конечную точку URL в Internet Explorer.
  • нажмите на ошибку сертификата (красный значок в адресной строке)
  • нажмите на кнопку Просмотр сертификатов.
  • возьмите выданное: "имя "и замените IP-адрес или любое другое имя, которое мы использовали, и получите ошибку для этого"имени".

попробую еще раз :). Спасибо

в моем случае я пытался проверить SSL в моей среде Visual Studio с помощью IIS 7.

Это то, что я делал, чтобы заставить его работать:

  • под моим сайтом в ' привязки..."раздел справа в IIS, мне пришлось добавить привязку" https "к порту 443 и выбрать"сертификат разработки IIS Express".

  • В разделе "Мой сайт" в разделе "Дополнительные настройки"...'раздел справа мне пришлось изменить 'Протоколы' с "HTTP" на "HTTPS".

  • под значком "настройки SSL" я выбрал "принять" для клиентских сертификатов.

  • затем мне пришлось переработать пул приложений.

  • мне также пришлось импортировать сертификат локального хоста в мой личный магазин с помощью mmc.исполняемый.

мой web.config файл уже был настроен правильно, поэтому после того, как я получил все вышеперечисленное, я смог продолжить свою работу тестирование.

если не работает плохой сертификат, когда ServerCertificateValidationCallback возвращает true; Мой код ServerCertificateValidationCallback:

ServicePointManager.ServerCertificateValidationCallback += delegate
{
    LogWriter.LogInfo("Проверка сертификата отключена, на уровне ServerCertificateValidationCallback");
    return true;
};

мой код, который помешал выполнить ServerCertificateValidationCallback:

     if (!(ServicePointManager.CertificatePolicy is CertificateValidation))
    {
        CertificateValidation certValidate = new CertificateValidation();
        certValidate.ValidatingError += new CertificateValidation.ValidateCertificateEventHandler(this.OnValidateCertificateError);
        ServicePointManager.CertificatePolicy = certValidate;
    }

OnValidateCertificateError функция:

private void OnValidateCertificateError(object sender, CertificateValidationEventArgs e)
{
    string msg = string.Format(Strings.OnValidateCertificateError, e.Request.RequestUri, e.Certificate.GetName(), e.Problem, new Win32Exception(e.Problem).Message);
    LogWriter.LogError(msg);
    //Message.ShowError(msg);
}

Я отключил; также проверяется код и ServerCertificateValidationCallback работает очень хорошо