С момента обновления до .Net 4.6.1 я больше не могу обращаться к стороннему веб-сервису, но получить сообщение об ошибке «Не удалось установить безопасный канал для SSL/TLS с полномочиями ... ». Я могу обойти это несколькими способами, но я не считаю эти способы приемлемыми. а) Добавьте следующую строку кода:WCF - Не удалось установить безопасный канал для SSL/TLS с полномочиями после обновления до .Net 4.6.1
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls11 | System.Net.SecurityProtocolType.Tls;
Это гарантирует, что я не использую Tls1.2 и все работает, как и прежде с .Net 4.5.2
б) Добавьте следующую строку в мой конфигурационный файл
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
Это гарантирует, что я не использую Tls1.2 и все работает, как и прежде с .Net 4.5.2
Я предпочел бы быть в состоянии использовать Tls1.2, чем отключить его для всех ок lls из моего приложения, мое приложение общается со многими сторонними службами, и я не хочу ограничивать всю связь из-за проблемы с одним.
Использование WireShark для диагностики проблемы подсвечило, что сертификат клиента не отправлен, что явно приводит к этой ошибке.
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="def">
<security mode="Transport">
<transport clientCredentialType="Certificate"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="https://abc" binding="basicHttpBinding" bindingConfiguration="def" contract="ghi" name="jkl"/>
</client>
ClientCertificate устанавливается в коде
Я прочитал много статей о StackOverflow, наиболее похожий/полезный приведена ниже: How to force WCF client to send client certificate?
I проверили:
- Доступ к сертификату клиента (секретный ключ) доступен
- сертификат сервера является надежным и действующим
- Сертификат клиента соответствует одному из спецификации сервера посланной
Старинных моя привязки к обычаю не обязательная для указания requireClientCertificate - никакого эффекта
<endpoint address="https://abc" binding="customBinding" bindingConfiguration="def" contract="ghi" name="jkl"/>
Может кто-нибудь мне точку к чему-либо еще, что я могу проверить или помочь мне понять, почему мой сертификат не будет отправлен?
Update 2 июня я могу скачать WSDL успешно используя свой сертификат клиента для аутентификации в Chrome, но не в любом Internet Explorer, ни краю!
Я считаю, что Chrome не использует SChannel (как Edge и IE do) для TLS, но это собственная реализация SSL/TLS.
Хотя я не уверен, что на данный момент я считаю, что проблема заключается в том, что сервер указывает алгоритм подписи для сертификата клиента, который не соответствует алгоритму подписи клиентов. Я действительно не знаю достаточно о том, как работает TLS 1.2, но из чтения spec tools.ietf.org/html/rfc5246#section-7.4.4 кажется возможным.
запрос См сертификат в Wireshark след - i.stack.imgur.com/BwmUM.png и сертификат детали - i.stack.imgur.com/pbKEF.png
Любые tls1.2 эксперты там?
Осталось одна вещь. Укажите сертификат клиента в режиме конечной точки в конфигурации, такой как [здесь] (https://msdn.microsoft.com/en-us/library/ms731323 (v = vs.110) .aspx). – pepo
Благодарим вас за предложение. Я только что попробовал это, но, к сожалению, это не имеет никакого значения. Он по-прежнему работает, если я отключу Tls1.2, поэтому я знаю, что мои изменения в конфигурации верны. –
Вы уверены, что правильно задали права на закрытый ключ? Попробуйте [this] (http://stackoverflow.com/a/32605764/3245057). Или попробуйте использовать закрытый ключ в коде, т.е. в SignedCms. Существует также журнал событий CAPI (журналы приложений и сервисов/microsoft/capi), которые будут регистрировать, то есть проблемы с проверкой сертификатов, но по умолчанию отключены, поэтому включите его. – pepo