Contents of this directory is archived and no longer updated.

Update 05.12.2009: выпилена часть про смену пароля как не совсем правильную (см.каменты). Судя по логике смены паролей компьютерами в домене, можно реализовать Offline CA в доменной среде с большим сроком бездействия. Но это всё равно не отменяет того факта, что такое решение будет не совсем правильным.



КДПВСегодня хочу немного обсудить несколько (все не получится :-() вопросов планирования ирерархий Certification Authority (CA), как это делается в реальном мире. Как таковых бест-практисов на эту тему не существует, равно как и бест-практисов по планированию лесов Active Directory. Есть только несколько стандартных классических схем и рекомендаций на основании которых можно выбирать. Этот вопрос очень серьёзный, поскольку иерархии PKI и AD очень редко меняются в силу сложности и дороговизны процесса. И с тем вариантом, который вы выбрали на этапе планирования, скорее всего вы будете жить очень долго.

 

 

Лирическое отступление

В реальной жизни домены и PKI в основном развёртываются по одному из трёх сценариев:

  • Говноадминами в метро на коленке за 15 минут;
  • Системными администраторами после тщательного (по мере сил) анализа существующей инфраструктуры;
  • Системными интерграторами или аутсорсерами, грохая огромные деньги на полный и компетентный анализ существующей инфраструктуры, учитывая требования бизнеса с запасом на 5 лет минимум.

Не всем посчастливилось устроиться работать в компанию последней группы и чаще всего приходится работать в первых двух. С первым вариантом даже обсуждать нечего, потому что с такими администраторами говорить вовсе не о чем, разве что смаковать последние новости с ЛОРа, секлаба и двача. Я всё-таки надеюсь, что этот пост будет полезен администраторам второй группы.

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

  1. Root CA — корневой CA, который является наиболее критической точкой в инфраструктуре, потому что потеряв/скомпрометировав его, ваша PKI и репутация компании летит к чёрту, поскольку это та точка доверия, которая проверяется весьма условно. Т.е. вы доверяете тому или иному корневому сертификату только на основании каких-то косвеных данных или собственных предпочтениях. Технически проверить «хорошесть» корня не представляется возможным. Как правило выдаёт сертификаты только подчинённым Policy CA.
  2. Policy CA — даже не знаю как его перевести, поэтому не буду. Но его суть сводится к тому, что данный тип CA определяет политику сертификации на данном CA и на всех последующих CA в цепочке. Каждый Policy CA характеризуется своим собственным CPS (Certificate Practice Statement). Поэтому если у вас на предприятии используются различные схемы проверки подлинности участников, которые запрашивают сертификаты и требования к ним, а так же мероприятия по организации CA, то каждая такая схема выносится в отдельный CPS и отдельный Policy CA. Так же, как и корень, является критической точкой в иерархии, но чуть меньше, чем корневой CA. Поскольку изъять из эксплуатации (decomission) Policy CA всяко проще, чем корневой. Об этой проблеме я уже говорил в посте Certificate chaining engine (CCE) и отзыв корневых сертификатов. Policy CA может быть выделенный и выдавать сертификаты только подчинённым Policy или Issuing CA. А может быть и одновременно совмещён с ролью Issuing CA.
  3. Issuing CA — издающий CA, который уже выдаёт сертификаты конечным потребителям — пользователям, компьютерам, различным сетевым устройствам. Каждый Issuing CA должен подчиняться тем требованиям и указаниям, которые описаны в CPS Policy CA.

Enterprise Root CA — хороший выбор?

В условиях малого и среднего бизнеса не всегда можно набрать компетентный в этих вопросах персонал, поэтому админстраторы обычно делают всё попроще — ставят 1 или 2 Enterprise Issuing CA и радуются жизни. В таких ситуациях один единственный CA выполняет все 3 роли — он и корневой, и Policy и издающий CA. Чем это плохо? Учитывая тот факт, что сервер CA находится постоянно в сети и его настройки безопасности могут содержать брешь, через которую CA можно легко скомпрометировать. Это, например, совмещение роли CA с другими ролями, как контроллер домена, сервер терминалов, файл-сервер и т.д. В данных случаях получить доступ к закрытому ключу CA будет проще, чем в остальных сценариях.

Если выделить отдельный сервер, член домена, под роль CA, то риск снижается, но незачительно, поскольку любой член групп Domain/Enterprise Admins, операторы бэкапа, etc. могут получить доступ к ключу CA. Это весьма неиллюзорная угроза, поскольку обидевшийся админ может поломать вам единственный корневой CA и даже использовать его ключ в корыстных целях — выпускать «липовые» сертификаты. Учитывая, что не существует идеальной ОС и в любой из них обнаруживаются те или иные уязвимости, при помощи которых злоумышленник может положить ваш CA не слезая с подругидивана просто запустив эксплоит (я надеюсь, что случай с конфикером/кидо напоминать не надо?). Другая проблема заключается в том, что ваш корневой CA будет жить ровно столько, сколько живёт сам домен/лес, поскольку мигрировать в другой домен/лес может быть весьма проблематично. И если вы решили переименовать домен или мигрировать в другой лес, то неиллюзорный секс с миграцией PKI вас ожидает, особенно, если всё делалось простым Next-Next. Это означает, что даже в условиях сети на 20 человек, держать корневой CA постоянно в сети — не самая лучшая идея. Хотя, если у вас есть HSM (Hardware Security Module), то опасность компрометации такого CA снижается, но не на столько, чтобы оправдать наличие корневого CA в доменной сети. Да и цена таких девайсов явно не по карману компаниям малого и среднего бизнеса. Лично мне с HSM поработать не довелось.

Bad solution

Следовательно, чтобы избежать всех этих проблем путь есть только один — вынос корневого CA из домена на отдельный сервер рабочей группы. При этом вы можете не покупать Enterprise редакции Windows Server, поскольку в рабочей группе хватает Standard Edition (а с выходом Winows Server 2008 R2, Standard тянет даже на Enterprise CA). Какие преимущества вы получите от такого CA?

  • Резко уменьшается количество людей, которые могут получить доступ к серверу (как физический, так и программный);
  • В рабочей группе вы никак не привязаны к имени домена/леса. Что позволяет сохранять корень доверия даже при смене лесов;
  • В рабочей группе сервер не обязательно должен быть подключён к сети. А лучше вообще не подключать к сети, в результате чего вероятность атаки с использованием уязвимости резко падает до нуля;
  • Вы можете сделать Offline CA, который будет включаться только для того, чтобы обновить свои CRL, выдать сертификат новому подчинённому CA или обновить свой собственный сертификат. Учитывая, что корневой CA выдаёт сертификаты только другим CA, поэтому вероятность необходимости отзыва такого сертификата не очень высока. Это позволяет увеличить срок действия CRL до нескольких месяцев. Здесь главное — не переусердствовать и делать срок действия CRL более 3-х месяцев вряд ли будет разумным.

С учётом выской популярности и доступности систем виртуализации, даже если у вас нет лишнего железа для сервера CA (а CA к ресурсам крайне нетребователен и может спокойно работать на железе уровня Pentium III), то вы с лёгкостью можете развернуть корневой CA на виртуальной машине с минимальной затратой средств. При этом виртуальную машину лучше хранить на съёмном жёстком диске, который можно прятать в сейф.

Policy CA — что это и зачем оно нужно?

Это достаточно большой и очень теоретический вопрос. В действительности Policy CA от остальных отличает только активная кнопка Issuer Statement:

Policy CA

К сожалению очень многие компании забивают на такую мелочь. Подумаешь, есть кнопка или нет её. Но в действительности Policy CA очень нужен, поскольку кнопка Issuer Statement ведёт на CPS данной ветки иерарахии CA. Как я уже говорил, CPS документально описывает порядок работы служб сертификации и сопутствующих механизмов. В RFC 3647 вы можете более подробно ознакомиться с содержимым CPS или просто почитать CPS коммерческих CA, например, VeriSign — http://www.verisign.com/repository/cps. И это не просто бумажка какая-то, а уже юридический документ, за нарушение условий которого можно получить конфет пизденцовнанести сильный ущерб доверию компании со стороны самих сотрудников и внешних партнёров. Поскольку компания может вырасти или могут поменяться условия работы, не рекомендуется совмещать роль Policy CA с ролью корневого CA, потому что корень у вас только один, а политик сертификации может быть несколько. Все последующие CA (если есть) будут подчиняться политике самого первого Policy CA в цепочке. Поэтому каждый CA второго уровня (следом за корнем) будет представлять своё дерево политик сертификации со своим CPS.

Если Policy CA не рекомендуется совмещать с корнем, то совмещать его с Issuing CA вполне можно, если у вас планируется только один Issuing CA. Если же их будет больше одного, то Policy CA следует выносить отдельно и предусмотреть для него такие же правила размещения, как и для Offline Root CA (об этом я рассказывал чуть выше). Почему не рекомендуется совмещать Policy CA и Issuing CA, если издающих будет больше одного? Дело в том, что у вас не должно быть больше одного уровня издающих CA. Т.е. вот такой схемы:

 

Bad solution

Поскольку в этом во-первых нет необходимости и вы почём зря удлиняете цепочку сертификации. В принципе, иерархии состоящие из более, чем 4-х уровней нежизнеспособны, поскольку CCE (Certificate Chaining Engine) каждый раз будет тратить очень много времени на построение и проверки цепочек сертификатов и из-за таймаутов может давать битые цепочки. Конечно же, за такое вас никто бить по лицу ногами не будет, но таких схем лучше избегать за исключением очень сложных схем, когда используется 2 уровня Policy CA (что подразумевает несколько различных политик сертификаций) и 2 уровня издающих CA. Такое возможно только в больших компаниях и их я не затрагиваю в данном материале. В случае если вам необходимо иметь несколько издающих CA под одним Policy CA, то схему лучше строить вот так, в зависимости от количеста издающих CA:

Good solution

В первом случае у нас будет простая иерархия с единственным издающим CA, который так же выполняет роль Policy CA и ниже по иерархии ничего нет. Если ВНЕЗАПНО появятся потребности в ещё одном издающем CA, то это решается достаточно путём миграции ко второй схеме. Я не уверен, что Microsoft поддерживает миграцию с Online Enterprise CA на Offline Standalone CA, но я сам такие миграции делал и особых проблем это не вызывало. Просто при миграции нужно учитывать несколько нюансов и всё. Поэтому с учётом перспективы целесообразно делать такую схему изначально. По большому счёту это наиболее распространённые схемы иерархий PKI.

Время жизни сертификата CA

И ещё один момент, который хочу посмотреть — какой срок действия должен быть у сертификата CA? Вопрос достаточно риторический и зачастую зависит от требования к сроку действия конечных сертификатов. Но обычно используется простая схема:

  • конечный сертификат — 3 года;
  • Issuing CA — 5 лет;
  • 2 Level Policy CA — 10 лет;
  • 1 Level Policy CA — 15 лет;
  • Root CA — 20 лет.

Т.е. если у вас 2-х уровневая иерархия PKI, то Issuing CA будет на 5 лет, а Root CA на 10 лет. Для 3-х уровневой иерархии Issuing CA на 5 лет, Policy CA на 10 лет и Root CA на 15 лет. Но основной отправной точкой будет требования к сроку действия конечных сертификатов.

Как бы и всё. Данный материал в основном опирается на общие рекомендации и моё личное восприятие этого мира, поэтому готов обсудить альтернативные варианты.


Share this article:

Comments:

Stanky

> Сделать его offline не получится, потому что компьютерам в домене каждые 30 дней необходимо менять свои пароли. Это совершенно не Верно! Во-первых - необходимо менять не означает, что через 31 день компьютер этого сделать не сможет. Тут всё точно так же как и с пользователями - если пароль истёк, то при входе в систему его попросят изменить и совершенно неважно как давно он истёк - будь то месяц или год;). Грабли со сменой паролей и отключением сервера от сети можно словить только в случае контроллеров домена. Во-вторых - данный момент настраивается групповой политикой вплоть до отключения изменения пароля вообще, что лично я часто применяю для тестовых виртуальных машин при использовании Snapshot'ов. > Другая проблема заключается в том, что ваш корневой CA будет жить ровно столько, сколько живёт сам домен/лес > В рабочей группе вы никак не привязаны к имени домена/леса. Что позволяет сохранять корень доверия даже при смене лесов > Я не уверен, что Microsoft поддерживает миграцию с Online Enterprise CA на Offline Standalone CA, но я сам такие миграции делал и особых проблем это не вызывало. Враньё и противоречие! Во-первых - смерть леса не означает смерть корня, ибо мы можем взять его закрытый ключ и перенести его хоть на Standalone CA о чём ты сам же и говоришь;). Во-вторых - уж если говорить о привязке к имени домена, то у самого корневого сертификата её, в общем-то, нет.

Vadims Podāns

> Во-первых - необходимо менять не означает, что через 31 день компьютер этого сделать не сможет вопрос: а в чём профит такой схемы? Что у тебя будет по сути мёртвая машина. И, как я говорил корень лучше вообще к сети не подключать, ибо нефиг. > Во-вторых - данный момент настраивается групповой политикой вплоть до отключения изменения пароля вообще, что лично я часто применяю для тестовых виртуальных машин при использовании Snapshot'ов. ну в своих виртуалках ты можешь делать что угодно! :) > Враньё и противоречие! :) > Во-первых - смерть леса не означает смерть корня по дефолту это что-то близкое к этому. Потому что по тому же дефолту первые ссылки ведут на LDAP, из-за чего как минимум на данном этапе будет теряться 20 секунд времени (по 10 секунд на CDP и AIA). Если есть ещё один уровень CA с LDAP ссылками, то и там приплюсуй по 20 секунд таймаутов. Для http уже остаётся 5 секунд. Если клиент будет сильно слоупочить, то цепочки будут рваться. Кстати, это одна из причин почему я и не использую LDAP в CDP и AIA. С HTTP тоже могут быть трудности. Сменили домен/лес, но для этого придётся где-то создавать домен с таким именем и прописывать в DNS новые записи. Если для внутренних клиентов это просто — в DNS создал зону и набил нужные адреса, то для внешних клиентов имя домена придётся поддерживать и дальше (чтобы http ссылки не бились). И за это придётся платить. Вобщем, не каждый случай Enterprise Root CA можно спокойно мигрировать в Standalone Root CA, иногда будет проще всё грохнуть и сделать с нуля. > ибо мы можем взять его закрытый ключ и перенести его хоть на Standalone CA о чём ты сам же и говоришь одного ключа может не хватить. Всё-таки лучше переносить весь PFX файл, т.е. вместе с самим сертификатом. > Во-вторых - уж если говорить о привязке к имени домена, то у самого корневого сертификата её, в общем-то, нет. ну вобщем-то есть, потому что по дефолту когда ты поднимаешь Enterprise CA, то его Subject будет содержать DN домена. Принципиальной разницы в этом нет, просто нелогично будет, что у тебя новый домен/лес adatum.com, а Subject сертификата будет выдан на litware.com (старое имя). Это ещё один повод, почему при поднятии CA поле Subject нужно заполнять так, чтобы оно отражало принадлежность к компании, а не к имени домена или леса. Тогда вне зависимости от домена компании ни у кого никаких подозрений не будет. Т.е. тут играют роль не только технические моменты, но и психологические (если их так можно назвать) тоже.

Stanky

> вопрос: а в чём профит такой схемы? Тут дело в том, что идёт явный обман читателя, ибо цитирую: "Сделать его offline не получится". В общем, призываю отличать "нужно" от "можно";). > Потому что по тому же дефолту первые ссылки ведут на LDAP Вадя, вот не нужно сейчас уворачиваться, как уж на сковороде;)! Если поискать мои комментарии к соответствующему посту, то вспомнишь что по тому же умолчанию в корневом сертификате прописывается усключительно CDP и то такое поведение было лишь в 2003, в 2008 в корне нет ни AIA ни CDP. Но если, опять же, вспомнить, ты сам учил, что CDP в корне быть не должно;)! > Если есть ещё один уровень CA с LDAP ссылками О каком "ещё одном уровне" мы говорим при переезде, тем более в случае разворачивания PKI говноадминами? Мы можем просто сохранить лишь корень, а дальше создать новые подчинённые центры сертификации и соответственно прописывать в них новые CDP и AIA;)... > Сменили домен/лес, но для этого придётся где-то создавать домен с таким именем и прописывать в DNS новые записи А вот это потребуется только в случае сохранения всей старой инфраструктуры PKI - подчинённые центры и конечные потребители. > то для внешних клиентов имя домена придётся поддерживать и дальше (чтобы http ссылки не бились). И за это придётся платить Ну это вообще смешно! Продление жизни домена стоит 450 рублей в год;)! Да и нужен он будет лишь до тех пор, пока срок жизни старых подчинённых центров не истечёт. > Вобщем, не каждый случай Enterprise Root CA можно спокойно мигрировать в Standalone Root CA Думаю, при грамотном подходе, неразрешимых проблем возникнуть не должно. > Всё-таки лучше переносить весь PFX файл, т.е. вместе с самим сертификатом. Вадя, ну понятное дело, что я говорил о криптопаре, а не только о закрытом ключе;). > ну вобщем-то есть, потому что по дефолту когда ты поднимаешь Enterprise CA, то его Subject будет содержать DN домена Именно поэтому я и сказал "в общем-то, нет". > Принципиальной разницы в этом нет, просто нелогично будет Вот именно! Нелогично != привязка. То есть, технически это ни как не повлияет на работу PKI.

Vadims Podāns

> Тут дело в том, что идёт явный обман читателя, ибо цитирую: "Сделать его offline не получится". В общем, призываю отличать "нужно" от "можно";). Можно, но не всегда. Почему — я уже писал. > Вадя, вот не нужно сейчас уворачиваться, как уж на сковороде;)! Если поискать мои комментарии к соответствующему посту, то вспомнишь что по тому же умолчанию в корневом сертификате прописывается усключительно CDP и то такое поведение было лишь в 2003, в 2008 в корне нет ни AIA ни CDP. Но если, опять же, вспомнить, ты сам учил, что CDP в корне быть не должно;)! а при чём тут корень? Я говорю про конечные сертификаты. Или ты будешь утверждать, что по дефолту там не LDAP? Во всяком случае, сколько я видел PKI (не верисайна!), везде простой дефолтный next-next. Вот с дефолтом переезжать не очень интересно. Я не думаю, что кто-то будет заморачиваться поднимать какой-нибудь LDS только для поддержки LDAP ссылок. > О каком "ещё одном уровне" который будет выполнять Offline Policy CA. Он не всегда будет, но желательно иметь такой CA. > А вот это потребуется только в случае сохранения всей старой инфраструктуры PKI - подчинённые центры и конечные потребители. безусловно. Если старая инфраструктура не нужна, то там вообще никаких проблем нет. Всё грохнул и начинай жить заново. > Ну это вообще смешно! Продление жизни домена стоит 450 рублей в год;)! Да и нужен он будет лишь до тех пор, пока срок жизни старых подчинённых центров не истечёт. смешно-не смешно, зато правда. Это просто ещё один лишний хвост. Даже по 450 рублей + расходы на содержании зоны. И так лет на 10. И об этом тоже нужно думать. > Думаю, при грамотном подходе, неразрешимых проблем возникнуть не должно. вот ты можешь дать определение "грамотного подхода"? Это изначально правильное планирование или что? Если так, то миграция Enterprise -> Standalone как бы не подразумевается, потому что оно уже есть изначально. Или что ещё ты подразумеваешь в этом слове? > Вот именно! Нелогично != привязка. То есть, технически это ни как не повлияет на работу PKI знаешь, технически вообще есть только одна привязка - имя CA. Остальное всё относительно. Ну и ещё ссылки в CDP/AIA. Но тем не менее всякие нетехнические детали тоже имеют значение.

Stanky

> Можно, но не всегда. Почему — я уже писал. Вадя, ты меня опять не понял! Любой компьютер, кроме контроллера домена, можно выключить на любой срок и это не вызовет никаких проблем. Пароль компьютер изменит при следующем включении... > а при чём тут корень? А при том, что всё доверие строется на нём! > Я говорю про конечные сертификаты. Или ты будешь утверждать, что по дефолту там не LDAP? В таком случае, о каких внешних пользователях тут говорить;)? Устранить это можно только одним способом - правильно настроить ссылки и перевыпустить сертификаты. > Во всяком случае, сколько я видел PKI (не верисайна!), везде простой дефолтный next-next. Можно подумать, ты их видел миллион;)! > Я не думаю, что кто-то будет заморачиваться поднимать какой-нибудь LDS только для поддержки LDAP ссылок. It Depends. Если сертификатов огромное количество и их перевыпуск выльется в копеечку, можно и подумать. Но если у кого-то такой PKI, то наверняка и сертификатов там немного, так что будет гораздо проще их просто переиздать с правильными ссылками. > который будет выполнять Offline Policy CA. У "говноадминов" его не будет точно;)! > + расходы на содержании зоны Это ещё более смешно, чем стоимость домена:)! Это копейки! Даже, если взять, что дополнительные расходы обойдутся нам в 10000 рублей за год (а в действительности эта сумма не накапает даже за 10 лет), то получается, организации нужно выкладывать по 27 рублей в день. Неужели ты думаешь, что даже самая быдло-контора не справится с такими платежами и необходимо заранее планировать такие мега-расходы? > вот ты можешь дать определение "грамотного подхода"? Я говорил о грамотном подходе при миграции;). > Ну и ещё ссылки в CDP/AIA В корне нет AIA, а CDP в нём нет (по умолчанию), начиная с 2008.

Vadims Podāns

> Вадя, ты меня опять не понял! Любой компьютер, кроме контроллера домена, можно выключить на любой срок и это не вызовет никаких проблем. Пароль компьютер изменит при следующем включении... читай шапку поста. > А при том, что всё доверие строется на нём! Ты вообще о чём? > Можно подумать, ты их видел миллион;)! не миллион, но вообще общее представление построить можно. Редко у кого сделано как положено. > В таком случае, о каких внешних пользователях тут говорить ну хотя бы сотрудников компании, которые из дома заходят на OWA за почтой. В данном случае проблему будут испытывать только внешние пользователи. А с переездом в новый лес — и внутренние тоже. С этим уже определились, что LDAP в CDP и AIA по большому счёту нах не нужен. > It Depends. Если сертификатов огромное количество и их перевыпуск выльется в копеечку, можно и подумать. угу. > Это ещё более смешно, чем стоимость домена:)! Это копейки! Даже, если взять, что дополнительные расходы обойдутся нам в 10000 рублей за год (а в действительности эта сумма не накапает даже за 10 лет), то получается, организации нужно выкладывать по 27 рублей в день. тут дело даже не в деньгах. Просто эта мелочь на себя будет отвлекать внимание. > В корне нет AIA, а CDP в нём нет (по умолчанию), начиная с 2008 я про сам корневой сертификат вообще ничего не говорил. Я говорил про CDP/AIA всех остальных сертификатов. > Я говорил о грамотном подходе при миграции;). вот можешь рассказать про граммотный подход при миграции? Если всё изначально сделано так, что PKI не зависит от лесов, то переезд Enterprise CA в другой лес не вызовет вообще никаких проблем. При этом количество переносимых CA снижается до количества Enterprise CA.

akawildcat.livejournal.com

Здравствуйте! "Мне поручено и я пытаюсь..." Пытаюсь "всё сделать правильно". Подскажите, пожалуйста, если у нас есть родительская компания и у нее есть RootCA, то видимо нам не имеет смысла делать свой RootCA, а сделать только PolicyCA и IssuingCA, чтоб не удлиннять излишне цепочку? Заранее прошу прощения, если мой вопрос глупый. Принципиально вроде бы уже решено (на нашем уровне), что у нас не будет своего RootCA, а будет только PolicyCA м IssuingCA, но что-то меня сомнения одолели. PS система Windows 2003 server Заранее благодарю за ответ.

Vadims Podāns

А в чём сомнения? По возможности следует избегать создания новых корней, если иерархию можно подвязать под один корень.

akawildcat.livejournal.com

Да, пожалуй, всё же еще одно звено будет лишним. Я просто рассматриваю возможность, что нам может понадобиться два PolicyCA и вроде бы не нахожу такой необходимости. А сомнения как всегда смутные - не доводилось мне пока проектировать иерархию СА...

Vadims Podāns

Ничего страшного не случится. Просто подумайте, может, есть возможность разместить 2 PolicyCA на одном уровне. В любом случае, до 4-х CA в цепочке — допустимая длина (хоть и предельная).

akawildcat.livejournal.com

Если размещать два PolicyCA на одном уровне, то придется же два сертификата у головной компании запрашивать? И ведь надо еще им объяснить, зачем. А я и сама не знаю - зачем... Пусть пока будет один Policy и два Issuing (для внешних и внутренних пользователей отдельно)...

Vadims Podāns

извините, но я тоже не знаю, зачем вам два Policy CA.

akawildcat.livejournal.com

Если PolicyCA будет offline, то как же пользователи смогут получить у него сертификаты (те, которые уже выпущены) - для построения цепочки сертификатов (с помощью CCE)? Или они тоже на веб-сервере публикуются?

akawildcat.livejournal.com

Прошу прощения, радикально ступила. В сертификате есть поле AIA, в котором указывается, откуда качать сертификат вышестоящено CA.

Скилов Владимир

Не совсем понятно, насколько хорошей будет схема с 1 Offline Standalone Root CA и 2-мя Online Enterprise Policy/Issuing CA, выносить в таком случае Offline Standalone Policy CA как-то не очень хочется ибо это обслуживание, лицензии и т.д., а практического смысла не вижу никакого. PS: Спасибо за статьи, в вопросе PKI как лучик света ... толково и по существу.

Скилов Владимир

Нашёл сам. В другой статье http://www.sysadmins.lv/PermaLink,guid,5ee5feb6-bcb0-4a1f-adfc-de989556785a.aspx описана данная конфигурация.

Vadims Podāns

вот, почитайте подробнее по вопросу PolicyCA: http://www.sysadmins.lv/PermaLink,guid,a421d4c0-e56b-43e0-abbe-1704a7946eba.aspx т.е. это нормально иметь один Offline Root и 2 Online Subordinate (если они не подвязаны к разным политикам).

Valentin

Владимир, добрый день, возможно у вас это было описанно, но я пока не нашел. Меня интересует схема, когда система pki предприятия встраивается так сказать, в общемировую. И сертификат корневого ЦС не является самоподписанным. Т.е. корневой ЦС предприятия будет иметь подтверждаемый verisign сертификат, и ЦС предприятия далее выдает и управляет сертификатами для своих клиентов. Можно это в двух словах описать?

Vadims Podāns

http://social.technet.microsoft.com/wiki/contents/articles/certification-authority-root-signing.aspx

Dmitry Solovev

Может вопрос будет немного странный. В модели офлайн Root CA и офлайн Policy CA возможна ли установка этих 2х ролей на 1 физический хост? И в этой-же модели возможна первоначальная установка 1 а не 2х Issuing CA. Смысл такой модели таков. Общая сеть компании более 200 хостов, но сейчас речь идет об 1 основном офисе 50+ хостов. В будущем будет еще подключено 3 офиса по 20-25 хостов. Офисы распределенны по территории.

Vadims Podāns

Нет, на одну ОС можно установить только один инстанс Certification Authority.

coockie

кое-что из прочитанного всё равно ставляет вопросы: на примере 2х уровневой структуры 1 - надо ли юзерам и компам устанавливать серты корневого и выпускающего или только выпускающего? 2 - если скомпрометируют выпускающий то придётся перевыпустить все серты которые он выпустил и его собственный серт тоже - так?

Vadims Podāns

1) корневой надо устанавливать обязательно. Издающие сами устанавливаются на клиенты. 2) в принципе, достаточно отозвать только сертификат издающего CA, тогда все сертификаты, которые он выпустил автоматически будут считаться отозванными тоже.

coocckie

Не хочу показаться говноодмином из метро за 15 минут на коленке next-next ok profit маке бизнес пошел ежже, но чёт я всё равно не понимаю в чём смысл 2-х уровневой структуры кроме политик и возможности миграции в другой лес? Какие ещё плюсы? Если поломали выпускающий то одинх все серты перевыпускать, то же самое что и с одноуровневой иерархией - переустановить и ехать дальше если порвут или не так? Что может сделать кидо\конфикер с СА? А если в локальные админы добавить только доверенное лицо которое распишеться за ответственность, настроить файрволл, все обновления накатить, комерческий резидентный антивирус и не совмещать с другими ролями неужели одноуровневая иерархия всё равно будет только для говноадминов? Никак не могу определиться: 2-х уровневою или всё же говноадмина включить. В моём случае првда полюбому совмещать роли придёцца и ставить корневой либо выпускающий на контроллер, на сколько это будет хреново?

Comments are closed.