Список oidов улучшенного ключа файла запроса не совпадает со списком oidов заявки
Прошу прощения, сам понимаю что вопрос глупый, но 3 дня никак не могу разобраться:
Есть несколько серверов Exchange 2010, добавил новый CAS-сервер, хочу создать для него сертификат.
Все сервера работают под win 2008 r2.
Получаю файл запроса .req и отложенный запрос подписи сертификата для данного сервера. Дальше, я так понимаю, надо этот .req-файл передать центру сертификации (другой win-хост), чтобы он его подтвердил и выдал мне файл-.cer.
Команда как я понял должна быть наподобие: certreq -submit c:\cert_01.req cert_01.cer
И потом этот cer-файл я отдаю опять Exchange-серверу, и он выполнит запрос.
Однако, certreq возвращает ошибку:
Не могу понять, то ли проблема с самим ЦС, то ли я какие-то данные в сертификате некорректно заполнил, то ли я еще что-то неправильно делаю.
Answers
Сам когда-то столкнулся с подобной "фичей", благо помог один хороший человек Vadims Podans. Пробуем.
The Exchange 2010 wizard creates the request in a Unicode file. Certificate Services only understands Ansi. You have to open the request file in Notepad and then Save As specifying Ansi encoding. Then it works.
Actually it doesn’t work, but you get a more intelligible error. When you submit the request using certreq you have to specify a template by adding the argument:
All replies
Скорее всего, в службе сертификации настроена политика, требующая выдачи сертификатов администратором вручную (например, для изолированного центра сертификации она настроена по умолчанию).
В таком случае запустите оснастку центра сертификации, выдайте сертификат вручную и запишите идентификатор сертификата.
Сохранить сертификат на сервере Exchange в указнный в предыдущей команде файл можно командой
Скорее всего, в службе сертификации настроена политика, требующая выдачи сертификатов администратором вручную (например, для изолированного центра сертификации она настроена по умолчанию).
В таком случае запустите оснастку центра сертификации, выдайте сертификат вручную и запишите идентификатор сертификата.
Сохранить сертификат на сервере Exchange в указнный в предыдущей команде файл можно командой
certreq - retrieve cert_01.cer
Слава России!
Да, в последних экспериментах я ставил как раз изолированный центр сертификации, получил ту же ошибку, никаких политик относительно выдачи вручную конечно не настраивал.
А можно поподробнее, я не совсем понял, что именно надо сделать:
Т.е. я выдаю сертификат средствами графической консоли Exchange, он мне выкладывает req-файл, это не нужно? Я должен выдать сертификат прямо сразу на сервере ЦС, а консоль Exchange мне не нужна, а понадобится только в последний момент, для импорта? А какой тогда шаблон сертификата на сервере ЦС выбрать? Если я в свойствах своего ЦС выбираю пункт "Выдать новый запрос", выбираю свой req-файл, то окошко просто закрывается, и дальше ничего не происходит.
И что такое идентификатор сертификата? Я нашел в свойствах сертификата только идентификатор ключа субъекта, это не то?
Beast2040 пишет: Для ЕСИА в СУФД еще не делал, но разницы м/у АРМ и СУФД нет, кроме дублирующих OIDов в заявке.
Всегда писал ФИО в поле ФИО, а название организации в поле Организация, а также заполнял КПП и ОГРН и СНИЛС.
В таком случае получается не правильный сертификат, в поле CN будет ФИО, а должно быть наименование ЮЛ. Все эти траблы с сертификатами, потому что нет нормального софта для генерации, где четко требовало что заполнять
shaburoff пишет: В СУФД генерили заявки? Если да, то в поле ФИО пишем наименование ЮЛ? Меня просто смутила распечатка заявки там нет упоминания о руководителе, не фио, не должности. В АРМ ГК есть, толи в нём делать?
Тоже пока не приходилось генерить в СУФД. Если очень жмет - попробуй сгенерить "экспериментальный" на ЮЛ (без регистрации запроса в WebHandler) и посмотри в req-файле поля CN и SN. Методом научного тыка и поймешь что где вписывать надо при генерации в СУФД. Ну и может поделишься полученным знанием, полезным для всех заинтересованных. Я бы сам так и сделал, будь на работе, а не в отпуске (типа).
shaburoff пишет: В таком случае получается не правильный сертификат
Если бы он был неправильный, то работать под ним не получалось. А так все очень даже неплохо работатет
Alex_04 пишет: В связи с этим пришлось повозиться с картинками скринов из СУФД, связав их текстом с пояснениями в "Порядок генерации КСКП ФЛ для СУФД и ЕИС в ППО "СУФД-online".
В вашей инструкции написано что не нужно ставить КПП / ОГРН для ЭП физ лица
А где это написано? В приказе 27н я что то не увидел
Наверно в законе Об электронной подписи № 63-ФЗ ст.17. Там не сказано, что не надо заполнять, но там сказано, что нужно заполнять
Верней, что должен содержать сертификат ЭП.
СУФД версии 7.69.15 - 7.270.91 (027.032.700T05).
В req-файле запроса на сертификат ЭП роли полномочий АСФК сохраняются - исправили, эт хорошо. НО вылезло другое - поле со значениями СНИЛС и ИНН формируется некорректно:
1.2.372.980001.8.4.1: СНИЛС=04113841106,ИНН=450400455703
1.2.372.980001.8.4.1: СНИЛС=04113841106;ИНН=450400455703
Не сразу заметил разницу - разделитель значений СНИЛС и ИНН " , " вместо " ; " как в req-файле из АРМ ГК !
В новый WebHandler такой файл запроса принимается без проблем, как ни странно, но при загрузке его в ВРС выходит ошибка:
"Формат запроса на сертификат некорректен".
1. Не заполнен обязательный атрибут "ИНН"
2. Атрибут "СНИЛС" должен быть длиной 11
3. Атрибут "СНИЛС" должен состоять только из цифр
Народ, это только нам так "повезло" или у всех такое же счастье?
По данной ошибке собираюсь создавать обращение в СУЭ для эскалации его в ЦАФК и передачи разработчикам ППО СУФД. Поэтому важно знать (как можно оперативней) ваши отзывы, чтобы не поднимать лишнюю волну в случае "локальной" причины.
Alex_04 пишет: важно знать (как можно оперативней) ваши отзывы,
Alex67 пишет: Достаточно
одной таблэткиодного средства создания запроса.
Идём к этому 7-мильными шагами, а пока.
Клиенты генерят запроса в СУФД версии 7.283.47+fix1 (028.321.700t02). Видимо в выходные её поставили, ибо на прошлой неделе былов сё ОК, а с понедельника такое.
1. В генераторе запроса на серт ЭП на третьей строчке появилось следующее:
Запрос на сертификат Индивидуального предпринимателя
Если не ошибаюсь, этого пока нет ни в ВРС, ни в ФЗС - СУФД впереди их всех?
2. При генерации запроса из IE и FF любой версии, без или с КриптоПро ЭЦП Browser plug-in тоже любой версии если отмечены роли ЕИС (любые) при переходе на следующий этап для заполнения полей о владельце выходит ошибка:
No enum constant
com.otr.sufd.webapp.admin.crypto.request.AbstractCryptoRequestController.FIELD_PROP_NAME.SPZ_CODE
Дальше продолжать генерить после такого приветствия не рискнули. Сгенерили в старом добром АРМ ГК-44n.
АРМ ГК - наше всё и наше навсегда!
Alex_04 пишет: если отмечены роли ЕИС (любые) при переходе на следующий этап для заполнения полей о владельце выходит ошибка:
No enum constant
com.otr.sufd.webapp.admin.crypto.request.AbstractCryptoRequestController.FIELD_PROP_NAME.SPZ_CODE
Вы всё ещё кипятите? (с)
Полномочия ЕИС уже выпилены из ВРС и ФЗС чуть менее чем полностью, да и таблицу PROP_NAME.SPZ_CODE видно в СУФД просто очистили, (на что намекает текст ошибки), забыв подлатать интерфейс.
Конечно, заявители желающие иметь пяток халявных сертификатов на одно лицо заказчик - контроль - монтроль - надзор и так далее могут упасть в обморок, ну так обмахивайте их распечаткой 27н для обеспечения притока свежего воздуха.
Единственный (пока) случай второго сертификата заявителя на тоже лицо это "ГМУ отдельно" - вспоминаем ВКС посвященную новой версии регламента уц
Alex67 пишет: Полномочия ЕИС уже выпилены из ВРС и ФЗС чуть менее чем полностью
Да, читал на форумах уже об этом. Но вот остались 2 последних клиента по обмену сертов до 28.06, которым надо чтоб были роли ЕИС, "как положено" по их приказам.
Тогда уж и в генераторе СУФД бы вырезали блок "ЕИС" ко всем чертям и всё - типа баста, забудьте все о них и точка.
заявители желающие иметь пяток халявных сертификатов на одно лицо заказчик - контроль - монтроль - надзор и так далее могут упасть в обморок
Не, у нас райФО наоборот: всеми конечностями были против ведра ключей для ЕИС от разных кабинетов и только "за" один "универсальный" ко всем дверям.
Alex67 пишет: таблицу PROP_NAME.SPZ_CODE видно в СУФД просто очистили, (на что намекает текст ошибки), забыв подлатать интерфейс.
Да, но ради ясности enum это перечисление констант, а не таблица. Константу убрали/переименовали, а обращение к ней - нет. Теоретически может привести к неожиданным последствиям, если на это значение добавят новое имя константы.
Alex67 пишет: Конечно, заявители желающие иметь пяток халявных сертификатов на одно лицо
Халява конечно хорошо, но еще "не все УЦ одинаково полезны". Хоть и хотелось бы один сертификат, но некоторые оиды УЦ ФК просто не выдает (для СМЭВ), не выдаются сертификаты ЮЛ (с огрн) с указанным ФИО/снилс неруководителя (для ФИАС). Согласен, что это неправильно, но ФНС требуют. С "защитой электронной почты" и "аутентификации сервера" тоже все плохо (к слову, случайно попался только один отечественный УЦ с реально рабочей "защитой электронной почты", остальные тоже только ставят роль). "Связка ключей" у пользователя остается, даже если у человека от ФК будет только 1 сертификат.
Alex67 пишет: "ГМУ отдельно" - вспоминаем ВКС
Вау! Оказывается элементарно забыв при генерации о ГМУ, и сгенерив второй запрос только на ГМУ, я оказался идущим в ногу со временем.
two_oceans пишет: я оказался идущим
с не в ногу со временем мелко шагающими разрабами ПО ГМУ. Лучше бы убрали с главной страницы сайта ГМУ в отдельный раздел все "весёлые картинки" с диаграммами и т.п., из-за которых недостаточные сильные компы пользователей (а их ещё очень немало) еле-еле открывают её.
Alex_04 пишет: Лучше бы убрали с главной страницы сайта ГМУ в отдельный раздел все "весёлые картинки" с диаграммами и т.п., из-за которых недостаточные сильные компы пользователей (а их ещё очень немало) еле-еле открывают её.
Alex_04 пишет: Лучше бы убрали с главной страницы сайта ГМУ в отдельный раздел все "весёлые картинки" с диаграммами и т.п., из-за которых недостаточные сильные компы пользователей (а их ещё очень немало) еле-еле открывают её.
Соглашусь, однако ничего не мешает убрать "веселые картинки" самим, ведь главная страница в обычном http, без шифрования. Например, по умолчанию отключить отображение картинок в браузере либо задать свой "стиль пользователя" и включить его по умолчанию. Также это можно сделать централизованно различными прокси и банерорезками.
Beast2040 пишет: Для ЕСИА в СУФД еще не делал, но разницы м/у АРМ и СУФД нет, кроме дублирующих OIDов в заявке.
Всегда писал ФИО в поле ФИО, а название организации в поле Организация, а также заполнял КПП и ОГРН и СНИЛС.
В таком случае получается не правильный сертификат, в поле CN будет ФИО, а должно быть наименование ЮЛ. Все эти траблы с сертификатами, потому что нет нормального софта для генерации, где четко требовало что заполнять
shaburoff пишет: В СУФД генерили заявки? Если да, то в поле ФИО пишем наименование ЮЛ? Меня просто смутила распечатка заявки там нет упоминания о руководителе, не фио, не должности. В АРМ ГК есть, толи в нём делать?
Тоже пока не приходилось генерить в СУФД. Если очень жмет - попробуй сгенерить "экспериментальный" на ЮЛ (без регистрации запроса в WebHandler) и посмотри в req-файле поля CN и SN. Методом научного тыка и поймешь что где вписывать надо при генерации в СУФД. Ну и может поделишься полученным знанием, полезным для всех заинтересованных. Я бы сам так и сделал, будь на работе, а не в отпуске (типа).
shaburoff пишет: В таком случае получается не правильный сертификат
Если бы он был неправильный, то работать под ним не получалось. А так все очень даже неплохо работатет
Alex_04 пишет: В связи с этим пришлось повозиться с картинками скринов из СУФД, связав их текстом с пояснениями в "Порядок генерации КСКП ФЛ для СУФД и ЕИС в ППО "СУФД-online".
В вашей инструкции написано что не нужно ставить КПП / ОГРН для ЭП физ лица
А где это написано? В приказе 27н я что то не увидел
Наверно в законе Об электронной подписи № 63-ФЗ ст.17. Там не сказано, что не надо заполнять, но там сказано, что нужно заполнять
Верней, что должен содержать сертификат ЭП.
СУФД версии 7.69.15 - 7.270.91 (027.032.700T05).
В req-файле запроса на сертификат ЭП роли полномочий АСФК сохраняются - исправили, эт хорошо. НО вылезло другое - поле со значениями СНИЛС и ИНН формируется некорректно:
1.2.372.980001.8.4.1: СНИЛС=04113841106,ИНН=450400455703
1.2.372.980001.8.4.1: СНИЛС=04113841106;ИНН=450400455703
Не сразу заметил разницу - разделитель значений СНИЛС и ИНН " , " вместо " ; " как в req-файле из АРМ ГК !
В новый WebHandler такой файл запроса принимается без проблем, как ни странно, но при загрузке его в ВРС выходит ошибка:
"Формат запроса на сертификат некорректен".
1. Не заполнен обязательный атрибут "ИНН"
2. Атрибут "СНИЛС" должен быть длиной 11
3. Атрибут "СНИЛС" должен состоять только из цифр
Народ, это только нам так "повезло" или у всех такое же счастье?
По данной ошибке собираюсь создавать обращение в СУЭ для эскалации его в ЦАФК и передачи разработчикам ППО СУФД. Поэтому важно знать (как можно оперативней) ваши отзывы, чтобы не поднимать лишнюю волну в случае "локальной" причины.
Alex_04 пишет: важно знать (как можно оперативней) ваши отзывы,
Alex67 пишет: Достаточно
одной таблэткиодного средства создания запроса.
Идём к этому 7-мильными шагами, а пока.
Клиенты генерят запроса в СУФД версии 7.283.47+fix1 (028.321.700t02). Видимо в выходные её поставили, ибо на прошлой неделе былов сё ОК, а с понедельника такое.
1. В генераторе запроса на серт ЭП на третьей строчке появилось следующее:
Запрос на сертификат Индивидуального предпринимателя
Если не ошибаюсь, этого пока нет ни в ВРС, ни в ФЗС - СУФД впереди их всех?
2. При генерации запроса из IE и FF любой версии, без или с КриптоПро ЭЦП Browser plug-in тоже любой версии если отмечены роли ЕИС (любые) при переходе на следующий этап для заполнения полей о владельце выходит ошибка:
No enum constant
com.otr.sufd.webapp.admin.crypto.request.AbstractCryptoRequestController.FIELD_PROP_NAME.SPZ_CODE
Дальше продолжать генерить после такого приветствия не рискнули. Сгенерили в старом добром АРМ ГК-44n.
АРМ ГК - наше всё и наше навсегда!
Alex_04 пишет: если отмечены роли ЕИС (любые) при переходе на следующий этап для заполнения полей о владельце выходит ошибка:
No enum constant
com.otr.sufd.webapp.admin.crypto.request.AbstractCryptoRequestController.FIELD_PROP_NAME.SPZ_CODE
Вы всё ещё кипятите? (с)
Полномочия ЕИС уже выпилены из ВРС и ФЗС чуть менее чем полностью, да и таблицу PROP_NAME.SPZ_CODE видно в СУФД просто очистили, (на что намекает текст ошибки), забыв подлатать интерфейс.
Конечно, заявители желающие иметь пяток халявных сертификатов на одно лицо заказчик - контроль - монтроль - надзор и так далее могут упасть в обморок, ну так обмахивайте их распечаткой 27н для обеспечения притока свежего воздуха.
Единственный (пока) случай второго сертификата заявителя на тоже лицо это "ГМУ отдельно" - вспоминаем ВКС посвященную новой версии регламента уц
Alex67 пишет: Полномочия ЕИС уже выпилены из ВРС и ФЗС чуть менее чем полностью
Да, читал на форумах уже об этом. Но вот остались 2 последних клиента по обмену сертов до 28.06, которым надо чтоб были роли ЕИС, "как положено" по их приказам.
Тогда уж и в генераторе СУФД бы вырезали блок "ЕИС" ко всем чертям и всё - типа баста, забудьте все о них и точка.
заявители желающие иметь пяток халявных сертификатов на одно лицо заказчик - контроль - монтроль - надзор и так далее могут упасть в обморок
Не, у нас райФО наоборот: всеми конечностями были против ведра ключей для ЕИС от разных кабинетов и только "за" один "универсальный" ко всем дверям.
Alex67 пишет: таблицу PROP_NAME.SPZ_CODE видно в СУФД просто очистили, (на что намекает текст ошибки), забыв подлатать интерфейс.
Да, но ради ясности enum это перечисление констант, а не таблица. Константу убрали/переименовали, а обращение к ней - нет. Теоретически может привести к неожиданным последствиям, если на это значение добавят новое имя константы.
Alex67 пишет: Конечно, заявители желающие иметь пяток халявных сертификатов на одно лицо
Халява конечно хорошо, но еще "не все УЦ одинаково полезны". Хоть и хотелось бы один сертификат, но некоторые оиды УЦ ФК просто не выдает (для СМЭВ), не выдаются сертификаты ЮЛ (с огрн) с указанным ФИО/снилс неруководителя (для ФИАС). Согласен, что это неправильно, но ФНС требуют. С "защитой электронной почты" и "аутентификации сервера" тоже все плохо (к слову, случайно попался только один отечественный УЦ с реально рабочей "защитой электронной почты", остальные тоже только ставят роль). "Связка ключей" у пользователя остается, даже если у человека от ФК будет только 1 сертификат.
Alex67 пишет: "ГМУ отдельно" - вспоминаем ВКС
Вау! Оказывается элементарно забыв при генерации о ГМУ, и сгенерив второй запрос только на ГМУ, я оказался идущим в ногу со временем.
two_oceans пишет: я оказался идущим
с не в ногу со временем мелко шагающими разрабами ПО ГМУ. Лучше бы убрали с главной страницы сайта ГМУ в отдельный раздел все "весёлые картинки" с диаграммами и т.п., из-за которых недостаточные сильные компы пользователей (а их ещё очень немало) еле-еле открывают её.
Alex_04 пишет: Лучше бы убрали с главной страницы сайта ГМУ в отдельный раздел все "весёлые картинки" с диаграммами и т.п., из-за которых недостаточные сильные компы пользователей (а их ещё очень немало) еле-еле открывают её.
Alex_04 пишет: Лучше бы убрали с главной страницы сайта ГМУ в отдельный раздел все "весёлые картинки" с диаграммами и т.п., из-за которых недостаточные сильные компы пользователей (а их ещё очень немало) еле-еле открывают её.
Соглашусь, однако ничего не мешает убрать "веселые картинки" самим, ведь главная страница в обычном http, без шифрования. Например, по умолчанию отключить отображение картинок в браузере либо задать свой "стиль пользователя" и включить его по умолчанию. Также это можно сделать централизованно различными прокси и банерорезками.
Получили 4 носителя для работы с ЕГАИС. На 3 носителя на одном и том же ПК были получены RSA ключи на сайте ЕГАИС без ошибок. На этом же ПК на один из носителей не удается записать ключ RSA, при запросе ключа страница ЕГАИС перестает отвечать. Светодиод на носителе постоянно моргает.
Сотрудники поддержки компании-поставщика проводили диагностику ключей, переустанавливали драйвера, запускали утилиту удаления ключей RSA, но ничего не изменилось.
Что ещё можно предпринять для устранения проблемы?
- Николай Киблицкий
- Техническая поддержка
- Неактивен
Данные для подключения направлены на адрес электронной почты.
Добрый день!
.
Что ещё можно предпринять для устранения проблемы?
В один и тот же день это было или разные?
Если разные то вы могли попасть не в то время.
Последний раз замечал генерация значительно дольше начинает работать, один раз 5-6 минут ждал ответа.
- Ксения Шаврова
- Администратор
- Неактивен
Сегодня был аналогичный случай и хорошо, что у нас RSA пытались получить.
Когда не смогли получить на месте где всё работало, проверили на другом т.к. сбою допустимы,
но на втором точно так же и дефект был точно не со стороны ЕГАИС.
Ключ был и сбой происходил когда уже производился последний "запрос" и обращение для генерации
закрытой части и в этот момент ключ "терялся" - т.е. он был, но на W7 показывал как буд то занят чем то.
В итоге я сказал выдать другой т.к. 80-90% клиент приедит и не чего не получит у себя.
Потому выдать новые и на 99% сразу поймём ключ это или нет, если RSA получим после,
то значит ключ, но как доказать - не попытками же получения RSA и не вдруг "поломкой"
работы клиента если отзовётся при этом прежний.
Исходя их всего этого - хотел запросить, нет ли тестовой утилиты запроса PKI, но не на ЕГАИС, а просто так?
- Ксения Шаврова
- Администратор
- Неактивен
Клиент 40 минут ждал и уже было не до проверок долгих. Были другие проблемы с УЦ, потому они уже хотели так с этим уйти. но бл что не ушли т.к. в тоге там помогали им переходить с Якарты на Рутокен и инет там стабильно падал, потому совсем было бы не приятно.
Olgerd » 02 сен 2020, 12:28
Кто по 44-ФЗ работает, тот в цирке не смеется. Закупки это не только работа, это ещё и квест: нам подкидывают препятствия, мы их преодолеваем. Преодолели? Внесение поправок в условия игры.
tumbb » 09 сен 2020, 12:41
Genadiy писал(а): На Win7, такая же проблема аналогичная уже второй день входим в личный кабинет а дальше fz-wf19.zakupki.local:8080/223/sso/esialogin, окошко что ничего у Вас не получится.
Ну, я думаю, коллега, Вы понимаете, что проблема не такая же, раз она у Вас только два дня. И, очевидно, Вы можете сопоставить недавний переезд ЕИС со своей проблемой.
отъехала :) . лс 223 - не пускают . страница говорят недоступна или временно недоступна, . обнадёживает :)
goro27 » 21 сен 2020, 12:22
что за ерунда, уже час висит, даже если перезайти, ничего не дает сделать
Alienora » 21 сен 2020, 12:30
goro27 писал(а): что за ерунда, уже час висит, даже если перезайти, ничего не дает сделать
goro27 » 21 сен 2020, 12:34
goro27 писал(а): что за ерунда, уже час висит, даже если перезайти, ничего не дает сделать
результат очередного обновления, наверное.
Невозможно зайти в ЕИС
burgher » 08 окт 2020, 10:48
С 28 сентября на нескольких рабочих местах стало невозможным зайти в ЕИС закупки (bus.gov.ru). Четыре места с Windows 8.1, IE11 и одно с Windows 7 Pro SP1, IE11."Не удается отобразить эту страницу" и всё тут. Переустановка винды/Крипто-Про/плагина/Capicom'а ничего не решает. Сразу возникла мысль, что выпустили новый коневой сертификат, но его я нигде не нашёл. Потом обнаружил, что плагин не отображается в списке надстроек (на компах, где ничего не поломалось - отображается). Удалось настроить Яндекс.Браузер, но в нём подписывать невозможно.
Что это внезапно произошло?
Ninon » 16 окт 2020, 12:34
АннаБорисова » 27 окт 2020, 10:54
kir_dfg » 27 окт 2020, 11:35
Добрый день.
Беда у Вас( Вам нужна подпись на другого сотрудника с правами администратора. Если ее нет, то пишите в ТП с требованием заблокировать эту учетную запись. Если будут сопротивляться, проталкивайте через казну. Ну и скрины делайте.
Впредь обязательно имейте вторую подпись, а также будьте внимательны при заполнении реквизитов при выпуске сертификата.
Машины времени есть у каждого. Те, что переносят в прошлое, зовутся воспоминаниями, а те, что уносят в будущее - мечтами ©
rus94 » 27 окт 2020, 11:47
думаю, что это их не спасет, админа может привязать только рук, а рук зайти не может. или я не правильно что то понимаю?
думается, что им надо написать заявление в казну на отзыв "нового" сертификат (так как он с левым снилсом), и выпустить "второй новый" сертификат.
Читайте также: