Построение цепочки доверия в PKI, так ли все просто / Хабр

Что такое корневой сертификат

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

На основе корневого сертификата удостоверяющего центра строится цепочка доверия сертификатам. Любая электронная подпись, выпущенная удостоверяющем центром корректно работает только при наличии корневого сертификата.

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

Прежде чем перейти к пункту о том, зачем сайту нужен SSL-сертификат, стоит обозначить понятие самого протокола SSL. Это криптографический протокол, обеспечивающий надежную передачу данных в сети. Он является гарантией безопасного соединения между пользовательским браузером и ресурсом.

Что внутри ssl-сертификата

SSL-сертификат может содержать следующую важную информацию:

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

Cтруктура ssl сертификатов

Сертификационные центры могут выдавать множество SSL сертификатов, связанных по принципу древовидной структуры. Так, корневой сертификат является корнем дерева, секретным ключом которого подписываются другие сертификаты. Все промежуточные сертификаты (intermediate), находящиеся сразу под корневым, перенимают степень доверия к нему, так как подпись корневым сертификатом является чем-то вроде нотариального удостоверения личности.

• Корневой сертификат ЦС Comodo: AddTrustExternalCARoot
• Промежуточные сертификаты: PositiveSSL CA 2, ComodoUTNSGCCA, UTNAddTrustSGCCA, EssentialSSLCA, Comodo High-Assurance Secure Server CA
• В самом низу изображены SSL сертификаты для отдельных доменов.

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

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

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

Возможна ли установка электронной подписи без корневого сертификата

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

Без корневого сертификата система будет выдавать ошибку: «Невозможно проверить электронную подпись». Это касается как и подписи, установленной на компьютер, так и подписи на защищённом токене.

Выбор цифровой подписи

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

Для компаний дело обстоит несколько сложнее:

1. Если это сайт-визитка, цель которого — проинформировать о деятельности организации, то можно установить DV SSL. Он предотвратит появление всплывающего в браузере окна с информацией о небезопасности площадки и надежно закодирует данные. Обычно предоставляется бесплатно.
2. Ресурсы, которые связаны с транзакциями и другими видами доступа к деньгам, должны подключить EV подпись. Она подтвердит подлинность компании, а в браузерной строке появится полоска зеленого цвета с названием фирмы. Это касается банков, СМИ, платежных систем.
3. Интернет-магазины, форумы и благотворительные платформы должны позаботиться об установке OV SSL. Такие сайты практически не находятся в поле зрения злоумышленников. Однако пользователи захотят удостовериться в подлинности компании, где они планируют сделать заказ или куда собираются вложить свои деньги. SSL-сертификаты с проверкой организации предоставляются только платно.

Двухуровневая иерархия

Двухуровневая иерархия уже подразумевает как минимум два ЦС в дереве, в котором один строго корневой, а остальные — подчинённые. Схема такой иерархии представлена ниже:

Примечание: здесь пунктирными линиями отмечен ручной (неавтоматизированный) процесс получения сертификата. Сплошными линиями отмечен автоматизированный процесс получения сертификатов.

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

Это автоматически сводит к нулю шанс компрометации такого ЦС, поскольку без сети к нему не добраться. Более того, основное время жизни он может (и должен) проводить в выключенном состоянии. Включать его нужно только для обновления собственного сертификата, подчинённого ЦС или для публикации нового CRL. В остальное время он никому не нужен.

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

Именно здесь уже можно начинать задумываться о разделении ЦС по политикам выдачи (или классам). Например, можно выделить один ЦС для выдачи сертификатов с повышенными требованиями к сертификатам (например, сертификаты для аутентификации и цифровой подписи)

и ЦС общего назначения. Управлять ими могут различные команды ИТ-администраторов. При этом каждый подчинённый ЦС будет совмещать задачи ЦС политики и издающего ЦС. Это вполне допустимо, если предположить, что количество ЦС на каждый класс не более одного.

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

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

Зачем нужен частный pki?

Шифрование, цифровые подписи и сертификаты всё плотнее входят в нашу повседневную интернет-жизнь. Если об этих терминах 10 лет назад говорили мало, и далеко не всем ИТ специалистам был известен смысл этих слов, то сейчас они у многих на слуху. И этот процесс длится не год и не два, а добрый десяток лет.

Сейчас мы находимся в активной фазе развития клиент-серверных веб-сервисов (привет мейнфреймам!), и значительная доля коммуникации людей и устройств перекладывается на компьютерные сети и интернет. Как следствие, новые условия диктуют новые требования к защите данных.

Как получить корневой сертификат ssl?

Купив SSL сертификат на нашем сайте, Вы получите архив, содержащий 3 файла сертификатов:

• Ваш личный (с номером заказа)
• корневой
• промежуточный.

Как работает ssl-протокол

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

1. Публичный. Это собственно и есть SSL-сертификат. Он зашифровывает данные и используется при передаче пользовательской информации серверу. Например, посетитель вводит на сайте номер своей банковской карточки и нажимает на кнопку «Оплатить».
2. Приватный. Необходим для раскодирования сообщения на сервере. Он не передается вместе с информацией, как в случае с публичным ключом, и всегда остается на сервере.

Чтобы сайт обрабатывал такие соединения, его владельцу нужен SSL-сертификат. Это своеобразная цифровая подпись, которая индивидуальна для каждой платформы.

Какую информацию содержит корневой сертификат

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

Кому не обойтись без ssl-сертификата

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

Для SEO-специалистов, которые учитывают малейшие аспекты продвижения, также рекомендуется подключение подписи. Хотя на данный момент этот фактор слабо влияет на ранжирование страниц.

А вот чисто информационным ресурсам — блогам, визиткам и личным страницам можно обойтись и без сертификации.

Можно ли создать корневой сертификат самому?

Для этого необходимо зарегистрироваться в качестве центра сертификации, что требует больших временных и финансовых затрат. Поэтому рациональнее воспользоваться услугами всем известных доверенных центров сертификации, например, Thawte, Comodo, Verisign, GeoTrust, GlobalSign, которые без проблем распознаются практически всеми браузерами.

И все же в некоторых случаях создать свой корневой сертификат SSL – выгодно.Так, например, поступили с сервисом Webmoney. Его владельцы зарегистрированы в качестве центра сертификации и обеспечивают своих пользователей самоподписанными клиентскими сертификатами безопасности, на основе которых осуществляется индивидуальная аутентификация каждого пользователя в системе.

Об авторе

Вадим Поданс

— специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его

Одноуровневая иерархия

Одноуровневая иерархия является самой простой в реализации и имеет следующий вид:

Такая иерархия является самой простой и экономичной как по ресурсам (лицензиям), так и по расходам на обслуживание и управление. Достаточно развернуть один такой ЦС в лесу Active Directory, и он будет обеспечивать сертификатами всех потребителей. Из неочевидных, но немаловажных достоинств можно отметить очень короткую цепочку сертификатов. Т.е. время на проверку доверенности и отзыва сертификата будет тратиться гораздо меньше, чем в любых других иерархиях.

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

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

Другой момент связан с гибкостью разделения ЦС на функциональные уровни (делегирование). Например, невозможно организовать несколько различных политик выдачи, разделить на классы (например, один ЦС издаёт сертификаты только машинам и устройствам, другой только для пользователей) и т.д., потому что он всего один.

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

Получение и установка ssl-сертификата

Чтобы получить цифровую подпись, необходимо зайти на сайт центра сертификации и предоставить необходимую информацию для данного типа цифровой подписи. Например, для получения DV SSL достаточно предоставить доменное имя, email и номер телефона. Для других разновидностей могут понадобится документы, которые подтверждают наличие юридического лица: ИНН, сведения из ЕГРЮЛ и прочее.

После активации, ссылка на которую придет на указанную почту, следует дождаться окончания проверки. Этот процесс может занять от десятка минут до нескольких суток, после чего на e-mail придет архив с сертификатом, который требуется установить на сайт.

Словарь терминов

В этой части серии использованы следующие сокращения и аббревиатуры:

Сложности

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

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

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

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

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

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

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

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

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

Типовые схемы развёртывания иерархии pki

В этом разделе мы рассмотрим типовые (или классические) схемы развёртывания иерархии PKI в условиях предприятия и проводятся оценки каждой схемы и рекомендации. Следует отметить, что ни одна из них не является универсальной, и каждая может иметь смысл в своих пределах.

Типы ssl-сертификатов

SSL-сертификаты делятся не несколько видов в зависимости от количества доменных и субдоменных имен, на которые они будут устанавливаться, а также от способа проверки платформы. По методу проверки существует три основных варианта:

Трёх- и более уровневые иерархии

В более крупных компаниях со сложной организацией сетей может случиться, что двухуровневая иерархия не может обеспечить необходимый уровень гибкости управления ЦС. Например, когда компания использует географический принцип разделения с относительной автономией ИТ отделов в каждом регионе.

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

В в своём сертификате он указывает поддержку (и ссылку на соответствующий документ) тех или иных нормативных документов и выпускает сертификаты для издающих ЦС, действующих в рамках тех политик, которые обозначены в сертификате (грубо говоря, в данном регионе).

В таких иерархиях корневой ЦС и ЦС политик изолируют от сети, а к сети уже подключаются только издающие ЦС:

Здесь также пунктиром отмечен ручной процесс получения сертификата для ЦС и сплошными линиями автоматизированный процесс получения сертификата для клиентов.

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

В рамках этой серии статей рассматривается наиболее популярная (в большинстве случаев) двухуровневая иерархия.

Целевая аудитория

ИТ-администраторы, ИТ-инженеры и специалисты по безопасности, имеющие основные понятия о цифровых сертификатах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

Использование SSL-сертификата повышает доверие пользователей к вашему сайту. Это стоит учитывать владельцам интернет-магазинов, банковских и платежных систем, а также площадок, где посетителям требуется предоставить свои персональные данные для создания аккаунта. Однако важно понимать, что цифровая подпись не является стопроцентной гарантией защиты от хакерских или DDoS-атак.