.
  • Внедрение цифровых подписей документов и файлов, что гарантирует их целостность и альтернативу ручной подписи.
  • Setup Создание 3-х уровневой иерархии уже будет подразумевать разделение иерерхии на области действий CPS ( Certificate Practice Statement) и будут подвержены различным политикам управления серверами CA.

    Это достаточно долгая песня и о ней говорить не будем. Поэтому мы остановимся на двухуровневой иерархии с одним корневым центром сертификации (Root CA) и одним издающим центром сертификации (Issuing CA). Planning CA types yack

  • 25. 2010 09:10 (GMT+3)
  • Устанавливаем Certification Authority (часть 1) — Введение
  • p/invoke
  • My Nuggets В данном цикле статей мы будем использовать преимущества обоих типов CA. Для корневого CA будем использовать Standalone CA в рабочей группе и для издающего CA будем использовать Enterprise CA в домене Active Directory.

    При этом Standalone CA не будет издавать сертификаты конечным потребителям, а только для других центров сертификации. Planning validity periods Microsoft поддерживает два типа центров сертификации — Standalone и Enterprise. Обычно администраторы привыкли устанавливать Enterprise CA и по очевидным причинам не используют Standalone CA.

    Чем они отличаются?

  • ACL
  • Server Backup
  • EFS у нас в домене развернут сервер сертификатов, сочетающий в себе все функции, в том числе root ca. Устанавливался когда-то давно неизвестно кем, судя по всему, next-next'ом и использовался в исключительно для выдачи сертификатов на шифрование почты. Я так понимаю, если я вывожу его из домена и пытаюсь менять структуру на двухкомпонетную, все ранее выданные сертификаты становятся недействительными? И стоит ли заморачиваться этой процедурой, или проще поднять все заново, по-человечески настроив? Оставить все как есть нельзя, т. планируется расширение функционала службы сертификации (в том числе - распространение на филиалы).
  • Certificate Authority
  • Former blog / Vadims Podāns
  • 31. 2010 12:07 (GMT+3)
  • Устанавливаем Certification Authority (часть 1) — Введение
  • Digital Signatures pgarmashov
  • 11.

    2010 15:03 (GMT+3)

  • Устанавливаем Certification Authority (часть 1) — Введение Что значит "старший"? Это корневой или ниже корня? Корневой сертификат, как я и говорил не подлежит стандартному методу отзыва. И его аннулирование — крайне нетривиальная операция и зачастую это невозможно сделать полностью. его надо вручную удалять из контейнера Trusted Root CAs. Если в домене это относительно просто, то с недоменными клиентами будет ещё хуже.

    Безусловно, аннулирование (отзыв) любого сертификата CA влечёт автоматическое аннулирование всех сертификатов в его цепочке. В случае аннулирования корневого сертификата, все сертификаты в его цепочке будут недействительны, поскольку этот корневой сертификат не является доверенным. Это одна из причин, почему корневые CA нуждаются в особенной защите. 2010 12:26 (GMT+3)

  • Устанавливаем Certification Authority (часть 1) — Введение Я бы не думал отчаянно отчего у меня авторегистрация не отрабатывает как надо :).

  • CryptoAPI
  • Внедрение защищённой почты с шифрованием и/или подписью писем; действительно, я заходил под локальным админом. Устанавливаем Certification Authority (часть 1) — Введение - PKI Extensions
  • Домен Adatum. Com содержит сервер способный выполнять роль OCSP Responder'а.

    Если это будет Windows Server, требования к версии будут такие же, как и для Enterprise CA.

    Windows Server 2008 R2 Standard/Enterprise/Datacenter или Windows Server 2008 Enterprise/Datacenter. All rights reserved Большое спасибо! ;) > Что он теперь может сделать (помимо выдачи липовых сертификатов, естественно)?

  • WMI Permalink | Comments (12) Про Conclusion - 4.

  • PS PKI Module
  • Windows PKI team Blogroll Так же можно предусмотреть использование OCSP ( Online Certificate Status Protocol). Хоть обычно OCSP и используется только для Enterprise CA, ничего не мешает использовать его для корневого CA. С учётом роста количества клиентов под управлением Windows Vista и выше, это будет хороший экспериенс и я расскажу, как это можно будет реализовать.

    Conclusion

  • Shares хотелось задать такой вопрос - предположим в системе есть только один сервер сертификации, кто-то его взломал.
  • PowerShell Team Blog
  • OCSP
  • Scripting Games
  • PowerShell V2 Я считаю, что старый CA следует декомиссовать: http://support.

    Com/kb/889250 По своим возможностям Standalone CA выглядит убогим чуть более, чем полностью. Но этот тип CA имеет одно сильное преимущество — он не зависит от наличия домена.

    Домены даже рулят и педалят и всё, что работает без домена не нужно! Но давайте посмотрим на ситуацию немного с другой стороны. Центры сертификации верхних уровней (корневые и подчинённые центры сертификации первого уровня) имеют как правило очень большой срок действия — от 10 до 20 лет. При этом очень часто домены и леса AD живут значительно меньше, поскольку они постоянно реструктуирутся, переименовываются, мигрируются и т. А центр сертификации в домене (Enteprprise CA) лишает нас некоторых возможностей, как переименование домена и усложняют процессы реструктуризации доменов и лесов. По этой причине, Enterprise CA имеет небольшой срок действия своих сертификатов — от 5 до 10 лет максимум.

    В принципе, если есть независимый от домена AD центр сертификации (Standalone CA в рабочей группе) гораздо проще проводить миграцию и реструризацию лесов AD, поскольку эти процессы не затрагивают корневой CA и избавляют от проблем построения новой иерархии PKI. В такой ситуации достаточно только сменить центры сертификации 2-го и 3-го уровней (последний обычно является Enterprise CA). Именно по этой причине корневые центры сертификаций целесообразно устанавливать вне домена, в рабочей группе.

    На этом я заканчиваю вводную часть и в следующих частях мы поговорим уже о непосредственной установке и конфигурировании центров сертификаций. Возможно ли использовать для standalone root CA windows 2003, а для Enterprise Policy/Issuing CA windows 2008 R2? в первую очередь спасибо за ликбез )

  • Windows Server 2008/2008 R2 Standard Edition. и можно еще вопрос? Исходя из вышесказанного мы можем сформулировать программные требования для нашей иерархии PKI: При попытке поднять enterprise CA мне недоступна к выбору опция enterprise CA(затемнена), доступна только standlaone.

    Компьютер является членом рабочей группы WORKGROUP, с именем хоста RootCA. Компьютер не подключен к локальной сети или к интернетам. В принципе, для это задачи можно использовать и Enterprise/Datacenter редакции, но от них вы никакого профита не получите в случае использования роли ADCS ( Active Directory Certificate Services).

    Редакции Standard хватит вполне. В остальном - пожалуй, это один из лучших гайдов по сборке PKI на Windows :)

  • Домен Adatum. Com содержит выделенный веб-сервер под управлением любой ОС и который доступен из интернета (только для обслуживания внешних клиентов).

    и еще - если скомпрометирован "старший сертификат", после этого заменен - значит ли это что необходимо заменять все клиентские сертификаты (для чтения зашифрованной почти, например)? Во-первых, нужно определиться с задачами, которые могут потребовать внедрения PKI:

  • Standalone
  • PowerShell V3
  • DasBlog Да, можно. Версия ОС, под которой работает CA может быть любой даже non-Windows. Просто я отмечал, что отдельно по 2003 ничего не буду писать, т. новые инсталляции на нём уже очень мало делают.
  • Smart Cards Contents of this directory is archived and no longer updated.

  • Устанавливаем Certification Authority (часть 1) — Введение Протупил, однако :)
  • Chaining Engine Однако, зависимость от домена вносит некоторые ограничения в свою жизнь. Поскольку домены достаточно подвижные единицы и подвержены изменениям, Enterprise CA имеют достаточно короткий срок действия своих сертификатов — от 5 до 10 лет максимум. В случае Enterprise Root CA, удаление домена автоматически ведёт к краху всей иерархии PKI и её придётся строить с нуля, что может вылиться в большие трудности в довесок к текущим проблемам удаления домена.

    Именно поэтому компании никогда не устанавливают корневой центр сертификации на Enterprise CA, а только Issuing CA, которые уже издают сертификаты конечным потребителям, где и восстребованы все возможности Enterprise CA. Хотя, в очень небольших компаниях этого будет вполне достаточно, когда корневой CA устанавливается на Enterprise CA и имеет срок действия сертификата 5 лет.

  • Autoenrollment lordgraill.

    2010 09:40 (GMT+3)

  • Устанавливаем Certification Authority (часть 1) — Введение Если http://www. Com/windowsserver2008/en/us/r2-compare-roles.

    Aspx не врут, то OCSP на 2008 R2 Standard запустить не удастся (хотя мне никогда не приходило в голову это проверять, возможно, что ограничение исключительно лицензионное).

  • Decrypt my World В принципе, если сеть достаточно сконцентрирована, такая схема будет идеальной для многих случаев. А если сеть географически распределена с крупными филиалами (сайтами), в каждый такой филиал можно добавить по ещё одному сертификату CA и получить вот такую схему: alexiszp.

    2010 12:49 (GMT+3)

  • Устанавливаем Certification Authority (часть 1) — Введение alexiszp. 2010 17:48 (GMT+3)
  • Устанавливаем Certification Authority (часть 1) — Введение Одной из самых больших проблем при внедрении PKI на предприятии является отсутствие навыков планирования и установки Certification Authority. Как я уже неоднократно отмечал, потребность в PKI возрастает с каждым днём, а вот понимания вопроса у людей не увеличивается.

    К чему это приводит? В лучшем случае это приводит к установке вида Next –> Next –> ????? –> PROFIT и последующей нетривиальной и болезненной переконфигурации инфраструктуры под бизнес-задачи. Но чаще это заканчивается смачным эпик-фейлом в виде абсолютно неработающей PKI

    . Вот один из примеров: Помогите установить и настроить службу сертификации.

    Пробояню себя ещё раз, сказав, что для многих планирование, установка и поддержка PKI кажется задачей не сложнее администрирования нотепада и укладывается по времени в промежуток обеденного перерыва. При этом они глубоко заблуждаются, поскольку даже книга Брайана Комара и Пола Адаре по PKI ( Windows Server® 2008 PKI and Certificate Security) не даёт полного и детального представления о работе PKI, хотя там ТЗ хватит на не один год. В реальности для полного понимания материала ещё необходимо прочитать десяток вайтпеперов и всяческие RFC.

    Я не претендую на попытку устранить этот пробел, поскольку это нереально, но стараюсь дать какие-то полезные понятия и какие-то другие вещи в соответствии с бест-практисами. PKI tasks Компьютер является членом домена Adatum. Com с именем хоста Issuing CA.

    Компьютер не должен держать роль контроллера домена.

    2010 19:44 (GMT+3) by Vadims Podāns |

  • Windows Server 2008 Enterprise/Datacenter или Windows Server 2008 R2 Standard/Enterprise/Datacenter. Что он теперь может сделать (помимо выдачи липовых сертификатов, естественно)? Prologue 1) вы залогонены под доменной учётной записью, а не под локальной. Характеризуются нетребовательностью к наличию домена Active Directory.

    Так же Standalone CA не использует шаблоны, следовательно вы не можете запрашивать сертификаты на таком CA через оснастку Certificates консоли MMC. Что означает, что вы не можете пользоваться функциями autoenrollment'а. Так же при выдаче сертификатов, Standalone CA не может автоматически публиковать сертификаты в свойства учётной записи пользователя или компьютера.

    Энролить сертификаты в Standalone CA можно только через Enrollment Web Pages, либо вручную генерируя запросы (файлы с расширением. Req) и отправляя их через оснастку CertSrv.

    Причём отправка запросов через оснастку CertSrv

    . Msc является новой возможностью в Windows Server 2008. В связи с этим необходимость в Enrollment Web Pages отпала совсем. 2010 13:10 (GMT+3)
  • Устанавливаем Certification Authority (часть 1) — Введение > и еще - если скомпрометирован "старший сертификат", после этого заменен - значит ли это что необходимо заменять все клиентские сертификаты (для чтения зашифрованной почти, например)?
  • CRL Distribution Points и Authority Information Access
  • Certificate chaining engine (CCE) и отзыв корневых сертификатов
  • Планирование расширений CDP и AIA
  • FCIV Vadims Podāns
  • 31. 2010 14:10 (GMT+3)
  • Устанавливаем Certification Authority (часть 1) — Введение По конфигурации, два сервера 2008R2, один контроллер домена, второй просто член домена без каких-либо ролей, на него я и пытаюсь установить enterprise CA. а больше ему ничего не надо делать.

    Достаточно выпускать поддельные сертификаты, которые будут идентифицировать поддельных пользователей.

    поддельные пользователи будут аутентифицироваться под логинами легитимных пользователей.

    2010 16:25 (GMT+3)

  • Устанавливаем Certification Authority (часть 1) — Введение
  • Ask the Directory Services team 2) Убедитесь, что ваша доменная учётная запись является членом группы Enterprise Admins.

    2010 18:22 (GMT+3)

  • Устанавливаем Certification Authority (часть 1) — Введение Мне бы раньше попасть на этот блог! Попробуем попорядку. Спасибо за инфу! Very usefull! Да, тут я оплошал, Standard не поддерживает OCSP. 2010: Windows Server 2008 R2 Standard не поддерживает роль OCSP Responder.

  • Tips & Tricks Что касается шифрования, тут есть другой момент, который зависит от самих приложений. Как приложения настроены на проверку отзыва, так они работать и будут.
  • Client Authentication
  • The Old New Thing Центр сертификации уровня предприятия (как это следует из названия) совершенно не похож на Standalone CA по своим возможностям.

    Во-первых Enterprise CA требует наличия домена для хранения там своей информации и шаблонов сертификатов. Данный тип CA имеет очень большие возможности по выдаче и обслуживанию сертификатов. Enterprise CA не требует генерации файлов запросов со стороны клиентов, а позволяет подавать заявки на сертификаты через оснастку Certificates консоли MMC и автоматически распространять сертификаты в масштабах целого леса AD при минимальном участии конечного пользователя.

    Чаще всего это участие сводится к настройке администратором политик autoenrollment'а и всё. Плюс, Enterprise CA может публиковать сертификаты в свойства учётных записей пользователей и компьютеров. Ссылки на другие материалы из этой серии:

  • Внедрение защищённых сетевых протоколов — L2TP, SSL, IPsec; Вадим, хотел уточнить.

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

    .

    2010 13:31 (GMT+3)

  • Устанавливаем Certification Authority (часть 1) — Введение В одном из своих предыдущих постов я вёл дискуссию об иерархиях PKI: Обсуждение схем иерархии Certification Authority. На основе этого материала мы подбеёрм схему для нашей инсталляции, которая будет описана в данном материале. Исходя из написанного по ссылке мы сразу отметаем вариант одноуровневой иерархии.

    Двухуровневая иерархия выглядит крайне привлекательно:

  • Устанавливаем Certification Authority — Подведение итогов понял, спасибо Добрый день, натолкнулся на Вашу статью, решил поднять свой уровень в плане сертификатов :) сорри за нубские вопросы
  • Внедрение защищённых механизмов аутентификации — смарт-карты, сертификаты для аутентификации в IIS/VPN; Categories: Security | PKI | Setup Исходя из описанного по ссылкам (читать обязательно!) мы полностью откажемся от LDAP-ссылок и в сертификатах будем публиковать только ссылки на HTTP. Для этой цели нам потребуется веб-сервер, который будет хранить наши CRL/CRT файлы и поддерживать работоспособность ссылок. Поскольку корневой CA не будет издавать сертификаты конечным потребителям, а только для других CA, риск компрометации которых невелик (но всё же существует) и он большую часть времени будет выключен, мы отключим публикацию Delta CRL для корневого CA, но включим для Issuing CA.

    Основной CRL (Base CRL) мы будем публиковать каждые 3 месяца для корневого сертификата и каждые 5 дней для Issuing CA. Для обеспечения более быстрой реакции на отзыв сертификатов, для Issuing CA будем публиковать Delta CRL каждые 12 часов. Убедитесь, что:

  • PKI На какой срок будем выдавать сертификаты для каждого типа CA? 20 лет мне кажется слишком круто, ведь через 20 лет в вашей компании может всё круто поменяться и если ваш бизнес не завязан на предоставлении услуг цифровых сертификатов, 20 лет, наверное, слишком большой срок.

    А вот 10 лет для корневого и издающего будет вполне достаточно. Не надо думать, что через 10 лет всё умрёт. Просто через 10 лет (фактически чуть раньше, через 8-9 лет) вам придётся обновить сертификаты обоих CA и всё, жизнь будет продолжаться дальше.

    Издержки на обновлении сертификатов CA минимальные, поскольку никаких изменений в конфигурации производить не придётся. Planning CDP/AIA extensions Вашу инструкцию заодно и сравниваю с пошаговым руководством от Microsoft по 2008 серверу(версия от апреля 2007). Если из всего вышеперечисленного вам не нужно, PKI вам не нужна так же.

    Planning CA hierarchy Об этом у меня написано уже достаточно много:

    .