| ||||
| ||||
| Добрый день! Вопрос1: В процессе начальной установки ЦС (от Microsoft) во время формирования сертификата ЦС при выборе крипто-провайдера кроме всего прочего можно выбрать алгоритм хэширования (для КриптоПро доступны GOST 34.11-94 и GOST 28147-89). Вопрос заключается в следующем: на что влияет выбор этого параметра, какое значение является предпочтительным (в случае использования КриптоПро) и почему? Вопрос2: предположим у меня есть ЦС (для простоты - корневой) и веб-сервер, настроенный на обслуживание клиентов, имеющих сертификаты, выданные только этим ЦС. Как известно, при обращении клиента с сертификатом, сервер проверят по CRL не был ли сертификат клиента отозван, и если он (сервер) не может получить соответсвующий CRL, то запрос клиента отвергается, исходя из пессимистического предположения, что ЦС был взломан. Теперь предположим, что пришло время менять закрытый ключ ЦС. Я естественно хочу, не причиняя лишних неудобств старым клиентам, плавно перевести систему на использование нового сертификата ЦС (ФАПСИ рекомендует производить замену клиентских сертификатов раз в год) - новые сертификаты подписывать новым сертификатом ЦС, и продолжать обслуживать клиентов со старыми сертификатами. Проблема заключается в том, что при обновлении сертификата ЦС, формируется новый CRL этого ЦС. Таким образом, после истечения срока действия старого CRL, старые сертификаты ни прикаких условиях не будут приниматься веб-серввером, поскольку обновить старый CRL будет уже некому. Отсюда вытекает, что за время, пока старый CRL еще действует, я должен обновить сертификаты всех старых клиентов. Внимание, вопрос. Существует ли менее радикальное решение описанной задачи (обновление сертификата ЦС), которое было бы прозрачно для всех клиентов. Т.е. для старых клиентов переход на новый сертификат ЦС происходил бы во время плановой замены их сертификатов. Замечание: реальный срок действия сертификата ЦС в данном случае не является ограничением на использование сертификатов, выданных этим ЦС, поскольку я изначально могу выбрать его с запасом в один год, в течение которого сроки действия всех старых сертификатов истекут (по регламенту системы клиенты должны обновлять свои сертификаты раз в год). Заранее спасибо за ответы! | ||||
| Ответы: | ||||
| ||||
| GOST 34.11-94 - это алгоритм хеширования, который используется при создании ЭЦП. GOST 28147-89 - это алгоритм шифрования, в котором есть имитозащита. Так получается что имитозащита видна в этом списке алгоритмов. Пользовать ее нельзя. К подписи она не имеет никакого отношения. Что касается плановой смены ключей. 1. Посмотрите во встроенном хелпе микрософтовского центра описаны алгоритмы плановой смены. 2. Обратите внимание. Сертификаты пользователей не могут быть по срокам больше чем сертификат центра. Даже если у сертификата центра остался один день жизни, сертификат пользователя будет на один день. таком образом нельзя сделать пользователя центра, который останется безхозный. | ||||
Андрей Костоусов (СКБ Контур)