В связи с приказом ФНС № ММ-7-6/353@ необходимо перерегистрировать всех ранее зарегистрированных пользователей УЦ. Как можно автоматизировать процесс плановой замены ключей налогоплательщиков?

До этого налогоплательщик на своем рабочем месте генерировал ключи, формировал подписанный действующем ключом запрос на сертификат и отправлял в УЦ. УЦ обрабатывал этот запрос стандартными средствами ПАК «КриптоПро УЦ» и высылал налогоплательщику сертификат. Все это происходило удаленно без оформления документов на бумаге (только копии сертификата распечатывались).

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

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

По теме: наш УЦ будет делать именно так, как предлагает dedov

Не по теме:
Лень создавать новую тему. Спрошу здесь.
Имеется два АРМ для генерации ключей, которые находятся на разных этажах. Все политики УЦ изменяются удаленно с АРМ. В ближайшем времени грядет плановая массовая перегенерация ключей. В зависимости от ситуации ключи генерятся с различными политиками. Когда объем работы не большой, то справляется один АРМ, т.е. выставляешь нужные политики и генеришь ключ. Сейчас будет необходимость генерить порядка 100ключей в день с различными политиками, т.е. необходимо задействовать второй АРМ, т.к. один справляться с таким объемом не будет. Проблема заключается в следующем: как двум АРМ-мам не мешать друг другу работать? Объясню на примере: АРМ-ы находятся на разных этажах. Необходимо сделать ключ на 1-ом АРМ. Инженер 1-АРМ выставляет нужные себе политики и начинает вносить информацию о владельце ключа. В это время на 2-ой АРМ садится другой инженер, ему так же необходимо сделать ключ, но с другой политикой. Он ее меняет на нужную и, естественно, 1-ый инженер об этом не подозревает и продолжает делать свой ключ. Вариантов 2: либо первый инженер на 1-ом АРМ сдает не правильный ключ (не с той политикой), либо он его вообще не сделает.
Можно ли как либо этого избежать? Не существует ли какого либо средства, которой способно определять в режиме реального времени какие настройки на УЦ? Т.е. стоит один набор политик - горит "красная лампочка", набор политик изменили - лампочка сразу "загорелась синим" цветом. Т.е. необходимо реализовать способ оповещения инженера, сидящего за АРМ, о том, что настройки УЦ поменялись не подключаясь удаленно к самому УЦ. Надеюсь объяснил понятно))

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

У нас всего один шаблон и именно в нем мы и меняем политики (ставим необходимые галочки)

Ок! Спасибо! На этой неделе попробуем.

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