Принципы доверия PKI | Windows IT Pro/RE | Издательство «Открытые системы»

Что такое ssl-сертификат?

Многие наверняка слышали про

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

Pki и его стандарты

Отдельно следует упомянуть всякого рода национальные стандарты и нормативные требования, к примеру, в РФ это ФЗ-63, приказы ФСБ России № 795 и 796 и прочие производные от них. Следует учитывать, что многообразие стандартов RFC и описанных в них функций PKI породило несколько организационно-нормативных подходов к построению инфраструктуры PKI в отдельно взятой стране. Для иллюстрации приведу список сервисов PKI, которые описаны в стандарте X.842:

Результатом этого многообразия стало безобразие в национальных стандартах отдельных стран. Как результат – набор проблем по совместимости между различными решениями в отдельных странах и, очень часто, невозможность построения цепочки доверия между двумя пользователями технологии PKI в разных странах.

Где купить ssl-сертификат?

Приобретают сертификаты обычно не напрямую у удостоверяющего центра, а через партнёров. В России продажей сертификатов известных удостоверяющих центров (УЦ), таких как Comodo, Geotrust, GoDaddy, GlobalSign, Symantec и прочих, занимается множество компаний.

Гибкость управления доверием в pki

Принципы доверия являются фундаментальной концепцией инфраструктуры PKI. Расширенные возможности доверительных отношений, реализованные в Windows 2003 PKI, с одной стороны, делают данную инфраструктуру более мощной и гибкой, а с другой — вносят дополнительную сложность в процессы построения и администрирования доверительных отношений.

Тем не менее на данный момент не существует какого-либо другого защищенного протокола или технологии с аналогичными возможностями работы с доверительными отношениями. В следующей статье будут рассмотрены методики управления доверительными отношениями на стороне пользователя инфраструктуры Windows PKI.

Другие методы устранения ошибки при проверке отношений доверия

Если вы используете КриптоПро версии 4, но ошибка все равно появляется, попытайтесь просто переустановить программу. Во многих случаях эти действия помогали пользователям. Еще возможно, что ваш жесткий диск переполнен ненужными файлами и их нужно удалить. В этом нам помогут стандартные утилиты Windows.

1. Откройте проводник (WIN E) и выберите один из локальных дисков ПКМ;
2. Нажмите на пункт «Свойства»;
3. Под изображением занятого пространства диска найдите и нажмите кнопку «Очистить»;
4. Затем появится окно, где нужно выбрать файлы, которые будут удалены;
5. Можете выбрать все пункты и нажать «Ок».

Эту инструкцию нужно выполнить для всех локальных дисков на вашем компьютере. Далее выполните следующую инструкцию для проверки файлов Windows

1. Откройте меню «Пуск»;
2. Введите в строке поиска «Командная строка»;
3. Эту строку выберите ПКМ и укажите мышью пункт «От имени администратора»;
4. Введите в этом окне команду для запуска сканирования «sfc /scannow»;
5. Нажмите клавишу ENTER.

Дождитесь завершения этого процесса. Если утилита найдет неполадки в файловой системе вы увидите это в итоговом сообщении. Закройте все окна и попытайтесь запустить программу КриптоПро, чтобы убедиться, что ошибка «При проверке отношений доверия произошла системная ошибка» уже устранена. Для особых случаев есть номер технической поддержки ПО — 8 800 555 02 75.

Защита для бизнеса и клиентов

Каким же сайтам нужна защита SSL? Да практически всем. Особенно тем, которые в наибольшей степени подвержены атакам: ресурсам финансовых учреждений, крупных брендов, сайтам, работающим с персональными данными и платёжной информацией.

Как выбрать ssl-сертификат – ru-center

Настройка регулируемых доверительных отношений

Для установки параметров регулируемых доверительных отношений в инфраструктуре Windows 2003 PKI имеется три средства: конфигурационный файл capolicy.inf, конфигурационный файл policy.inf и оснастка Certificate Templates консоли MMC.

В процессе установки центра CA с помощью файла capolicy.inf можно устанавливать параметры регулируемых доверительных отношений для сертификатов CA инфраструктуры PKI, а также изменять другие параметры настройки центра CA. Например, можно задать местонахождение узлов распространения списков сертификатов, подлежащих аннулированию (Certificate Revocation List (CRL)

Distribution Points) и узлов Authority Information Access (AIA). Проверка содержимого файла capolicy.inf на наличие параметров регулируемых доверительных отношений производится при установке центра CA, а также при каждом обновлении его сертификата. Данный файл следует хранить в каталоге %systemroot% того компьютера, на который устанавливается центр CA, причем имя этого файла изменять нельзя. В файле capolicy.inf можно задавать только параметры ограничения типа basic и issuance policy.

С помощью конфигурационного файла policy.inf можно определять те параметры ограничения степени доверия, которые записываются в файл запросов сертификатов центра CA (утилита Certreq использует данный файл в качестве параметра). Файл policy.inf предоставляет наиболее полные возможности конфигурирования отношений с регулируемой степенью доверия; здесь, в отличие от файла capolicy.inf, могут настраиваться параметры регулирования степени доверия всех категорий. Отметим также, что, в противоположность файлу capolicy.inf, имя файла policy.inf может быть изменено.

Через оснастку Certificate Templates могут создаваться, редактироваться и удаляться шаблоны сертификатов. Шаблоны сертификатов определяют свойства сертификатов (в том числе относящиеся к регулируемым доверительным отношениям), выдаваемых центрами сертификации Windows CA.

Шаблоны сертификатов версии 2 предусматривают редактирование, шаблоны версии 1 не редактируются. Следует отметить, что редактирование шаблонов сертификатов предоставляет менее полные возможности настройки регулируемых доверительных отношений, чем работа с файлом policy.inf: с помощью шаблонов сертификатов могут настраиваться только те параметры ограничения степени доверия, которые относятся к категориям basic, application policy и issuance policy.

Причина появления ошибки в криптопро

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

Нередко само программное обеспечение устанавливается в систему с ошибками. Причин для этого предостаточно:

• Неполадки в системном реестре Windows;
• Жесткий диск заполнен мусором, которые не дают правильно работать другому ПО;
• Наличие вирусов в системе и так далее.

Регулируемые доверительные отношения

В рамках инфраструктуры PKI среды Windows 2003 реализована поддержка регулируемых доверительных отношений (в Microsoft такой тип отношений называют «ограниченное подчинение»). С помощью этой технологии администраторы центров CA могут управлять доверительными отношениями между вышестоящим центром CA и его подчиненными центрами (для иерархической модели) или воздействовать на отношения между центрами-точками (для сетевой модели).

Регулирование степени доверия может осуществляться с помощью внедрения специальных расширений X.509 в сертификат подчиненного центра CA или в кросс-сертификат центра CA, который является точкой сетевой модели. В Windows 2003 PKI поддерживаются следующие типы расширений сертификатов для регулирования степени доверия: базовые, по именам, политика выдачи и политика приложений.

Базовые ограничения. Эти параметры регулирования основываются на расширениях сертификата X.509, называемых Basic Constraints и содержащих поле с именем pathLenConstraint (или path-length constraint). Эти поля можно использовать только в том случае, если в поле СА расширения X.

509 Basic Constraint сертификата установлено значение true, что имеет место только в сертификатах центров CA. С помощью параметра path-length constraint задается максимально допустимое количество сертификатов, выпущенных независимыми центрами CA, которые могут следовать в пути сертификации за данным сертификатом.

На рис. 3 показано два примера иерархических отношений доверия: Config 1 и Config 2. В примере Config 1 установка параметра базового ограничения в сертификате подчиненного центра CA уровня 1 ограничивает длину пути сертификата до 1. В результате центр CA, расположенный на уровень ниже, сможет выдавать пользовательские сертификаты, но он лишен возможности выдавать сертификаты центрам CA.

В примере Config 2 аналогичный результат достигается путем добавления параметра длины пути, равного 2, в сертификат корневого центра CA. В этом случае программное обеспечение PKI автоматически добавит параметр длины пути, равный 1, во все сертификаты подчиненных CA, которые были выданы корневым центром.

Ограничения по именам. Расширение сертификата типа ограничения по именам может устанавливаться только для сертификатов центров CA. Данная возможность позволяет ограничить количество субъектов, которым могут выдавать сертификаты подчиненные центры CA или СA, работающие по кросс-сертификатам.

С помощью расширений типа ограничения по именам можно задавать то пространство имен, в пределах которого должны находиться имена и дублирующие имена или IP-адреса субъектов, посылающих запросы на сертификацию. Параметры ограничения доверия данного типа размещаются в расширении Name Constraints сертификата центра CA. В табл.

Решение ошибки с сертификатом

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

Все важные данные с предыдущей версии необходимо скопировать на съемный носитель или в отдельную папку Windows.

1. Откройте меню «Пуск» и нажмите раздел «Панель управления» Windows;
2. На следующем шаге нажмите «Удаление программ». Это можно сделать и быстрее — нажмите 2 клавиши WIN R и введите в строке команду «control», затем выберите «Удаление программ»;
3. В списке найдите старую версию КриптоПро и выделите её мышью. Затем нажмите вверху кнопку «Удалить»;

   

4. Подтвердите удаление.

Сложности

В этот момент начинаются сложности. Сложность первая. Случается, что сертификат пользователя заполнен неправильно, не соответствует требованиям законодательства, в этом случае он должен быть перевыпущен. Как правило, подобную проблему порождает работник УЦ, который неправильно его заполнил, а проблемы получает пользователь, когда не может его нормально использовать.

Сложность вторая. Законодательство говорит о том, что УЦ – это юридическое лицо, и ГУЦ должен подписать сертификат этого УЦ. Ситуация, когда у одного юридического лица несколько комплексов УЦ и несколько сертификатов этих УЦ, толком в законах не прописана.

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

Сложность третья. Если сертификат отозвали, УЦ обязан его добавить в список отозванных сертификатов (СОС), обязанность эта прописывается в RFC, если они приняты как стандарт в стране, или в регламенте ГУЦ, к которому обязаны присоединиться все аккредитованные УЦ.

В случае когда СОС (CRL) большой, УЦ для удобства пользователей выпускает дельта СОС (deltaCRL) с изменениями за короткий период. В регламенте ГУЦ прописана периодичность обновления 12 часов или по факту отзыва сертификатов. В реальности различные УЦ свои СОС публикуют как хотят, существуют некоторые УЦ, которые обновляют их 1 раз в несколько месяцев.

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

Сложность четвертая, связная. Построение цепочки доверия в PKI так или иначе требует наличия связи с УЦ и ГУЦ и работу в онлайне. Работа в офлайне не предусмотрена. Существует ряд мест и приложений, где работа с подписями и сертификатами в офлайне очень бы пригодилась.

Сложность пятая, техническая. Иногда в программно-аппаратных комплексах УЦ все-таки находятся ошибки в логике и реализации, это также может влиять на построение цепочки доверия.

И только если на пути пользователя эти проблемы не встретились, цепочка доверия должна построится. В случае использования OCSP/TSP-служб проблемы тоже существуют, но это тема для отдельной статьи.

Установка личного сертификата

Далее нужно установить сертификат в утилите КриптоПро, чтобы устранить сбой сертификата — при проверке отношений доверия произошел сбой. Запустите ПО от имени администратора. Делать это лучше всего из меню «Пуск».

1. В окне программы выберите вкладку «Сервис»;
2. Выберите пункт «Просмотреть сертификаты…»;
3. Далее в окне «Сертификаты закрытого ключа» нажмите небольшую кнопку «Обзор» и выберите контейнер;
4. Нажмите кнопку «Далее». Если вы увидите сообщение, в котором говорится об отсутствии набора ключей, возьмите его с ключевого носителя;
5. Нажмите кнопку ниже «Установить»;
6. Затем в процессе нужно выбрать пункт, чтобы переместить сертификаты в личное хранилище и в завершении нажмите кнопку «Готово».

Цепочка сертификации и цепочка доверия

Прежде чем рассматривать вопрос методики построения трансграничного доверия, хотелось бы разобрать вопрос построения цепочки доверия внутри страны, взяв за пример РФ.

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

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

Цепочка доверия между людьми строится при помощи построения цепочки сертификации. Делается это следующим образом: в роли третьей доверенной стороны выступает аккредитованный удостоверяющий центр. Это юридическое лицо, обладающее одним или несколькими наборами оборудования, которое реализует функции удостоверяющего центра.

Аккредитация означает, что это юридическое лицо отвечает ряду требований законодательства, у него есть соответствующие лицензии ФСБ, Минкомсвязи и иногда ФСТЭК России, должным образом оборудованные помещения, обученный персонал с правильными дипломами и сертифицированные ПО и оборудование в роли удостоверяющего центра (УЦ).

Так вот, этот удостоверяющий центр уполномочен государством подтверждать вашу электронную подпись другим лицам. Процедура подтверждения вашей электронной подписи удостоверяющим центром является процессом создания цепочки сертификации, так как сертификат УЦ так же подписывается Главным удостоверяющим центром (ГУЦ), который является единой точкой доверия.

Для того чтобы этот УЦ мог точно сказать, что под документом именно ваша подпись, вам надо прийти в центр регистрации этого УЦ и предоставить ваш открытый ключ, запрос на сертификат, паспорт и ряд других документов. В результате вы получите сертификат открытого ключа, подписанный на ключе данного УЦ.

Аналогом этого являются 2-я и 3-я страницы внутреннего паспорта гражданина РФ, там тоже стоит ваша уникальная подпись, ФИО и указано, какой орган эти данные заверил. Но есть небольшое различие – в случае паспорта доверие к его носителю строится через подтверждение подлинности самого паспорта, а потом уже через данные, которые в нем указаны.

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

Такой путь хорош, когда УЦ не много, но если каждое ведомство развернет себе свой УЦ, получится ситуация, которая возникла в РФ к 2002–2005 годам: множество УЦ по стране, а единого пространства доверия нет, так как кросс-сертификация среди 800 УЦ – штука технически нереальная.

И вот тут возникает вопрос – как построить единое пространство доверия в отдельно взятой стране так, чтобы оно работало. Подход, который используется в РФ и не только – создание Главного удостоверяющего центра (государственного) (ГУЦ), подпись его сертификатом всех сертификатов УЦ в стране, как результат – построение цепочки доверия через проверку действительности всех сертификатов в подписи через ГУЦ.

Такой подход подразумевает, что проверяются подпись пользователя, действительность сертификата пользователя, действительность всех сертификатов в цепочке (УЦ–ГУЦ). Проверка действительности сертификатов в различных странах производится по-разному. В Эстонии и на Украине для этого требуется обратиться к OCSP/TSP-службе ГУЦ, которая ответит – действующий сертификат или же срок действия истек или сертификат отозван.

В России для проверки надо запросить у каждого УЦ в цепочке список отозванных сертификатов (СОС) и проверить, что сертификат в нем не указан. Пожалуй, наиболее развитым вариантом построения системы PKI следует считать схему с использованием мостообразующего УЦ, в том виде, в котором она используется в США.