Идентификатор ключа центра сертификации

[firsov@zic.e-zab.ru]

Здравствуйте!

В сертификатах ключей электронной подписи пользователей во вкладке состав поле  Идентификатор ключа центра сертификации указывается Серийный номер сертификата администратора УКЦ ( корневого), а не сертификата, подписанного Головным Удостоверяющим центром. Техническая поддержка ФНС ссылается, что из-за этого не работают сертификаты на сайте nalog.ru и указывают, что там должен быть указан серийный номер сертификата выпущенного Головным УЦ.   

[BRV]

Добрый день!

Действительно, согласно требованиям п. 24 приказа ФСБ России №795 " В квалифицированном сертификате следует использовать дополнение authorityKeyIdentifier с занесением  в поле authorityCertSerialNumber номера соответствующего квалифицированного сертификата аккредитованного УЦ или доверенного лица аккредитованного УЦ либо уполномоченного федерального органа, создавшего исходный квалифицированный сертификат".

При работе УКЦ в режиме аккредитованного удостоверяющего центра, а также использовании квалифицированного сертификата, полученного от УЦ Минкомсвязи России, в качестве Текущего сертификата дополнение "Идентификатор ключа центра сертификации" в издаваемых квалифицированных сертификатах пользователей будет соответствовать требованиям п. 24 приказа №795.  

[firsov@zic.e-zab.ru]

Наш УЦ функционирует в режиме Аккредитованного УЦ, но в сертификаты пользователей вносится серийный номер самоподписного корневого сертификата, а не квалифицированного сертификата Головного УЦ, так, как УКЦ не знает про сертификат  Головного УЦ.

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

[BRV]

Скажите, а Ваш УЦ прошел аккредитацию в Минкомсвязи (https://digital.gov.ru/ru/activity/govservices/2/)?

Все Аккредитованные УЦ получают свой квалифицированный сертификат у Головного УЦ (https://digital.gov.ru/ru/appeals/faq/66/) .

[firsov@zic.e-zab.ru]

Да, мы аккредитованный УЦ. Сертификат у Головного УЦ мы получили, но в УКЦ он не подгружается (согласно документации ViPNet УКЦ 4_Руководство администратора) и все сертификаты подписываются самоподписным сертификатом.

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

[BRV]

Действительно, ранее установление доверительных отношений с Головным УЦ осуществлялось за счет прохождения процедуры кросс-сертификации. К сожалению, я не могу уточнить, с какого момента УЦ Минкомсвязи стал выступать в качестве Головного, и все Аккредитованные УЦ стали его подчиненными. Теперь для получения квалифицированного сертификата, согласно https://digital.gov.ru/ru/appeals/faq/66/ , необходимо сформировать запрос к вышестоящему УЦ. 

Когда Вы проходили аккредитацию и передавали запрос на кросс-сертификат в Головной УЦ в последний раз? 

[firsov@zic.e-zab.ru]

Аккредитацию повторно прошли 21.08.2018 г. Запрос на кросс-сертификат отправляли в декабре 2018 г. по новому ГОСТ 2012.

15.01.2019 г. повторно направил в ГУЦ кросс-сертификат, но уже как к вышестоящему УЦ. Пришел ответ от ситуационного центра, что:

Ваш запрос на сертификат не может быть обработан, т.к. содержит ошибку:

1) Ошибка кодирования: запрос содержит недопустимые структуры
    Атрибут[1]: 1.2.643.2.4.1.1.1.1.2
    Значение[1][0]:
    Неизвестный тип атрибута

Обратитесь, пожалуйста, в техническую поддержку разработчика вашего средства УЦ, там в курсе проблемы. Вам необходимо сформировать корректный запрос на подчинённый центр сертификации без неизвестного атрибута (Атрибут[1]: 1.2.643.2.4.1.1.1.1.2)

[azz]

6 часов назад, firsov@zic.e-zab.ru сказал:

Аккредитацию повторно прошли 21.08.2018 г. Запрос на кросс-сертификат отправляли в декабре 2018 г. по новому ГОСТ 2012.

15.01.2019 г. повторно направил в ГУЦ кросс-сертификат, но уже как к вышестоящему УЦ. Пришел ответ от ситуационного центра, что:

Ваш запрос на сертификат не может быть обработан, т.к. содержит ошибку:

1) Ошибка кодирования: запрос содержит недопустимые структуры
    Атрибут[1]: 1.2.643.2.4.1.1.1.1.2
    Значение[1][0]:
    Неизвестный тип атрибута

Обратитесь, пожалуйста, в техническую поддержку разработчика вашего средства УЦ, там в курсе проблемы. Вам необходимо сформировать корректный запрос на подчинённый центр сертификации без неизвестного атрибута (Атрибут[1]: 1.2.643.2.4.1.1.1.1.2)

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

[firsov@zic.e-zab.ru]

я и 

3 минуты назад, azz сказал:

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

я и обращаюсь. Разработчики средства УЦ - Инфотекс. 

[azz]

1 час назад, firsov@zic.e-zab.ru сказал:

я и 

я и обращаюсь. Разработчики средства УЦ - Инфотекс. 

Ну, форум - не техподдержка. Есть форма для обращения на самом сайте, либо на hotline@infotecs.ru. Выбирайте любой удобный для Вас способ.

[BRV]

7 часов назад, firsov@zic.e-zab.ru сказал:

Аккредитацию повторно прошли 21.08.2018 г. Запрос на кросс-сертификат отправляли в декабре 2018 г. по новому ГОСТ 2012.

15.01.2019 г. повторно направил в ГУЦ кросс-сертификат, но уже как к вышестоящему УЦ. Пришел ответ от ситуационного центра, что:

Ваш запрос на сертификат не может быть обработан, т.к. содержит ошибку:

1) Ошибка кодирования: запрос содержит недопустимые структуры
    Атрибут[1]: 1.2.643.2.4.1.1.1.1.2
    Значение[1][0]:
    Неизвестный тип атрибута

Обратитесь, пожалуйста, в техническую поддержку разработчика вашего средства УЦ, там в курсе проблемы. Вам необходимо сформировать корректный запрос на подчинённый центр сертификации без неизвестного атрибута (Атрибут[1]: 1.2.643.2.4.1.1.1.1.2)

У Вас какая версия УКЦ?

 

[firsov@zic.e-zab.ru]

4.6 (1.37636)

[BRV]

7 минут назад, firsov@zic.e-zab.ru сказал:

4.6 (1.37636)

В комплекте должна быть утилита обработки запроса в вышестоящий УЦ.