Аутентификация по выбранному сертификату не пройдена

Аутентификация по выбранному сертификату не пройдена

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

Инфраструктура, используемая для поддержки сертификатов в организации, на­зывается инфраструктурой открытого ключа (Public Key Infrastructure, PKI). [22]

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

Важно, что в отличие от алгоритмов с симметричным ключом, где для расшифро­вания и шифрования используется один и тот же ключ, в алгоритмах с открытым/ секретным ключом используются два ключа: один для шифрования, а другой — для расшифровки. Если шифрование осуществляется с использованием открытого клю­ча, то расшифровать зашифрованный текст можно только с помощью соответствую­щего секретного ключа. Если шифрование осуществляется на секретном ключе, то расшифровать текст можно только с помощью соответствующего открытого ключа.

При использовании сертификатов для аутентификации секретный ключ при­меняется для шифрования или цифровой подписи некоторого запроса или «вопро­са». Соответствующий открытый ключ (доступный в сертификате) может исполь­зоваться сервером или центральным сервером аутентификации для расшифровки запроса. Если результат соответствует ожидаемому, подлинность считается дока­занной. Так как с помощью соответствующего открытого ключа можно успешно расшифровать вопрос, а секретным ключом, посредством которого был зашифро­ван вопрос, обладает только объект-сущность, сообщение должно исходить имен­но от этого объекта-сущности. Ниже приведены шаги описанного процесса аутен­тификации.

1. Клиент подает запрос аутентификации.

2. Сервер создаст вопрос.

3. Рабочая станция использует свой секретный ключ для шифрования вопроса.

4. Ответ возвращается серверу.

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

6. Если наблюдается совпадение, клиент успешно проходит аутентификацию. Данная концепция представлена на рис. 4.2.

Рис. 4.2. Аутентификация с использованием открытого и секретного ключей

Здесь полезно понять, что исходный набор ключей генерируется клиентом и в центр сертификации передается только открытый ключ. СА генерирует сертифи­кат и подписывает его с помощью секретного ключа, после чего возвращает копию сертификата пользователю и его базе данных. [23]

SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, обеспечивающий безопасную передачу данных по сети Интернет. При его использовании создаётся защищённое соединение между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

Дан­ная система может использоваться в электронной коммерции или в любой другой сфере, где требуется машинная аутентификация или необходимы безопасные со­единения. Transport Layer Security (TLS) — это версия SSL, стандартизированная для использования в Интернете (RFC 2246). Несмотря на то, что TLS и SSL выпол­няют одну и ту же функцию, они не являются совместимыми: сервер, использую­щий SSL, не может установить защищенный сеанс с клиентом, который использу­ет только TLS. Необходимо обеспечить совместимость приложений с SSL или TLS, прежде чем использовать одну из этих двух систем.

Хотя наиболее общая реализация SSL обеспечивает безопасное соедине­ние и аутентификацию сервера, может быть также реализована аутентификация кли­ента. Клиенты должны обладать для этой цели своими собственными сертификатами, веб-сервер должен быть настроен на требование аутентификации от клиентов.

В наиболее распространенном варианте использования SSL организация полу­чает SSL-сертификат сервера из открытого центра сертификации, такого как VeriSign, и устанавливает его на свой Веб-сервер.

Процесс аутентификации состоит из следующих этапов.

1. Пользователь вводит URL сервера в браузере.

2. Запрос клиента на веб-страницу передается на сервер.

3. Сервер получает запрос и отправляет свой сертификат сервера клиенту.

4. Браузер клиента проверяет свое хранилище сертификатов на наличие сертифи­ката от центра сертификации, выпустившего сертификат сервера.

5. Если обнаруживается сертификат СА, браузер подтверждает сертификат посред­ством проверки подписи на сертификате сервера с использованием открытого ключа, имеющегося в сертификате СА.

6. Если проверка завершается успешно, браузер принимает сертификат сервера и считает его действительным.

7. Генерируется симметричный ключ шифрования, происходит его шифрование клиентом с использованием открытого ключа сервера.

8. Зашифрованный ключ возвращается серверу.

9. Сервер расшифровывает ключ с помощью собственного секретного ключа сервера. Для компьютера теперь общий ключ шифрования, который может использоваться для обеспечения безопасности соединений между ними.[24]

Существует множество потенциальных проблем, связанных с данной системой.

· Если веб-сервер не настроен соответствующим образом на требование исполь­зования SSL, сервер не аутентифицируется относительно клиента, и может быть установлено обычное незащищенное соединение. Безопасность зависит от того, укажет ли пользователь в строке URL браузера протокол https:/ вместо http:/.

Читайте также:  Embarcadero rad studio android

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

· Процесс получения сертификата СА в хранилище браузера не является четко контролируемым. В прошлом данное обстоятельство могло потребовать уплаты денежных средств или зависело от ваших связей. Теперь же Microsoft требует, чтобы сертификаты, устанавливаемые все браузеры, были выпущены центрами сертификации, прошедшими соответствующий аудит.

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

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

Стойкость шифра SSL-сеанса прямо пропорциональна числу разрядов в ключе сеанса. Иначе говоря, считается, что ключи с большим числом разрядов безопаснее — их труднее взломать.

Для SSL-сеансов обычно применяются 40- и 128-разрядный уровни шифрования. Первый вариант подходит для большинства ситуаций, включая электронную коммерцию, а второй — обеспечивает дополнительную защиту важных личных и финансовых сведений клиента. В версиях Microsoft Windows для США реализовано 128-, а в экспортных версиях — 40-разрядное шифрование. Чтобы обновить сервер для 128-разрядного шифрования, необходимо установить специальный пакет обновления, распространяемый Microsoft.

Необходимо различать уровень шифрования SSL-сеансов (стойкость ключа сеанса, выраженная в разрядах) и уровень шифрования SSL-сертификатов (стойкость открытого и закрытого ключей сертификата, выраженная в разрядах). Обычно длина ключа шифрования, открытого или закрытого, составляет 512 или 1024 разряда. Внутренние американские и экспортные версии большинства приложений и ОС поддерживают ключи шифрования длиной 512 разрядов. Ключи длиной 1 024 и более разрядов во многих случаях не поддерживаются.

Когда пользователь пытается установить SSL-соединение с Web-сервером, клиентский браузер и сервер на основе своих ключей шифрования определяют максимально возможный уровень шифрования. Если длина ключей шифрования 512 разрядов, используется 40-разрядное, если 1 024 — 128-разрядное шифрование. Также доступны другие длины ключей и уровни шифрования.

Дата добавления: 2016-11-12 ; просмотров: 1994 | Нарушение авторских прав

Пройдите аутентификацию в СБИС с помощью электронной подписи сотрудника, или используйте менее безопасный способ — по логину и паролю.

При успешной аутентификации пользователю возвращается строка с идентификатором сессии. Ее нужно передавать на сервер при выполнении каждой команды.

Для входа по сертификату ЭП используется свой набор команд, а по логину и паролю — свой.

  1. Выполните команду «СБИС.СписокСертификатовДляАутентификации» чтобы проверить сертификаты, которые допускают аутентификацию.
  2. Выберите сертификат. С помощью команды «СБИС.АутентифицироватьПоСертификату» войдите в кабинет. В ответе вернется идентификатор сессии, который зашифрован в адрес выбранного сертификата.
  3. Расшифруйте идентификатор сессии с помощью любого сертифицированного СКЗИ. Зашифрованная сессия передается в виде структуры «ContentInfo» со структурой «EnvelopedData» в качестве содержимого. Идентификатор сессии шифруется в адрес открытого ключа сертификата, с помощью которого происходит аутентификация. Пример можно посмотреть на сайте КриптоПро.
  4. Работайте в личном кабинете, выполняя другие команды API.
  1. Выполните команду «СБИС.Аутентифицировать». В ней передайте логин/пароль от личного кабинета online.sbis.ru. В ответе вернется идентификатор сессии.
  2. Работайте в личном кабинете, выполняя другие команды API.

При выполнении HTTP-запросов указывайте идентификатор сессии как значение HTTP заголовка «X-SBISSessionID». Исключение — команды «СБИС.Аутентифицировать», «СБИС.АутентифицироватьПоСертификату» и «СБИС.СписокСертификатовДляАутентификации».

Пример заголовка HTTP-запроса с указанием идентификатора сессии

Если запросы к серверу отсутствуют, идентификатор сессии принудительно аннулируется через 24 часа. Максимальное время «жизни» идентификатора — 7 дней с момента аутентификации.

Чтобы завершить сессию и прекратить сеанс обмен, вызовите функцию «СБИС.Выход».

Процедуру аутентификации нужно выполнить один раз за сеанс работы. Полученный идентификатор можно использовать многократно для выполнения других команд в этом сеансе работы. При получении в ответ на HTTP POST/GET-запрос кода состояния 401 (Unauthorized) — еще раз выполните аутентификацию и повторите запрос.

Обратите внимание: если метод аутентификации выполняется чаще 300 раз в минуту, система заблокирует доступ по IP-адресу на 20 минут.

В этой статье описано как создать WCF-сервис, который реализует два вида аутентификации клиентов: по логину-паролю и по сертификату при использовании Message Security. Причём оба вида реализуют собственную логику аутентификации.

Читайте также:  Mini pci e wifi ac 5 ghz

В данном примере в качестве сервисного сертификата используется сертификат ГОСТ, хотя примерно аналогичные настройки будут применяться с любыми типами сертификатов. Для корректной работы ГОСТ-сертификатов необходимо установить пакеты CryptoPro CSP и КриптоПРО .NET.

1. Аутентификация по логину-паролю

Процесс условно можно разделить на 3 этапа:

  • создание и настройка сервиса;
  • создание класса, реализующего собственную логику аутентификации;
  • создание приложения-клиента.

Создание и настройка сервиса

Создайте в Visual Studio проект WCF-сервиса. Для данного примера я использовал тип проекта WCF Service Application. При этом Visual Studio автоматически создаст сервис Service1.svc с тестовыми методами. Его мы и будем использовать в качестве примера.

Далее необходимо настроить конфигурацию сервиса. Это можно сделать вручную или с помощью утилиты WCF Service Configuration Editor, которая встроена в Visual Studio и позволяет настраивать сервис в графическом режиме. Для этого кликните правой кнопкой мыши на файле Web.config и выберите пункт Edit WCF Configuration. Откроется окно настройки параметров сервиса как показано на рис. 1. Если у вас отсутствует данный пункт, то перейдите на вкладку Tools и нажмите WCF Service Configuration Editor. После этого пункт меню должен появиться.

Рис. 1. Окно настройки параметров WCF-сервиса

Сначала создадим привязку для сервиса, поддерживающую аутентификацию по логину-паролю. Для этого кликните на узел Bindings в левой части окна, а затем по ссылке New Binding Configuration… в правой части. В раскрывшемся списке выберите тип привязки wsHttpBinding и нажмите OK. В поле Name введите наименование привязки, например, UserNameBinding. Остальные настройки можно оставить по умолчанию, подробнее они описаны здесь. Далее перейдите на вкладку Security и настройте параметры следующим образом:

  • Mode — Message;
  • MessageClientCredentialType — UserName;
  • TransportClientCredentialType — None.

Также, если используется сертификат с алгоритмом ГОСТ, то необходимо выставить параметр NegotiateServiceCredential в False. Этот параметр указывает, будет ли информация о сертификате сервиса автоматически передаваться на клиент или в клиенте необходимо вручную указывать сертификат сервиса. С ГОСТ-сертификатами это не работает, поэтому выставляем параметр в False. Остальные параметры оставьте по умолчанию.

Далее создадим для сервиса поведение (Behavior). Для этого разверните узел Advanced, далее Service Behaviors и в правой части окна нажмите New Service Behavior Configuration. В поле Name введите наименование, например AuthenticationBehavior. Далее с помощью кнопки Add… добавьте элементы как описано ниже.

  • ServiceMetadata. Выставите параметр HttpGetEnabled в True, чтобы wsdl был доступен на странице сервиса.
  • ServiceDebug. Выставите параметр IncludeExceptionDetailsInFaults в True. Это удобно для целей отладки, так как все исключения сервиса будут пробрасываться на клиент. При развёртывании на продуктивном сервере эту настройку лучше отключать и пробрасывать на клиент только те исключения, которые считаете нужным.
  • ServiceCredentials. Так как будет использоваться собственная логика аутентификации, то параметр UserNamePasswordVal >

Рис. 2. Настройка сертификата сервиса

Далее необходимо связать сервис с созданными привязкой и поведением. Для этого кликните по узлу Services и в правой части окна по ссылке Create New Service… В открывшемся окне в поле Service type введите полное имя сервиса. Сервис за нас уже создала Visual Studio, поэтому сошлёмся на него, в данном случае это будет: ServiceWithAuthentication.Service1. Если появится окно с сообщением, что тип сервиса может быть не корректен, не обращайте внимания и нажмите кнопку Да. Далее необходимо указать контракт сервиса, в данном случае это будет ServiceWithAuthentication.IService1. В следующем окне будет предложено выбрать привязку. Отметьте Existing binding configuration и выберите из выпадающего списка созданную привязку (UserNameBinding для данного примера). Затем укажите адрес конечной точки, например, ByUserName и нажмите Next, затем Finish. Сервис будет создан.

Кликните по сервису и в правой части окна в параметре BehaviorConfiguration выберите созданное ранее поведение AuthenticationBehavior. Далее раскройте узел Endpoints сервиса, кликните по созданному Endpoint и назначьте ему имя, например, UserNameEndpoint. Остальные параметры оставьте по умолчанию.

На этом конфигурация сервиса закончена, нажмите CTRL+S для сохранения и закройте окно. Файл Web.config будет изменён соответствующим образом.

Создание класса, реализующего собственную логику аутентификации

Далее необходимо создать класс, который был указан при настройке и который будет реализовывать логику аутентификации пользователей. В данном случае это класс, который должен находится в той же сборке в пространстве имён ServiceWithAuthentication и иметь название CustomUserNameValidator. Для того чтобы этот класс мог осуществлять валидацию, его необходимо унаследовать от класса UserNamePasswordValidator, который находится в сборке System.IdentityModel, и переопределить метод Validate. В данном примере метод просто будет проверять одного конкретного пользователя и отвергать всех остальных. Ниже приведён код:

Для проверки конфигурации сервиса, кликните правой кнопкой мыши на файле Service1.svc и нажмите View in Browser. При этом, если всё было сделано правильно, должна открыться страница сервиса как показано на рис. 3.

Читайте также:  Hebe m1 rgb драйвер

Рис. 3. Страница сервиса

По умолчанию Visual Studio использует IIS Express. Если при просмотре страницы сервиса возникает ошибка «Набор ключей не существует», то либо ваш сертификат не имеет закрытого ключа, либо учётная запись, от которой запущен IIS Express не имеет прав доступа к закрытому ключу для этого сертификата. Для сертификатов ГОСТ, если закрытый ключ хранится в реестре, права доступа можно настроить в ветке реестра HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCrypto ProSettingsKeys или HKEY_LOCAL_MACHINESOFTWARECrypto ProSettingsKeys для 32-разрядной версии Windows. Кликните правой кнопкой мыши по необходимому ключу и выберите пункт Разрешения… Далее необходимо дать права учётной записи, от которой запускается IIS Express. Также, если вы разворачиваете свой сервис, например, на локальном IIS, то аналогично нужно дать права доступа к закрытому ключу учётной записи, от которой запущен пул приложений, на котором развёрнут ваш веб-сервис.

Создание приложения-клиента

Теперь для проверки аутентификации создадим простое консольное приложение-клиент. Для этого добавьте в решение новый консольный проект и привяжите к нему созданный сервис через меню Add Service Reference…. В открывшемся окне введите адрес созданного сервиса (его можно скопировать из адресной строки браузера) и нажмите Go. Название сервиса должно появиться в списке Services. Далее введите пространство имён, например, ServiceWithAuhenticationClient и нажмите ОК. При этом добавится ссылка на сервис и файл App.config изменится соответствующим образом.

Далее откройте файл Program.cs и отредактируйте его следующим образом:

Запустив этот код, вы должны увидеть в консоли строку «You entered: 25». Это означает что сервис и аутентификация отработали верно. Попробуйте изменить логин или пароль и вы получите MessageSecurityException, что будет означать, что пользователь не прошёл аутентификацию.

2. Аутентификация по сертификату

Теперь рассмотрим аутентификацию по сертификату. Для этого добавим к сервису ещё одну конечную точку.

Кликните правой кнопкой мыши на файле Web.config сервиса и выберите пункт меню Edit WCF Configuration. Для начала необходимо немного изменить созданное ранее поведение. Перейдите к AuthentiactionBehavior (Advanced —> Service Behaviors —> AuthentiactionBehavior), раскройте его узел serviceCredentials и далее узел clientCredentials. Для собственной логики проверки сертификата клиента выставите свойство CertificateValidationMode в Custom, а в поле CustomCertificateValidatorType введите полное наименование класса (включая сборку), который будет осуществлять проверку сертификата. В данном примере это будет ServiceWithAuthentication.CustomCertificateValidator, ServiceWithAuthentication.

Далее раскройте узел Bindings и в правой части окна кликните по ссылке New Binding Configuration…. Во всплывающем окне выберите wsHttpBinding и нажмите ОК. Будет создана новая привязка. В поле Name укажите наименование, например, CertificateBinding и на вкладке Security выставите параметры следующим образом:

  • Mode — Message;
  • MessageClientCredentialType — Certificate;
  • NegotiateServiceCredential — False
  • TransportClientCredentialType — None.

Далее перейдите к узлу Services, раскройте созданный ранее сервис, кликните правой кнопкой мыши по узлу Endpoints и нажмите New Service Endpoint. Заполните поля следующим образом:

  • Name — CertificateEndpoint;
  • Address — ByCertificate;
  • Binding — wsHttpBinding;
  • BindingConfiguration– CertificateBinding;
  • Contract — ServiceWithAuthentication.IService1.

Сохраните изменения и закройте окно.

Далее необходимо создать сам класс, который будет заниматься проверкой клиентского сертификата. В данном случае это будет CustomCertificateValidator. Класс необходимо унаследовать от X509CertificateValidator и переопределить метод Validate. Для примера будем принимать только сертификат с определённым отпечатком и отсеивать все остальные. Код будет примерно такой:

Кликните правой кнопкой по файлу Service1.svc и нажмите View in Browser. Если всё сделано правильно, то как и прежде должна открыться страница сервиса.

Теперь перейдите к клиенту, кликните правой кнопкой мыши по сервису и нажмите Update Service Reference, чтобы обновить ссылку на сервис.

Далее откройте файл Program.cs и отредактируйте его следующим образом (измените параметры поиска сертификата на свои):

Запустите клиент. Если всё сделано правильно, вы увидите в консоли две строки. При этом в первом случае отработала аутентификация по логину-паролю, а во втором по сертификату.

3. Дополнительные настройки

Указание сертификата сервиса на клиенте

По умолчанию, когда вы добавляете ссылку на сервис через меню Add Service Reference…, в файл App.config клиента добавляется сертификат сервиса в кодированном виде как показано ниже:

Это не всегда удобно, например, при изменении сертификата сервиса. Есть другой способ указания сертификата сервиса на клиенте. Откройте файл App.config клиента, удалите элемент , а вместо него добавьте элемент с параметрами для поиска сертификата сервиса (сертификат сервиса с открытым ключом должен быть установлен в хранилище). Файл App.config после этого должен выглядеть примерно так:

Попробуйте теперь вновь запустить клиентское приложение, если параметры поиска сертификата заданы верно, то всё должно сработать как и раньше.

Ссылка на основную публикацию
Adblock detector