ПОДЧИНЕННЫЙ ЦЕНТР СЕРТИФИКАЦИИ И КАК ПРАВИЛЬНО РАЗВЕРНУТЬ ЦЕНТР СЕРТИФИКАЦИИ

Привет, Хабр! Мы начинаем новую серию статей. Она будет посвящена развертыванию службы сертификатов на предприятии на базе Windows Server 2016 с практическими примерами. Сегодня обозначим вступительные моменты и поговорим о типовых схемах развёртывания иерархии PKI: двухуровневой и многоуровневой. Обо всем этом читайте под катом.

Вторая часть серии

Третья часть серии

Что такое подчиненный ЦС?

Поскольку они являются основной технологией, обеспечивающей надежную и безопасную связь в Интернете, и их сложно и дорого устанавливать и поддерживать, закрытые ключи публично доверенных корневых сертификатов чрезвычайно ценны и должны быть защищены любой ценой. Следовательно, для центров сертификации имеет смысл выдавать сертификаты конечных объектов клиентам из подчиненные сертификаты (иногда также упоминается как промежуточные сертификаты). Они подписываются корневым сертификатом, который надежно хранится в автономном режиме и используется для подписи сертификатов конечных объектов, таких как SSL /TLS сертификаты для веб-серверов. Это создает цепь доверия возвращение к корневому ЦС, и компрометация подчиненного сертификата, каким бы плохим он ни был, не приводит к катастрофической необходимости отзывать каждый сертификат, когда-либо выданный корневым ЦС. Кодифицируя этот здравый смысл реакции на ситуацию, CA / Browser Forum Базовые требования запретить выдачу сертификатов конечных объектов непосредственно из корневых ЦС и, по существу, требовать, чтобы они оставались в автономном режиме, что требует использования подчиненных ЦС (также известных как выдающие CA) в интернете PKI.

Помимо обеспечения безопасности корневого ЦС, подчиненные ЦС выполняют административные функции в организациях. Например, один подчиненный ЦС может использоваться для подписи сертификатов SSL, а другой — для подписи кода. В случае публичного Интернета PKI, некоторые из этих административных разделений требуются форумом CA / Browser. В других случаях, которые мы хотим здесь изучить более внимательно, корневой ЦС может выдать подчиненный ЦС и делегировать его отдельной организации, давая этому объекту возможность подписывать общедоступные доверенные сертификаты.

Введение

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

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

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

Доброго времени суток! Товарищи специалисты, подскажите пожалуйста как правильно организовать удостоверяющий центр в рамках компании.

Вопрос технического характера:
Допустим я хочу организовать следующую структуру удостоверяющих центров:

Корневой УД существует только для создания дочерних УД.1. Должен ли корневой сертификат (CompanyName Root CA) иметь ссылки на crl и ocsp?
Просмотрел кучу корневых сертификатов разных корпораций, и только у нескольких есть указание ссылки и/или на crl и ocsp. Собственно вытекает вопрос: 2. Если ссылка указываться, что будет храниться на этих адресах, информация об отозванных сертификатах УД?3. Можно ли отозвать сертификат дочернего УД?

Со ссылками на crl и ocsp в дочерних УД все понятно, там ссылки нужны для быстрого отзыва клиентских и серверных сертификатов.

Вопрос идеологического характера:
CompanyName Project 2 CA — УД Проекта 2 занимается тем что:
1. Выдает клиентские сертификаты — клиентам
2. Выдает серверные сертификаты — серверам
Клиент имеющий ключ, получает доступ к серверу — все как всегда.
Ключ клиента, понятно, подписан CompanyName Project 2 CA, а тот в свою очередь CompanyName Root CA.

CompanyName Security CA — УД например для VPN замается тем что:
1. Выдает клиентские сертификаты — сотрудникам
2. Выдает серверные сертификаты — vpn серверам
Сотрудник имеющий ключ, получает доступ к vpn серверу — все как всегда.
Ключ сотрудника, подписан CompanyName Security CA, а тот в свою очередь CompanyName Root CA.

Может ли случится такое в дикой природе, что хитрый админ у которого есть доступ только к CompanyName Security CA, создаст сертификат и продаст его клиенту, который по нему сможет получить доступ к CompanyName Project 2 CA?

На эту тему, у нас с коллегой вышел спор. Он утверждает, что может. Если вдруг программист реализует неправильную проверку внутри продукта, при проверке цепочки сертификатов, функция может вернуть положительное значение, опустив тот факт что промежуточный УД не тот. Он предлагает для каждого проекта создавать свой ROOT CA и не подписывать их общим ключом компании.

Собственно, хотелось бы увидеть мнение на этот счет, на сколько реальна такая схема.

В ходе изучения материала, наткнулся на пару сертификатов со встроенным логотипом компании.
У меня даже получилось добавить свой логотип в сертификат, но RFC3709 гласит что это просто фенечка — забавы ради. Есть какой ни будь более глубокий смысл добавления логотипа в сертификат на практике?

Почему вам может понадобиться

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

В то время как PKI Цепочка доверия может содержать более трех сертификатов и может быть организована в сложные иерархии, общий принцип сертификатов корневого, промежуточного и конечного объекта остается согласованным: объекты, контролирующие подчиненные ЦС, подписанные доверенными корневыми ЦС, могут выдавать сертификаты, которым неявно доверяют операционными системами конечных пользователей и веб-браузерами. Без подчиненного ЦС, который существует как часть цепочки доверия к корневому ЦС, организация может выпускать только самозаверяющими сертификаты, которые должны быть установлены вручную конечными пользователями, которые также должны самостоятельно принимать решения о том, доверять сертификату или нет, или создавать частные PKI инфраструктура (см. ниже). Избежание этого препятствия удобству использования и потенциальному препятствию доверию, в то же время поддерживая возможность выдачи пользовательских сертификатов по желанию в соответствии с бизнес-целями вашей организации, является одной из основных причин, почему вы можете захотеть, чтобы ваш собственный подчиненный ЦС был частью вашей организации. P KI план.

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

Частное против общественного PKI

При формировании PKI план, предприятия должны делать выбор между частным и государственным PKI, Для целей этой статьи очень важно отметить, что, если организация желает выпустить общедоступные сертификаты и ожидает, что им неявно доверяют, организация должен иметь подчиненный ЦС, подписанный общедоступным корневым ЦС, или получить собственный самозаверяющий сертификат, которому доверяют различные корневые программы. Без цепочки доверия к корневому ЦС конечные пользователи вынуждены самостоятельно определять степень доверия, а не просто полагаться на свою операционную систему и корневые хранилища браузера. С другой стороны, если общественное доверие не нужен частный PKI инфраструктура освобождает организацию от необходимости придерживаться стандартов, регулирующих общественное PKI, В этом случае, можно привести популярное решение, использовать Службы сертификатов Microsoft Active Directory для внутренних PKI. Посмотреть Статья SSL.com на эту тему для более подробного объяснения публичного и частного PKI.

Внутренний против SaaS

При взвешивании преимуществ частного и общественного PKIДля организации также важно учитывать потенциальные затраты на персонал и оборудование и понимать, что они будут нести ответственность за безопасность своего собственного корневого и подчиненного ключей. Если требуется общественное доверие, усилия, необходимые для установления и поддержания соответствия ОС и корневым программам браузера, значительны до такой степени, что становятся непреодолимыми для многих организаций. Хостинг PKI как для общественности и частные ЦС теперь доступны из нескольких корневых центров сертификации (включая SSL.com) и может помочь корпоративным клиентам избежать значительных затрат и усилий собственными силами PKI, Размещенный подчиненный ЦС обычно позволяет организациям выпускать и управлять жизненным циклом сертификатов конечных объектов через веб-интерфейс и / или API, предлагаемые хостом. Хостинг PKI, пользующиеся всеобщим доверием или нет, также дает организациям уверенность в том, что PKI объекты и процессы проходят регулярные, тщательные и дорогостоящие аудиты, и что они будут активно поддерживаться и обновляться по мере развития стандартов и лучших практик.

Общие положения

PKI является технологией безопасности, которая основывается на стандарте X.509 и использует цифровые сертификаты. Целью PKI является повышение безопасности ИТ инфраструктуры предприятия за счёт предоставления механизмов по защите данных от несанкционированного доступа и незаконного изменения данных (подделка данных). Это достигается двумя основными криптографическими механизмами:

Типичная инфраструктура PKI состоит из следующих компонентов:

Структура ЦС и сертификатов выстраиваются в древовидную иерархию. Каждый ЦС может выполнять одну или несколько (совмещать) ролей:

Для понимания процесса построения цепочек сертификатов рекомендую прочитать следующую статью: Certificate Chaining Engine — how it works. Данная статья ориентирована на платформу Microsoft CryptoAPI, она также справедлива (за некоторыми исключениями) и для других реализаций криптографических платформ.

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

Отзыв сертификатов

Помимо задач по выпуску сертификатов, каждый ЦС периодически выпускает списки отзыва (Certificate Revocation List, CRL). Как и сертификаты, целостность списков отзыва обеспечивается цифровой подписью. C RL содержит серийные номера сертификатов, действие которых прекращено по какой-либо причине до официального истечения срока действия сертификата. Таким образом ЦС обеспечивает своевременное изъятие недействительного сертификата из оборота.

Каждый клиент после установки доверия сертификата через цепочку должен убедиться, что ни один сертификат в цепочке не был отозван своим издателем. Для этого клиент перебирает каждый сертификат в цепочке, выбирает CRL предоставленный издателем и проверяет наличие/отсутствие текущего сертификата в списке CRL. Если текущий сертификат находится в CRL, то доверие к сертификату (и всем ветвям дерева под ним) автоматически обрывается.

Фактически, если корневой ЦС отозвал все свои непосредственно изданные сертификаты, то ни один сертификат под этим корнем не будет доверенным вне зависимости от высоты иерархии. Здесь следует отметить один крайне важный и принципиальный момент: невозможно отозвать корневой (самоподписанный) сертификат. Т.е. если по какой-то причине он был скомпрометирован, его можно отозвать только принудительным удалением сертификата из хранилища сертификатов каждого клиента. Дело в том, что ЦС не определяет списки отзывов для самого себя, это делает издатель. В случае самоподписанного сертификата, ЦС является издателем самого себя. И при попытке включить себя в свой же список отзыва получается неопределённость: сертификат ЦС включен в CRL, который подписан ключом этого же ЦС. Если предположить, что сертификат ЦС недействителен, то и цифровая подпись на CRL является недействительной. Как следствие, невозможно достоверно утверждать, что сертификат корневого ЦС отозван. Причём, отзыв корневых сертификатов не предусмотрен и основным регламентирующим стандартом, RFC 5280, параграф §6.1 которого гласит:

When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path.

А на отзыв проверяется только проспективная цепочка. Если говорить в контексте Microsoft ADCS, то тут ситуация усугубляется ещё больше. В частности, вы технически можете отозвать корневой сертификат при помощи certutil.exe или CryptoAPI. Но как только вы это сделаете, ЦС не сможет подписать ни один CRL, как следствие, сертификат ЦС никогда не попадёт в CRL. Более того, даже если использовать различные утилиты (тот же certutil.exe), можно насильно включить сертификат ЦС в CRL, но это мало чем поможет. Дело в том, что конфигурация по умолчанию CryptoAPI даже не пытается проверить корневой сертификат на отзыв.

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

Примеры 1) промежуточного УЦ в открытой иерархии доверия и 2) частной иерархии, которая изолирована от открытой иерархии, со своим собственным корневым УЦ

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

Но что, если мы хотим создать частную инфраструктуру PKI со своим собственным УЦ? Действительно, в некоторых ситуациях такие промежуточные или частные иерархии очень удобны на практике.

Типичные причины для создания промежуточной или частной иерархии

Хостинг и сопровождение собственного УЦ компания может осуществлять самостоятельно или отдать на аутсорсинг. Многие компании берутся за развёртывание крупномасштабных систем PKI своими силами (инсорсинг), не имея необходимых ресурсов на это. Поскольку процесс требует капиталовложений, то лучше заранее оценить свои материальные ресурсы и финансовые возможности на настоящий момент и в ближайшие годы, экономический эффект от использования новой технологии, начальных затрат и стоимости функционирования системы.

Проведя такую оценку, некоторые организации вообще могут прийти к выводу, что инфраструктура открытых ключей им не нужна, а в их случае лучше применить другой инструментарий безопасности: например, VPN или программы шифрования файлов. Вместо всей инфраструктуры PKI иногда проще запустить только сервер сертификатов, который решает проблемы несанкционированного доступа к веб-контенту (IntranetSSL, см. выше).

Промежуточная или частная иерархия

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

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

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

Типичные примеры промежуточной или частной иерархии

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

Кажется, что отдавая свою иерархию доверия на аутсорсинг, вы понижаете уровень безопасности, но на практике выходит наоборот. Это гарантирует, что все компоненты УЦ должным образом защищены и настроены в соответствии с последними передовыми отраслевыми практиками. Дополнительное преимущество — экономия затрат и ресурсной нагрузки на внутренние команды для поддержки PKI. Только в некоторых редких случаях (например, проверка/дешифрование SSL) промежуточное звено должно размещаться у клиента.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Для чего вы используете промежуточный или частный УЦ?

Для разработки собственных решений

Проголосовали 17 пользователей.

Воздержались 11 пользователей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шифрование, цифровые подписи и сертификаты всё плотнее входят в нашу повседневную интернет-жизнь. Если об этих терминах 10 лет назад говорили мало, и далеко не всем ИТ специалистам был известен смысл этих слов, то сейчас они у многих на слуху. И этот процесс длится не год и не два, а добрый десяток лет. Сейчас мы находимся в активной фазе развития клиент-серверных веб-сервисов (привет мейнфреймам!), и значительная доля коммуникации людей и устройств перекладывается на компьютерные сети и интернет. Как следствие, новые условия диктуют новые требования к защите данных. Крупные производители ПО активно продвигают идеологию «безопасного интернета», требуя поддержки цифровых сертификатов, начиная от серверов с конфиденциальными данными, облачных служб, вплоть до кухонного чайника или бельевого утюга (IoT).

Некоторые компании делают это весьма настойчиво. Так, начиная с 2017 года, компания Google считает все сайты без поддержки HTTPS небезопасными: Moving towards a more secure web. И это весьма ощутимо влияет на интернет-индустрию. Во-первых, предупреждение в браузере (Google Chrome) явно не будет радовать ваших потенциальных клиентов и просто посетителей. Во-вторых, сайты без поддержки HTTPS опускаются в поисковой выдаче. Mozilla и другие крупные вендоры также не отстают от Google: Deprecating Non-Secure HTTP. С одной стороны, компании давят на интернет-индустрию, толкая организации на дополнительные расходы, связанные с цифровыми сертификатами. С другой стороны, это — вынужденный шаг, и всем нужно идти в ногу со временем.

Однако текущее положение Internet PKI не позволяет решать эти вопросы достаточно гибко и удобно, требуя существенных затрат. Например, один сертификат SSL для публичного веб-сервера вам обойдётся в сумму порядка $100, а если хотите сертификат с зелёной полосой, это вам будет стоить ещё дороже. И это только за один сертификат! При этом автоматизация процессов находится в самом зачаточном состоянии.

Для решения этих проблем крупнейшие вендоры ПО объединились и совместными усилиями наводят порядок с цифровыми сертификатами в Internet PKI. Во-первых, создан единый стандартизирующий орган — CAB Forum (CA/Browser Forum), который определяет стандартные практики для коммерческих CA, производителей веб-ПО и потребителей сертификатов. Во-вторых, активное продвижение некоммерческого CA (но глобально доверенного) Let’s Encrypt для обеспечения бесплатными сертификатами с возможностью автоматического продления.

Казалось бы, это решает все проблемы безопасной коммуникации, и частные PKI (разворачиваемые в пределах организации) стали сразу ненужными. В какой-то, да, если частный PKI занимался обслуживанием внешних серверов (веб, VPN и т.д.). Но сервисы наподобие Let’s Encrypt в настоящее время покрывают лишь узкий спектр корпоративных потребностей в сертификатах. Например, не покрываются сертификаты для шифрования документов, почты, цифровых подписей. Часть задач, как аутентификация клиентов не покрывается совсем. Ещё одним ограничением является то, что для использования публичных сертификатов, выданных коммерческими CA вам необходимо иметь публичный домен. Получить сертификат для веб-сервера на имя domain.local от Let’s Encrypt технически невозможно. Именно поэтому актуальность частных PKI остаётся на очень высоком уровне. Пример использования частных PKI в корпоративной среде изображён на следующем рисунке:

Об авторе

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

Заключение

И, как всегда, спасибо за ваш интерес к SSL.comгде мы считаем, что более безопасный Интернет — это лучший Интернет.