Главная Security, Windows, Без рубрики, Новое Проектирования Инфраструктуры Открытых Ключей. Часть 2.
  • Проектирования Инфраструктуры Открытых Ключей. Часть 2.

    smime Мы говорим о потребности внедрения инфраструктуры PKI, когда речь идет о приложениях, требующих ее наличия. Что же это за приложения?

     

     

     

     

    Если нам необходимо

         · обеспечить неотрицание авторства (то есть добиться того, чтобы автор не мог отказаться от своей подписи), неизменность передаваемых по сети данных;

          · использовать технологий цифровой подписи;

          · обеспечить шифрование данных;

          · внедрить многофакторной аутентификацию,

          · реализовать VPN доступ;

          · решить задачи аутентификации в беспроводных сетях;

          · обеспечить конфиденциальность почтового обмена;

          · защитить код и т. д,

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

    Обладателями цифровых сертификатов могут являться: Пользователи, компьютеры, сетевые устройства и службы.

     

    Требования безопасности

    При разработке политики безопасности организации следует учитывать и требования, которые должны предъявляться к инфраструктуре PKI.

    Одним из ключевых аспектов защиты является обеспечение физической безопасности отключенных (Offline) Удостоверяющих Центров. Речь идет о Root и Policy CA. Обычно для этих целей просто снимаются диски указанных серверов и помещаются в сейф.

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

         · Необходимо разместить серверы в специально отведенном для этих целей помещении, физический доступ в которое разрешен специально выделенному кругу лиц;

         · Не использовать совмещение ролей на таких серверах, так как это снижает безопасность системы.

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

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

    Технические требования

    Технические требования также оказывают влияние на архитектуру инфраструктуры открытых ключей. К техническим требованиям относятся:

         · Требования ролевого разделения пользователей на сервере сертификатов;

         · Требования к отказоустойчивости серверов;

         · Срок жизни сертификата открытого ключа;

         · Длина ключа;

         · Параметры публикации сертификата УЦ и списков отзыва сертификатов.

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

    Сервер сертификатов Windows 2008 предоставляет нам определенный набор стандартных ролей, которые могут быть нами использованы для делегирования полномочий.

        · CA Administrator – администратор УЦ. Обладание этой ролью предусматривает возможности по управлению конфигурацией УЦ, включая настройку параметров службы и назначение менеджеров сертификатов. Назначение этой роли осуществляется посредством назначения прав Manage CA на УЦ. Для этого откройте консоль сервера сертификатов «Start->Administrative Tools ->Certification Authority». Выберите требуемый УЦ, нажмите правую клавишу мыши и выберите пункт «Properties». В открывшемся окне перейдите на вкладку «Security» и добавьте в список группу, права которой вы делегируете. Назначьте ей право «Manage CA».

    См. рис 4.

    Рис. 4. Назначение роли CA Administrator

    clip_image002

        · Certificate Manager – пользователи, обладающие этой ролью, отвечают за управление сертификатами (выдача, отзыв, удаление). Кроме этого, у них есть возможность извлечения частного ключа при процедурах восстановления (функционал агентов восстановления ключей). Роль назначается с помощью задания разрешения «Issue and Manage Certificates» на УЦ. Чтобы это сделать, откройте консоль сервера сертификатов «Start->Administrative Tools ->Certification Authority». Выберите требуемый УЦ, нажмите правую клавишу мыши и выберите пункт «Properties». В открывшемся окне перейдите на вкладку «Security» и добавьте в список группу, права которой вы делегируете. Назначьте ей право «Issue and Manage Certificates».

    См. рис 5.

    Рис. 5. Назначение роли Certificate Manager

    clip_image004

        · Backup Operators. Роль этих пользователей – выполнение процедур резервного копирования и восстановления БД сервера сертификатов и его конфигурации. Назначение этих полномочий может быть осуществлено с помощью локальных или групповых политик (Backup files and directories, Restore file and directories). Для этого необходимо в консоли управления групповыми политиками GPMC [3] выбрать требуемый объект групповой политики раздел Computer Configuration->Windows Settings->Security Settings->Local Policies->User Rights Assignment->Backup up files and directories и добавить требуемую группу. См. рис. 6.

    См. рис 6.

    Рис. 7. Назначение роли Backup Operator

    clip_image006

         · Auditors – задача этой роли выполнение процедур аудита УЦ, назначение этой роли выполняется с помощью локальных или групповых политик (Manage Auditing and Security Logs). Этот также выполняется в консоли управления групповыми политиками. Откройте GPMC выберите требуемый объект групповой политики раздел Computer Configuration->Windows Settings->Security Settings->Local Policies->User Rights Assignment->Manage auditing and security log и добавьте требуемую группу. См. рис. 7.

    См. рис 7.

    Рис. 7. Назначение роли Auditors

    clip_image008

    Предусматривается возможность задания ролей индивидуально для каждого из УЦ. Windows 2008 дает возможность жесткого разделения ролей, то есть обладая одной ролью, теряется возможность обладания другой.

    При проектировании инфраструктуры PKI не следует забывать о надежности ее функционирования. Здесь мы можем рассмотреть решение на основе отказоустойчивого кластера серверов УЦ или, как более простой вариант, использовать отказоустойчивые дисковые массивы. Разумеется, требования к издающим online CA с точки зрения отказоустойчивости выше, чем к offline CA, где, в сущности, нам будет достаточно обычного резервного копирования. Это может быть выполнено как с помощью консоли управления сервера сертификатов (тогда речь идет о сохранении базы данных сервера, ключей и настроек службы), так и с помощью копирования встроенными средствами операционной системы (Windows Server Backup). В этом случае, может быть сохранена не только информация, относящаяся к функционированию PKI, а полностью все содержимое сервера).

    Срок жизни сертификата определяется его шаблоном. Изменение этого параметра после выдачи невозможно.

    При определении сроков жизни, следует иметь ввиду, что для выдаваемого сертификата недопустимо превышать срок жизни сертификата УЦ.

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

    При обновлении сертификата УЦ допустимо придерживаться двух стратегий:

         1. Сохранение исходного частного ключа на весь период жизни УЦ.

         2. Замена частного ключа при обновлении сертификата УЦ.

    Срок жизни корневого УЦ должен быть в два раза больше, чем у Policy CA.

    Например, RootCA – 20 лет, PolicyCA – 10 лет, IssuingCA – 5 лет.

    Не следует задавать срок жизни корневого CA более чем 20 лет, так как большие сроки увеличивают вероятность компрометации ключа.

    При выборе длины ключа, основным ограничивающим фактором являются возможности приложений по работе с ключом определенной длины. В любом случае для повышения уровня безопасности рекомендуется использовать длинные ключи. В частности MS-PKI поддерживает ключи до 4096 бит. Имеет смысл использовать ключи размером 4096 бит для RootCA и PolicyCA. Для IssuingCA в целях совместимости можно предложить использовать ключи длиной 2048 бит.

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

    Следует найти баланс требований безопасности с затратами на внедрение более защищенных решений. Положительные и отрицательные стороны того или иного варианта вы можете увидеть таблице. См. Рис. 8.

    Рис. 8. Выбор метода защиты частного ключа.

    clip_image010

    Последний раздел технических требований к инфраструктуре открытого ключа – расположение списков отзыва сертификатов (CRL) и сертификатов УЦ.

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

    · HTTP;

    · LDAP (обычно речь идет о Active Directory Domain Services);

    · FTP;

    · File share (SMB);

    Основными являются протоколы HTTP и LDAP, именно их следует рассматривать.

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

    Протокол LDAP предоставляет возможности поиска для клиентов AD. Таким образом, в основном речь идет о внутренних клиентах сети, так как если планируется предоставлять возможность внешним клиентам, использовать LDAP, то потребуется предоставить возможность выполнения LDAP запросов к службе каталога.

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

    Принимая решение о том, какой способ публикации выбрать, следует учесть:

    • необходимую частоту публикации,
    • возможности по прохождению через брандмауер,
    • используемую клиентом операционную систему.

    Наиболее часто используемый протокол должен быть помещен первым в списке, остальные в порядке частоты их применения.

    Бизнес требования

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

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

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

    Рассмотрим примеры таких ситуаций:

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

    Существуют различные решения для такого сценария.

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

         2. Использование сертификатов исходной организации при работе сотрудников в сторонней организации.

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

    Требования законодательства

    Если компания является транснациональной, то не исключен вариант, что требования к электронным цифровым сертификатам для разных стран различны, вследствие этого может потребоваться использовать различные PolicyCA и IssuingCA для каждой из стран.

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

    Выводы

    Итак, настало время подвести итоги.

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

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

     

    Список литературы

    [1] Brian Komar Windows Server 2008 PKI and Certificate Security

    [2] http://www.microsoft.com/pki

    [3] http://technet.microsoft.com/enus/magazine/2009.05.pki.aspx

    [4] http://www.windowsecurity.com/articles/MicrosoftPKIQuickGuidePart1.html

    [5] http://www.windowsecurity.com/articles/MicrosoftPKIQuickGuidePart2.html

    [6] http://www.verisign.com

    [3] Здесь и далее приводится пример назначения роли с помощью групповой политики, однако следует иметь в виду, что такое назначение роли выполняется также и с помощью политик локальных, действующих только на указанный сервер, что в ряде ситуаций является предпочтительным способом.

     

    Автор: Леонид Шапиро,

    MCT, MCSE:S, MCSE:M, MCITP EA, TMS Certified Trainer.

Комментарии

  1. Ну где же наш мега гуру alekseybb?

    2Леонид: Спасибо, будем читать, а то с практикой всё нормально, а вот с теорией…

  2. >Ну где же наш мега гуру alekseybb?

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

  3. Я тут давно не был, пробежался по его постам… Знаешь, если взять из них нужные 5% информации, я бы подписался под каждым словом… Жаль, что это всё утонуло в 95% ферментов…

  4. добавьте соли… ответьте пожалуйста на жизненный вопрос: возможно ли развернув внутренний УЦ, и НЕ настраивая кросс сертификацию пользоваться благами PKI и “не иметь проблем” во внешнем мире? 😉

  5. Увы, но нельзя. Хотя смотря что считать проблемой.

  6. Спасибо.
    а можно просьбу? постепенно раскрыть и рассказать больше технической информации.
    как происходит соединение, какие проверки, какие протоколы… и тд )
    а то постоянно используешь, а не понимаешь что и как работает. )

  7. xobbit, почитайте все что Поданс писал про PKI http://www.sysadmins.lv/CategoryView,category,SecurityPKI.aspx

    Очень качественная техническая информация человеческим языком.

  8. Мде, статья как-то внушает уныние. Во-первых, просто ошеломляющие ошибки:

    > использовать технологий цифровой подписи
    > внедрить многофакторной аутентификацию

    Плюс, есть трудности с пунктуацией. Далее, непонятен вот этот фрагмент:
    > См. рис 6.
    > Рис. 7. Назначение роли Backup Operator

    почему рисунок под номером 7 фигурирует 2 рза?

    > назначение этой роли выполняется с помощью локальных или групповых политик (Manage Auditing and Security Logs). Этот также выполняется в консоли управления групповыми политиками

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

    > Срок жизни сертификата определяется его шаблоном

    а вот это не совсем так. В шаблоне указывается лишь предполагаемый срок издаваемого сертификата, но не абсолютный. Рсшаривая ТЗ подскажу как вычисляется действительный срок. А реальный срок сертификата будет наименьший срок из:
    1) остаточного срока действия издающего CA
    2) значение ValidityPeriod в настройках CA
    3) значение из настроек шаблона.

    > Изменение этого параметра после выдачи невозможно.

    это что, шаблон нельзя менять или что?

    > При обновлении сертификата УЦ допустимо придерживаться двух стратегий

    это неверные стратегии, потому что иногда приходится обновлять сертификат CA с новой ключевой парой для разгрузки CRL’ов.

    > Срок жизни корневого УЦ должен быть в два раза больше, чем у Policy CA

    кто вам сказал такую чушь? Это максимум какая-то условная рекомендация, не более. Требования такого нет. Скажем, лично я делаю одинаковый срок действия как для корневого, так и Policy CA по практическим соображениям.

    > Имеет смысл использовать ключи размером 4096 бит для RootCA и PolicyCA. Для IssuingCA в целях совместимости можно предложить использовать ключи длиной 2048 бит

    тоже не совсем верно, поскольку такие хитрые приложения и устройства не могут проверять цепочки, где хоть один сертификат имеет длину ключа выше, чем 2048 бит. Т.е. если корень имеет 4кбит ключ — проверка сертификата будет фейлиться такими приложениями и девайсами.

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

    следует ли напоминать, что FTP и SMB более не поддерживаются? SMB поддерживается только для публикации файлов, но не для публикации в сертификат.

    > прежде чем клиент получит доступ к точке распространения, используя другой способ, пройдет 10 секунд

    если мне не изменяет память, то начиная с висты и выше уже 15 секунд на точку и 20 секунд на всю цепочку.

    > Наиболее часто используемый протокол должен быть помещен первым в списке, остальные в порядке частоты их применения

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

    > При этом оба центра сертификации подчинены одному корневому

    но разным Policy CA.

    и в комментариях Илья даёт неправильный ответ.
    > возможно ли развернув внутренний УЦ, и НЕ настраивая кросс сертификацию пользоваться благами PKI и «не иметь проблем» во внешнем мире?

    на самом деле это не так. Коммерческие CA предлагают именно такой сервис Managed CA.

    Итого. Статья написана наспех и крайне бездарно и не рекомендуется для использования где-либо.

  9. Итак, попробуем разобраться со всем по-порядку, рассмотрим претензии по-существу:
    Рис. 7 упоминается два раза. Это действительно опечатка, повтор подписи, однако, по сути, ни на что не влияет. Опечатки, полагаю, комментировать нет нужды. Впредь, постараюсь вычитывать текст внимательней. Спасибо.
    Скриншоты назначения ролей приводятся для того, чтобы проиллюстрировать, где именно осуществляется настройка, путь приводится дважды (хотя, разумеется, это повтор) по тем же соображениям. Цель – упростить нахождение настроек политики.
    Отсутствие рекомендации об использовании глобальных и или универсальных групп – мой ляп. Следовало указать.
    О сроках жизни сертификатов…
    Здесь речь идет вот о чем: Никто не утверждал, что модификация шаблонов не допускается – это не так, я говорю о том, что после выдачи сертификата, невозможно изменить его «validity period». Срок жизни сертификата предопределен и не может быть изменен после выдачи сертификата. Возможно, в тексте статьи я не акцентировал на этом внимание, и, видимо, из за этого произошло некое недопонимание того, что я имел в виду.
    Жесткого требования о двукратном превышении срока жизни сертификата корневого УЦ относительно Policy CA и Policy CA относительно Issuing CA нет, это рекомендация. Однако это «не какая-то условная рекомендация», она имеет обоснование.
    MS CA не может выдавать сертификаты, время жизни которых превышает время жизни сертификата самого удостоверяющего центра.
    Следовательно, у нашего УЦ должен оставаться достаточный срок жизни для того, чтобы выдавать сертификаты с требуемым сроком жизни.
    В этом смысле хорошим подходом является двукратное увеличение срока относительно срока жизни выдаваемых сертификатов. В дополнение следует обновлять сертификат УЦ по достижению половины его срока жизни.
    О длине ключа…
    Несомненно, существуют устройства и приложения, не понимающие ключей длиной выше 2048 бит, причем это касается любого сертификата в цепочке. В этом смысле наличие ключей 4096 бит – проблема, например для Cisco VPN 3000. Тем не менее, мне представляется, что рекомендацию об использовании длинных ключей это все-таки не отменяет. Да у нас есть ограничение и при проектировании, мы это должны учесть, т. е. если используются подобные устройства, то мы не будем делать ключ корневого УЦ длиной свыше 2048.
    О времени проверки…
    Не готов сейчас ответить. Надо уточнить.

  10. > Скриншоты назначения ролей приводятся для того, чтобы проиллюстрировать, где именно осуществляется настройка, путь приводится дважды

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

    > Возможно, в тексте статьи я не акцентировал на этом внимание, и, видимо, из за этого произошло некое недопонимание того, что я имел в виду.

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

    > Однако это «не какая-то условная рекомендация», она имеет обоснование.

    Я когда-то тоже так думал, что это обязательное условие. Однако, со временем понял, что во многих случаях можно (а иногда и полезно) не соблюдать эту рекомендацию. Но если у вас есть годные мысли по этому поводу, я готов выслушать.

    > MS CA не может выдавать сертификаты, время жизни которых превышает время жизни сертификата самого удостоверяющего центра

    да, именно так. Но вы этот момент упустили. Кстати говоря, это достаточно распространённая ошибка, когда администраторы думают, что значение в шаблоне — абсолютное значение и начинают доставлять кирпичи, когда срок у сертификата не такой, как указано в шаблоне. Именно поэтому в этом моменте нужно обязательно делать сноску и уточнять этот момент. И если срок действия сертификата CA — ещё можно догадаться, то про ValidityPeriod мало кто знает или вспоминает вообще. Особенно это актуально на Standalone CA. И об этом стоило бы рассказать в статье, а не комментариях.

    > В этом смысле хорошим подходом является двукратное увеличение срока относительно срока жизни выдаваемых сертификатов

    ну с этим пунктом я не спорил.

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

    чаще всего вы ещё долго не будете делать ключ длиннее 2048 бит. Потому что даже новенький системцентер тоже не любит ключи 4096 бит и выше. Иными словами в 90% случаев это будет именно так и для корневых CA длина ключа будет 2048 бит.

    > Не готов сейчас ответить.

    а я уже подсмотрел, 15 секунд на первую и 20 на всю цепочку. Это по умолчанию для висты и более новых систем (опция настраиваемая). И что касается типов ссылок в CDP/AIA я придерживаюсь единой стратегии — только HTTP ссылки. Хотя можно разводить условности и говорить, что если PKI сугубо приватная (без возможности использования сертификатов извне сети), можно использовать LDAP или когда у нас есть 2 и более издающих CA, один можно выделить под внешние сертификаты и использовать HTTP, а другой CA выделить под внутренние сертификаты и там использовать LDAP. Но в реальной жизни это не доставляет положительных моментов, поэтому для упрощения всегда и везде используется HTTP.

  11. И все таки Вадим зануда)

    ————————————-
    кто вам сказал такую чушь? Это максимум какая-то условная рекомендация, не более. Требования такого нет. Скажем, лично я делаю одинаковый срок действия как для корневого, так и Policy 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 лет. Но основной отправной точкой будет требования к сроку действия конечных сертификатов.

  12. > И все таки Вадим зануда

    можете считать как хотите.

    > Но обычно используется простая схема

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