Содержание
Сертификаты открытого ключа подписи уполномоченного лица внутреннего Удостоверяющего центра ЦА ФСС РФ и списки аннулированных сертификатов в соответствии с 1-ФЗ начиная с 10.01.2002 года:
| 2011г. | 2012г. | 2013г. | 2014г. | 2015г. |
| Сертификат САС | Сертификат САС | Сертификат САС | Сертификат САС | Сертификат САС |
Квалифицированные сертификаты открытого ключа подписи уполномоченного лица Головного Удостоверяющего
центра ФСС РФ и списки аннулированных сертификатов в соответствии с 63-ФЗ начиная с 01.07.2013 года:
| 2011г. | 2012г. | 2013г. | 2014г. | 2015г. | 2016г. | 2017г. | 2018г. | 2019г. | 2020г. |
|
Сертификат САС |
Сертификат САС |
Сертификат САС |
Сертификат САС |
Сертификат САС |
Сертификат САС |
Сертификат САС |
Сертификат САС |
Сертификат САС |
Сертификат САС |
Сертификаты открытого ключа подписи уполномоченного лица для подписи квитанции о приёме расчёта в соответствии с 1-ФЗ начиная с 10.01.2002 года:
| 2011г. | 2012г. | 2013г. | 2014г. | 2015г. |
| Сертификат | Сертификат | Сертификат | Сертификат | Сертификат |
Квалифицированные сертификаты открытого ключа подписи уполномоченного лица для подписи квитанции о приеме расчета в соответствии с 63-ФЗ начиная с 01.07.2013 года:
| 2011г. | 2012г. | 2013г. | 2014г. | 2015г. | 2016г. | 2017г. |
| Сертификат | Сертификат | Сертификат | Сертификат | Сертификат | Сертификат | Сертификат |
Рутокен ЭЦП 2.0 — один из видов носителей для закрытого ключа электронной подписи. В чем его преимущество и в каких системах можно использовать?
Основные характеристики
Носитель Рутокен ЭЦП 2.0 предназначен для:
- хранения сертификатов электронной подписи,
- генерации электронных подписей и шифрования документа,
- аутентификации пользователей и защиты информации от доступа посторонних лиц.
Рутокен ЭЦП 2.0 выпускает компания «Актив-софт», токен выполнен в виде флеш-накопителя со встроенным микроконтроллером и защищенной памятью для безопасного хранения данных владельца.
Носитель можно использовать на любом компьютере или на мобильном устройстве с USB-разъемом. Рутокен ЭЦП 2.0 поддерживает российские и международные стандарты информационной безопасности и совместим c операционными системами Windows, Linux и Mac.
Получить электронную подпись
В чем преимущества носителя
Дополнительный уровень безопасности
Шифрование данных на Рутокен ЭЦП 2.0 производится методом двухфакторной аутентификации с использованием PIN-кода. Для успешной аутентификации требуется выполнить два условия:
- знать пользовательский PIN-код,
- иметь на руках сам токен.
Это обеспечивает гораздо более высокий уровень защиты по сравнению с обычным доступом по паролю. Если устройство попадет в руки злоумышленника, он не сможет воспользоваться информацией на нем или создать подпись, даже если ему известен пароль.
Встроенная лицензия на криптопровайдер
Для работы с Рутокен ЭЦП 2.0 не нужно устанавливать средство криптографической защиты информации (СКЗИ) на компьютер или мобильное устройство. СКЗИ вшито в носитель и работает внутри него, а не в операционной системе.
Благодаря этому владелец не привязан к одному рабочему месту и может выполнять операции создания электронной подписи и шифрованию на любом компьютере, где установлено соответствующее ПО. Кроме того, исключен конфликт Рутокен ЭЦП 2.0 и других СКЗИ.
Криптография на борту
Рутокен ЭЦП выполняет криптографические операции таким образом, что закрытая ключевая информация не покидает пределы токена. Это исключает возможность компрометации ключа и повышает информационную безопасность системы, в которой используется токен.
Где используется?
Рутокен ЭЦП 2.0 используют в электронном документообороте и самых разных системах, в том числе где установлены высокие требования к безопасности информации:
- дистанционное банковское обслуживание,
- электронный документооборот в госсекторе,
- взаимодействие с ЕГАИС ФСРАР.
«Рутокен ЭЦП 2.0» также можно использовать на сайте ФНС для аутентификации в сервисе «Личный кабинет индивидуального предпринимателя». С его помощью налогоплательщики подписывают и отправлять в ФНС заявления на регистрацию, перерегистрацию и снятие с учета контрольно-кассовой техники и другие документы.
Получить электронную подпись
Закупки в электронном виде — как по госзаказу, так и коммерческие — проводятся на электронных торговых площадках. Для аккредитации на них, отправки заявок и подписания контрактов поставщикам необходим сертификат электронной подписи (ЭП).
Удостоверяющий центр СКБ Контур выпускает сертификаты ЭП для электронных торгов в рамках тарифному плану: «Сертум Классик».
В стоимость тарифа «Сертум» входит:
- Изготовление сертификата ЭП сроком действия 12 месяцев («Сертум Платинум» — 15 месяцев),
- круглосуточная консультационная поддержка по вопросам использования сертификата ЭП и/или СКЗИ,
- Контур.Веб-диск — автоматическая настройка рабочего места,
- Контур.Крипто — сервис для создания и проверки электронной подписи.
При срочной необходимости участия в торгах можно заказать ускоренное получение сертификата. Это займет около часа при условии, что будут представлены оригиналы всех документов и подтверждение оплаты.
Обратите внимание, что аккредитация на ЭТП госзаказа действует 3 года. По истечении срока действия сертификата электронной подписи необходимо получить новый и обновить информацию в личном кабинете ЭТП для дальнейшего участия в торгах.
Если сотрудник организации, на которого был выпущен ключ электронной, больше не участвует в торгах от лица компании или уволился, нужно сразу же обратиться в свой удостоверяющий центр, чтобы отозвать старый сертификат электронной подписи и оформить заявку на новый.
Дополнительные услуги
- запись на защищенный носитель Рутокен,
- лицензия на право использования СКЗИ КриптоПро CSP в составе сертификата ключа,
- сопровождение сертификата: смена и отзыв сертификата ЭП в течение действия договора (но не более 3 раз),
- ускоренный выпуск сертификата за один час с момента представления всех документов,
- запись дубликата сертификата электронной подписи на защищенный носитель,
- Школа электронных торгов,
- Контур.Закупки — сервис по поиску и отбору закупок по 44-ФЗ и 223-ФЗ.
Ранее уже приходилось сталкиваться с проблемой невозможности корректного развёртывания ПО из-за того, что на целевых компьютерах с OC Windows не обновляется хранилище сертификатов доверенных корневых центров сертификации (далее для краткости будем называет это хранилище TrustedRootCA). На тот момент вопрос был снят с помощью развёртывания пакета rootsupd.exe, доступного в статье KB931125, которая относилась к ОС Windows XP. Теперь же эта ОС полностью снята с поддержки Microsoft, и возможно, поэтому данная KB-статья более недоступна на сайте Microsoft. Ко всему этому можно добавить то, что уже даже на тот момент времени решение с развёртыванием уже устаревшего в ту пору пакета сертификатов было не самым оптимальным, так как тогда в ходу были системы с ОС Windows Vista и Windows 7, в которых уже присутствовал новый механизм автоматического обновления хранилища сертификатов TrustedRootCA. Вот одна из старых статей о Windows Vista, описывающих некоторые аспекты работы такого механизма — Certificate Support and Resulting Internet Communication in Windows Vista. Недавно я снова столкнулся с исходной проблемой необходимости обновления хранилища сертификатов TrustedRootCA на некоторой массе клиентских компьютеров и серверов на базе Windows. Все эти компьютеры не имеют прямого доступа в Интернет и поэтому механизм автоматического обновления сертификатов не выполняет свою задачу так, как хотелось бы. Вариант с открытием всем компьютерам прямого доступа в Интернет, пускай даже на определённые адреса, изначально рассматривался как крайний, а поиски более приемлемого решения привел меня к статье Configure Trusted Roots and Disallowed Certificates (RU), которая сразу дала ответы на все мои вопросы. Ну и, в общем то, по мотивам этой статьи, в данной заметке я кратко изложу на конкретном примере то, каким образом можно централизованно перенастроить на компьютерах Windows Vista и выше этот самый механизм авто-обновления хранилища сертификатов TrustedRootCA, чтобы он использовал в качестве источника обновлений файловый ресурс или веб-сайт в локальной корпоративной сети.
Для начала, на что нужно обратить внимание, это на то, что в групповых политиках, применяемых к компьютерам, не должен быть задействован параметр блокирующий работу механизма авто-обновления. Это параметр Turn off Automatic Root Certificates Update в разделе Computer Configuration > Administrative Templates > System > Internet Communication Management > Internet Communication settings. Нам потребуется, чтобы этот параметр был Выключен, либо просто Не настроен.
Если взглянуть на хранилище сертификатов TrustedRootCA в разделе Локальный компьютер, то на системах, не имеющих прямого доступа в Интернет, набор сертификатов будет прямо так скажем небольшой:
В статье KB2677070 — Доступно автоматическое обновление отозванных сертификатов для систем Windows Vista, Windows Server 2008, Windows 7 и Windows Server 2008 R2 можно найти актуальные на данный момент ссылки на файлы, прямой доступ к которым (минуя прокси с требованием аутентификации) может потребоваться для функций авто-обновления:
Но вариант прямого доступа в рамках данной заметки мы больше упоминать не станем и рассмотрим пример локализации процесса обновления в соответствии с ранее упомянутой статьёй.
Первое, что нам нужно сделать, это рассмотреть варианты получения актуальных файлов набора корневых сертификатов для их дальнейшего распространения внутри локальной сети.
Попробуем на компьютере имеющем прямое подключение к Интернету выполнить команду генерации SST файла, который будет в себе содержать актуальный набор файлов корневых сертификатов. В данном случае на компьютере с Windows 10 выполняется команда, вызывающая входящую в базовый состав ОС утилиту Certutil, которая в свою очередь обращается к веб-узлу Microsoft и создаёт по указанному нами пути SST файл:
Certutil -generateSSTFromWU C:\Temp\WURoots.sst
Полученный в результате выполнения команды SST-файл по сути является контейнером, который содержит в себе все сертификаты для нужного нам обновления системы. Этот контейнер легко открывается в Проводнике Windows загружая ассоциированную с расширением файла оснастку управления сертификатами.
Этот файл удобно использовать, например, когда из всего подмножества доступных сертификатов нужно выбрать лишь некоторый набор и выгрузить их в отдельный SST файл для дальнейшей загрузки, например, с помощью консоли управления локальными сертификатами или с помощью консоли управления групповыми политиками (для импорта в какую-либо доменную политику через параметр Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities).
Однако для интересующего нас способа распространения корневых сертификатов, с помощью модификации работы механизма авто-обновления на конечных клиентских компьютерах, нам потребуется несколько иное представление множества актуальных корневых сертификатов. Получить его можно с помощью всё той же утилиты Certutil, но уже с другим набором ключей.
В нашем примере в качестве локального источника распространения будет использована общая сетевая папка на файловом сервере. И здесь важно обратить внимание на то, что при подготовке такой папки обязательно нужно ограничивать доступ на запись, чтобы не получилось так, что любой желающий сможет модифицировать набор корневых сертификатов, которые потом будут «разливаться» по множеству компьютеров.
Certutil -syncWithWU -f -f \\FILE-SERVER\SHARE\RootCAupd\GPO-Deployment\
Ключи -f -f используются для форсированного обновления всех файлов в каталоге назначения.
В результате выполнения команды в указанной нами сетевой папке появится множество файлов общим объемом примерно в пол мегабайта:
Согласно ранее упомянутой статьи, назначение файлов следующее:
- Файл authrootstl.cab содержит сторонние списки доверия сертификатов;
- Файл disallowedcertstl.cab содержит список доверия сертификатов с недоверенными сертификатами;
- Файл disallowedcert.sst содержит хранилище сериализованных сертификатов, включая недоверенные сертификаты;
- Файлы с именами типа thumbprint.crt содержат сторонние корневые сертификаты.
Итак, файлы необходимые для работы механизма авто-обновления получены, и мы теперь переходим к реализации изменения схемы работы этого самого механизма. Для этого, как всегда, нам на помощь приходят доменные групповые политики Active Directory (GPO), хотя можно использовать и другие инструменты централизованного управления, весь всё, что нам нужно сделать на всех компьютерах — это изменить, вернее добавить, всего один параметр реестра RootDirURL в ветке HKLM\Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate, который и определит путь к нашему сетевому каталогу, в котором мы ранее разместили набор файлов корневых сертификатов.
Говоря о настройке GPO, для реализации поставленной задачи, опять же, можно использовать разные варианты. Например, есть «олд-скульный» вариант с созданием собственного шаблона групповой политики, так как это описано в уже знакомой нам статье. Для этого создадим файл в формате административного шаблона GPO (ADM), например, с именем RootCAUpdateLocalPath.adm и содержимым:
CLASS MACHINE CATEGORY !!SystemCertificates KEYNAME «Software\Microsoft\SystemCertificates\AuthRoot\AutoUpdate» POLICY !!RootDirURL EXPLAIN !!RootDirURL_help PART !!RootDirURL EDITTEXT VALUENAME «RootDirURL» END PART END POLICY END CATEGORY RootDirURL=»URL address to be used instead of default ctldl.windowsupdate.com» RootDirURL_help=»Enter a FILE or HTTP URL to use as the download location of the CTL files.» SystemCertificates=»Windows AutoUpdate Settings»
Скопируем этот файл на контроллер домена в каталог %SystemRoot%\inf (как правило, это каталог C:\Windows\inf). После этого перейдём в редактор доменных групповых политик и создадим отдельную новую политику, открыв затем её на редактирование. В разделе Computer Configuration > Administrative Templates… откроем контекстное меню и выберем пункт подключения нового шаблона политик Add/Remove Templates
В открывшееся окне с помощью кнопки обзора выберем ранее добавленный файл %SystemRoot%\inf\RootCAUpdateLocalPath.adm, и после того, как шаблон появится в списке, нажмём Close.
После проделанного действия в разделе Configuration > Administrative Templates > Classic Administrative Templates (ADM) появится группа Windows AutoUpdate Settings, в которой будет доступен единственный параметр URL address to be used instead of default ctldl.windowsupdate.com
Сохраним проделанные изменения и применим созданную политику к доменному контейнеру, в котором расположены целевые компьютеры. Однако рассмотренный метод настройки GPO имеет ряд недостатков и именно поэтому я назвал его «олд-скульным».
Другой, более современный и более продвинутый метод настройки реестра клиентов — это использование Group Policy Preferences (GPP). При таком варианте мы можем создать соответствующий объект GPP в разделе групповой политики Computer Configuration > Preferences > Registry с обновлением параметра (Action: Update) реестра RootDirURL (тип значения REG_SZ)
При необходимости можем для созданного параметра GPP включить гибкий механизм нацеливания (Закладка Common > Опция Item-level targeting) на конкретный компьютер или группу компьютеров для предварительного тестирования того, что у нас в конечном итоге получиться после применения групповых политик.
Разумеется, нужно выбрать какой-то один вариант, либо с подключением собственного ADM-шаблона, либо с использованием GPP.
После настройки групповых политик на любом подопытном клиентском компьютере выполним обновление командой gpupdate /force c последующей перезагрузкой. После загрузки системы проверим в реестре наличие созданного ключа и попробуем проверить наличие факта обновления хранилища корневых сертификатов. Для проверки воспользуемся простым но действенным примером описанным в заметке Trusted Roots and Disallowed Certificates.
Для примера посмотрим, есть ли в хранилище сертификатов компьютера корневой сертификат, использованный для выпуска сертификата, который установлен на сайте с именем buypass.no (но на сам сайт пока не переходим :)).
Сделать это удобнее всего с помощью средств PowerShell:
Get-ChildItem cert:\localmachine\root | Where {$_.friendlyname -like «*Buypass*»}
С большой долей вероятности у нас не окажется такого корневого сертификата. Если так, то откроем Internet Explorer и обратимся к URL https://buypass.no. И если настроенный нами механизм автоматического обновления корневых сертификатов работает успешно, то в event-логе Windows Application при это появится событие c источником (Source) CAPI2, свидетельствующее об успешной загрузке нового корневого сертификата :
Имя журнала: Application Источник: Microsoft-Windows-CAPI2 Дата: 04.08.2016 18:20:45 Код события: 4097 Категория задачи:Отсутствует Уровень: Сведения Ключевые слова:Классический Пользователь: Н/Д Компьютер: KOM-WS306.holding.com Описание: Успешное автоматическое обновление стороннего корневого сертификата:: субъект: < CN=Buypass Class 3 Root CA, O=Buypass AS-983163327, C=NO > ; отпечаток SHA1: < DAFAF7FA6684EC068F1450BDC7C281A5BCA96457 > .
После этого мы можем снова выполнить указанную ранее команду запроса к хранилищу корневых сертификатов и увидим, что теперь в нём действительно появился новый корневой сертификат, именно тот который фигурировал в событии event-лога Windows:
Как видим, механизм авто-обновления работает и теперь всё, что остаётся, это организовать поддержку в актуальном состоянии файлов в сетевой папке, запланировав, например на ночное время, ежесуточное выполнение задания обновления ранее упомянутой командой: