| ||||
| ||||
| Здравствуйте! Есть Web-сервис на IIS работа с которым происходит по https. К узлу возможен анонимный доступ, при этом используется административный акаунт. На сервер стоит Server Authentication сертификат ГОСТ Р 34.11/34.10-2001. У клиента (в данном случае все на одной машине) соответствующий клиентский сертификат в Personal. При обращение из браузера вызов сервиса происходит нормально. Делаю клиентское приложение на VS 2005 (C#). Пытаюсь добавить Web Reference на сервис: появляется список Web-методов (как в браузере), но при этом выводится "The request was aborted: Could not create SSL/TLS secure channel.", возможности добавить web-reference нет. Как это побороть? | ||||
| Ответы: | ||||
| ||||
| Ничем не можем подсказать, т.к. в КРИПТО-ПРО криптопровайдер с поддержкой C# еще в стадии разработки :-( | ||||
| ||||
| Юрий, собстенно к С# относится лишь косвенно. Тут, насколько я понимаю проблема в создании SSL/TLS соединения... На вашем форуме уже обсуждалась подобная ситуация: http://www.cryptopro.ru/cryptopro/forum/view.asp?q=1926 Чем тогда завершилась e-mail переписка с саппортом, может всетаки нашли решение? | ||||
| ||||
| а мы не отделяем CSP от TLS. Пока у нас в реализации под .NET SSL только частично работает, а вот сертификаты "разбирать" он не умеет. Пока не сможем ответить. А про то обсуждение на форуме, ссылку которого переслали, закончилось тем, что стали делать криптопровайер под .NET :-) | ||||
| ||||
| Извините за назойливость, но мне необходимо найти какое то решение данной ситуации. Мне не понятно как эта ошибка вообще связана с .NET (вернее с отсутвием его поддержки вашим TLS). Может я и не прав, но разьве шифрование не будет происходить на гораздо "более низких" уровнях чем среда .NET framework, которая в данном случе лишь формирует SOAP-пакет для вызова метода сервиса? Предложите пожалуйста какие нибудь вариатны взаимодействия .NET клиента и Web-службы по https с шифрованием по ГОСТ. | ||||
| ||||
| А какой криптопровайдер Вы используете? Какая версия и номер сборки? | ||||
| ||||
| КриптоПРО CSP 2.0 билд 2049 + ваш TLS server 2.0. | ||||
| ||||
| возможно имеет значение: оба evaluation осталось 29 дней. | ||||
| ||||
| Попробуйте поставить версию 2.0 посвежее | ||||
| ||||
| Хорошо, попробую. Но значит все таки существует возможность осуществить взаимодействие м/у .NET клиентом и Web-сервисом по http через ваш TLS? | ||||
| ||||
| т.е. по https | ||||
| ||||
| Проставил CSP/TLS двушку, но билд поновее. Результат тот же ( Ошибку при добавлении Web Reference в проект .NET клиента удалось перехитрить временным отключением https - для http референс создается нормально, прокси-класс генерируется, методы сервиса вызываются. После этого снова включаю https на сервере, клиентское приложение вызывает любой метод web service и вылетает исключение. На этот раз уже "The underlying connection was closed: An unexpected error occurred on a receive." InnerException при этом: "System.NotSupportedException: The certificate key algorithm is not supported. at System.Security.Cryptography.X509Certificates.X509Certificate2.get_PrivateKey() at System.Net.Security.SecureChannel.EnsurePrivateKey(X509Certificate certificate) at System.Net.Security.SecureChannel.AcquireClientCredentials(Byte[]& thumbPrint). . . " Очевидно вы были правы, .NET не дружит с вашим TLS. Но мне опять же не понятно почему он на алгоритм сертификата ругается - шифрование передаваемых данных ведь вне .net будет проходить? Может это мои заблуждения, но проясните пожалуйста. Вообще хоть что-нибудь посоветуйте по сабжу, может все же каким шаманством можно заставить .net клиентское приложение работать с web-сервисом по https с использованием ваших крипто-средств? | ||||
| ||||
| Установление TLS сессии осуществляется заданием сертификата. Выборка секретного ключа по этому сертификату осуществляется непосредственно в .Net. Вот эта связка между сертификатом и секретным ключем и не работает на ГОСТ алгоритмах. Шифрование данных и аудентификация действительно работают на ГОСТ алгоритмах в .Net (то что пока удалось проверить). Шаманство :) в виде провайдера для .Net в стадии разработки. Других, более или менее приемлимых решений пока нет. | ||||
| ||||
| Александр, а что вы имели ввиду под: "Шифрование данных и аудентификация действительно работают на ГОСТ алгоритмах в .Net (то что пока удалось проверить)."? Недавно сталкивался с этим, мне пришлось разработать библиотечку на C# с кучей pinvoke, т.к. использовать КриптоПро CSP на .NET для этих целей как раз было невозможно. Или вы о текущем состоянии разрабатываемого .NET-провайдера? | ||||
Максим