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

Question

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

Теперь первое приложение WCF вызывает второй WCF для определенной функции. После вызова второго WCF первого выдается исключение

"Could not establish trust relationship for the SSL/TLS secure channel..."

Я видел похожие вопросы, но разница в том, что мой должен работать, так как он использует тот же сертификат. Что может происходить?

РЕДАКТИРОВАТЬ:

в основном вот как второй WCF вызывается внутри метода в первом WCF,

public void SomeMethod(string parameter)
{
   SecondServiceClient svc2 = new SecondServiceClient ("BasicHttpBinding_IService2");
   svc2.DoWork(parameter);
}

Первая конечная точка WCF web.config для второго WCF имеет что-то вроде этого:

...
<client>
  <endpoint address="https://192.168.1.100/MyService2/Service2.svc"
    binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IService2"
    contract="SecondService.IService" name="BasicHttpBinding_IService" />
</client>
...

С HTTPS сложно играть, говорю я.

Answer 1

Клиент, обращающийся к веб-сайту HTTPS, должен проверить две вещи о своем сертификате:

1. Он должен проверить, является ли сертификат подлинным, выданным доверенным органом (и действительным для этой цели).Это модель PKI, указанная в RFC 5280 .
2. . Они должны проверить, был ли выдан сертификат субъекту, с которым они пытаются связаться.Это проверка имени хоста, указанная в RFC 2818, раздел 3.1 (и позже в RFC 6125 ).

Проверка PKI выполняется путем настройкиклиент установил доверительные якоря (доверенные сертификаты CA).Если ваш сертификат выдан центром сертификации, которому ваша ОС доверяет по умолчанию, вам не нужно ничего делать.Если вам нужно было установить сертификат CA самостоятельно, убедитесь, что он также включен в хранилище machine (не только в хранилище пользователя), так как ваше приложение может работать как служба (а не под определеннымпользователь).

Проверка личности основана на идентификаторе, с которым вы пытаетесь связаться (имя хоста или IP-адрес) и идентичности, которой был выдан сертификат.Они должны совпадать.Правила содержатся в RFC 2818, раздел 3.1 , в частности:

Если присутствует расширение subjectAltName типа dNSName, это ДОЛЖНО использоваться в качестве идентификатора.В противном случае ДОЛЖНО использоваться (наиболее определенное) поле общего имени в поле «Тема» сертификата.Хотя использование общего имени является существующей практикой, оно устарело, и сертификационным органам рекомендуется вместо этого использовать dNSName.

[...]

В некоторых случаях указывается URIкак IP-адрес, а не имя хоста.В этом случае iPAddress subjectAltName должно присутствовать в сертификате и должно точно соответствовать IP-адресу в URI.

Ваш сервер может внутренне отвечать на несколько имен хостов и IP-адресов, например www.example.com, 192.168.1.100, localhost, 127.0.0.1.Ваш сертификат должен быть действительным для хоста / IP-адреса, с которым вы пытаетесь связаться.

Редко имеет смысл выдавать сертификат на localhost или 127.0.0.1, поэтому я сомневаюсь, что это то, что выесть, и нет смысла настраивать ваш клиент с https://localhost/... по этой причине.

Возможно иметь сертификат для 192.168.1.100, но он ДОЛЖЕН иметь IP (не DNS)Ввод альтернативного имени субъекта для этого IP-адреса.(Учитывая, что это частный адрес, вряд ли это так.)

Возможно, вам необходимо настроить службу для использования видимого имени хоста (того, для которого ваш сертификат, вероятно, был выпущен): www.example.com (или что бы то ни было).Могут возникнуть проблемы, если вы размещаете этот сервис за обратным NAT.