- Глава вторая: ещё одна эп
- История[ | ]
- Как добавить корневой сертификат в доверенные в linux на уровне системы
- Планирование имён цс
- Планирование сроков действия crl
- Ручная настройка конфигурации openssl
- Создание сертификатов
- Списки аннулированных сертификатов
- Список отозванных сертификатов не актуален электронный бюджет
- Требования к рабочему месту
- Формат списка аннулированных сертификатов
- Часто задаваемые вопросы | фнс россии | 77 город москва
- Состав списков отзыва
Глава вторая: ещё одна эп
Порывшись в почте, я нашел еще один электронный договор. По счастливой случайности, им тоже оказался страховой полис, но на этот раз еОСАГО от АО “Тинькофф Страхование”. Открываем сертификат, смотрим выпустившую сертификат организацию. Ей оказывается АО “Тинькофф банк”.
По отработанному алгоритму идём в поисковую систему с запросом “тинькофф сертификат”, находим официальный сайт УЦ АО Тинькофф Банк. Тут нас встречает изобилие ссылок на корневые сертификаты, списки отозванных сертификатов и даже видеоинструкция по их установке.
Скачиваем “Цепочка корневых сертификатов УЦ АО Тинькофф Банк ГОСТ Р 34.10.2021”, на этот раз ссылка ведёт не на сторонний сервис, а на сайт банка. Формат файла P7B не очень известный, но открывается Windows без установки стороннего софта и показывает находящиеся в нём сертификаты.
Ставим оба, проверяем сертификат в полисе. Но нет, сертификат не является доверенным, т.к. система не может подтвердить поставщика сертификата. На сайте УЦ было 2 ссылки на 2 цепочки сертификатов, один для ГОСТ Р 34.10.2001, другой для ГОСТ Р 34.10.2021.
В новом файле формата P7B оказывается уже 3 файла сертификатов. Можно поставить все 3, однако стоит заметить, что сертификат “Головного удостоверяющего центра” мы поставили в первой главе из RAR архива ООО “ИТК”, они идентичны. А сертификат с не очень говорящим названием “УЦ 1 ИС ГУЦ” поставил КриптоПро CSP, т.к. галочка об установке корневых сертификатов была установлена по-умолчанию в его инсталляторе. Единственным новым является сертификат АО “Тинькофф Банк”, который мы и ставим.
После установки сертификатов из “Цепочка корневых сертификатов УЦ АО Тинькофф Банк ГОСТ Р 34.10.2001” путь в сертификате прорисовался и система радостно сообщила, что он является доверенным. Adobe Acrobat Reader DC также подтвердил, что подпись действительна.
На этом приключения с проверкой ЭП на полисе еОСАГО завершаются. Заметно, что после того, как в системе уже установлен необходимый софт, а пользователь понимает принципы работы и поиска промежуточных сертификатов, то проверка подписи занимает уже меньше времени.
Но проблемные места по-прежнему видны: необходимо искать в интернете официальные сайты удостоверяющих центров, разбираться в инструкциях по установке сертификатов. Даже при установленных корневых сертификатах необходимо искать промежуточный, иначе цепочка доверия будет не полной и система не сможет подтвердить достоверность подписи.
История[ | ]
История создания PKI (Инфраструктура открытых ключей) восходит к оригинальной работе Уитфилда Диффи и Мартина Хеллмана по криптографии с открытым ключом, в которой предлагается каталог открытых файлов, который пользователи могли бы использовать, чтобы найти открытые ключи других пользователей.
Понимая некоторые недостатки этого подхода, в том числе то, что отключение доступа к каталогу не позволит пользователям безопасно общаться, Лорен Конфельдер[en] предложил концепцию сертификатов в 1978 году.
Сертификаты разделяют функции подписи и поиска, позволяя центру сертификации связывать имя с ключом с помощью цифровой подписи, а затем хранить полученный сертификат в репозитории. Поскольку хранилище можно реплицировать и сделать отказоустойчивым, подход CA устраняет многие проблемы, связанные с надёжностью каталогов.
Спустя несколько лет после того, как Конфельдер опубликовал свою диссертацию, разработчики включили использование сертификата в X.500, глобальный каталог названных объектов, управляемых монопольными телекоммуникационными компаниями. В каталоге X.
500 предлагается иерархическая модель базы данных, причём путь через каталог определяется рядом компонентов относительного отличительного имени (RDN), которые вместе образуют отличительное имя (DN). Чтобы защитить доступ к каталогу, его разработчики предложили различные механизмы контроля доступа, начиная от простых основанных на пароле мер и заканчивая относительно новым подходом к использованию цифровых подписей.
Разработчики основывали концепцию СОС на чёрных списках кредитных карт, которые использовались в 1970-х годах. Компании, выпускающие кредитные карты, периодически печатали буклеты с номерами аннулированных карт и распространяли их среди продавцов, ожидая, что они проверят все карты, с которыми взаимодействуют, в чёрном списке, прежде чем их принять. Те же проблемы, которые затрагивали чёрные списки кредитных карт, сегодня влияют на СОС.
Как добавить корневой сертификат в доверенные в linux на уровне системы
Сертификат с расширением .crt можно открыть двойным кликом и просмотреть его содержимое:
Если вы работаете в системе от обычного пользователя (не root), то кнопка «Импортировать» будет недоступна.
Чтобы разблокировать кнопку «Импортировать», выполните следующую команду:
sudo gcr-viewer /ПУТЬ/ДО/СЕРТИФИКАТА.crt
Например:
sudo gcr-viewer ./HackWareCA.crt
Данный способ может не сработать, поэтому рассмотрим, как добавить доверенные корневые центры сертификации в командной строке.
Суть метода очень проста:
- Добавить свой корневой CA сертификат в папку, предназначенную для таких сертификатов.
- Запустить программу для обновления общесистемного списка сертификатов.
Пути и команды в разных дистрибутивах Linux чуть различаются.
Просмотреть Subject всех корневых CA сертификатов можно уже знакомой командой:
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crtДля демонстрации я добавлю сертификат с Common Name, включающим «HackWare», тогда для проверки, имеется ли сертификат с таким именем среди корневых CA, я могу использовать команду:
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare
Для добавления своего корневого CA в доверенные в Debian, Kali Linux, Linux Mint, Ubuntu и их производных:
1. Проверьте, существует ли директория /usr/local/share/ca-certificates:
ls -l /usr/local/share/ca-certificates
Если её ещё нет, то создайте:
sudo mkdir /usr/local/share/ca-certificates
Сертификат должен быть в формате PEM (обычно так и есть) и иметь расширение .crt — если расширение вашего сертификата .pem, то достаточно просто поменять на .crt.
2. Скопируйте ваш сертификат командой вида:
sudo cp СЕРТИФИКАТ.crt /usr/local/share/ca-certificates/
Например:
sudo cp ./HackWareCA.crt /usr/local/share/ca-certificates/
3. Запустите следующую команду для обновления общесистемного списка:
sudo update-ca-certificates
Пример вывода:
Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... Adding debian:HackWareCA.pem done. done.
Проверим наличие нашего CA сертификата среди доверенных:
awk -v cmd='openssl x509 -noout -subject' ' /BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep -i HackWare
Сертификат успешно найден:
Чтобы его удалить:
sudo rm /usr/local/share/ca-certificates/СЕРТИФИКАТ.crt sudo update-ca-certificates
Для добавления своего корневого CA в доверенные в Arch Linux, BlackArch и их производных:
1. Выполните команду вида:
sudo cp ./СЕРТИФИКАТ.crt /etc/ca-certificates/trust-source/anchors/
Например:
sudo cp ./HackWareCA.crt /etc/ca-certificates/trust-source/anchors/
2. Обновите общесистемный список доверенных CA:
sudo update-ca-trust
Чтобы удалить этот сертификат:
sudo rm /etc/ca-certificates/trust-source/anchors/СЕРТИФИКАТ.crt sudo update-ca-trust
Планирование имён цс
Имя ЦС – это имя, которое будет отображено в поле
Subject
конкретного ЦС. Не путать с именем хоста, на котором работает служба сертификатов. Полное имя ЦС будет состоять из двух компонентов, самого имени (атрибут CN или Common Name) и опционального суффикса в формате X.500. По умолчанию ADCS назначает имя в следующем формате:
Для Standalone CA: <ComputerName>-CA
Для Enterprise CA: <DomainShortName>-<ComputerName>-CA, <X500DomainSuffix>
Хорошо это или плохо? Технически, вы можете выбрать любое имя, функционально оно ни на что влиять не будет. Есть мнение, что имя вашего ЦС является в некотором роде визитной карточкой вашей PKI, отражая ваше отношение к деталям, которые не имеют непосредственного отношения к функциональности, но обеспечивают достаточный уровень информативности и открытости. Поэтому при выборе полного имени сертификата следует руководствоваться несколькими рекомендациями:
Предположим, что вы подбираете имя для корневого ЦС компании Contoso Pharmaceuticals Ltd., которая находите в городе Рига, Латвия и управление обеспечивается отделом информационных технологий. В этом случае имя ЦС может иметь следующий вид:
CN=Contoso Pharm Root Certification Authority, OU=Division Of IT (DoIT), O=Contoso Pharmaceuticals Ltd., L=Riga, C=LVСледует помнить, что атрибут Country поддерживает только двухбуквенный индекс страны. Например, LV, GB, RU, US и т.д. В качестве дополнительных примеров, можете обратиться к сертификатам ЦС коммерческих провайдеров, как VeriSign/Symantec, DigiCert и т.д.
Для подчинённого ЦС это имя будет похожим, за исключением того, что слово Root в имени будет заменено на Subordinate или Issuing. В случае трёхуровневой иерархии, где явно выделяется ЦС политик, слово Root будет заменено на Policy. Как я выше отмечал, в вашей компании могут применяться другие правила, и вы можете их внедрить в имена ЦС, на функциональность это влиять не будет. При этом следует избегать:
- Чрезмерно длинных имён в атрибуте CN (не более 50 символов). При длине атрибута CN свыше 51 символа, оно будет укорочено с пристыковкой хэша отброшенного фрагмента имени в конец имени. Это называется процессом «санитизации» имени, который описан в §3.1.1.4.1.1 протокола [MS-WCCE]. Т.е. может случиться так, что при слишком длинном имени слово оборвётся на середине и будет иметь неприглядный вид.
- Использовать буквы, которые не входят в состав латинского алфавита, т.е. никакой криллицы или диактрических букв (например, ā, ž, Ü, ẞ). ADCS поддерживает только однобайтовые кодировки для атрибута CN и для ограниченного набора символов. Неподдерживаемые символы будут преобразованы в другую кодировку и станут нечитаемыми. Полный список запрещённых символов представлен в §3.1.1.4.1.1.2 протокола [MS-WCCE]. Здесь работает принцип «лучшее – враг хорошему», поэтому имена должны быть достаточно лаконичными и информативными.
Планирование сроков действия crl
Это всё было о составе списков отзыва для каждого ЦС. Теперь следует определить сроки:
Здесь тоже можно применить подход в зависимости от условий эксплуатации. Риск отзыва промежуточного ЦС весьма низкий, следовательно, нет смысла слишком часто публиковать пустой CRL. В современной практике применяются следующие типовые значения по сроку действия CRL для ЦС, которые выписывают сертификаты только другим ЦС:
Для подчиненных ЦС схема такая же. Поскольку риск отзыва клиентских сертификатов высокий, то можно предположить и высокую частоту отзыва. Следовательно, таким ЦС следует выполнять публикацию списков отзыва гораздо чаще, а для экономии трафика комбинировать базовые и дифференциальные CRL.
Можно понять желание администраторов уменьшить это время (в идеале – мгновенно), чтобы клиенты не признавали отозванный сертификат действительным. Однако, уменьшение одного риска приводит к увеличению другого риска. Представьте, что по какой-то причине отказал сервер ЦС в момент, когда предыдущий CRL близок к истечению срока действия, а новый CRL невозможно опубликовать.
Microsoft CA по умолчанию уже закладывает некоторый резерв по времени на непредвиденные случаи и когда распространение списков отзыва по всем точкам публикации занимает некоторое время (например, вызваны латентностью репликации). Этот резерв в английской терминологии называется CRL overlap.
Это достигается использованием двух полей в списке отзыва: Next CRL Publish и Next Update. Поле Next CRL Publish указывает на время, когда ЦС опубликует обновлённый список отзыва (автоматически). Next Update указывает на время, когда срок действия текущего списка истечёт.
Поле Next Update будет всегда выставлен на несколько позднее время, чем Next CRL Publish. Другими словами, ЦС опубликует обновлённый список отзыва до истечения срока предыдущего. Алгоритм вычисления автоматических значений для этих полей нетривиален и описан в следующей статье:
How ThisUpdate, NextUpdate and NextCRLPublish are calculated (v2). Если значения по умолчанию вас не устраивают по тем или иным причинам, их можно отредактировать. Необходимо учитывать, что запас по времени имеет нижние и верхние границы.
Например, верхняя граница не может превышать срока действия самого CRL. Так, если срок действия CRL составляет 1 день, то запас может составлять максимум 1 день, и тогда ЦС будет публиковать списки отзыва ежедневно, но срок действия будет составлять 2 дня. Тем самым достигается запас времени на восстановление ЦС в случае непредвиденных обстоятельств.
На практике я достаточно часто наблюдал желание администраторов закрутить настройки сроков действия CRL до минимального предела с таким обоснованием: «пользователь уволился и не должен иметь возможность аутентифицироваться с отозванным сертификатом».
При планировании сроков действия CRL и периодичности следует руководствоваться следующими рекомендациями:
Ручная настройка конфигурации openssl
Добавить в начало файла /etc/ssl/openssl.cnf строку
В конец файла добавить строчки
Значения параметров в секции [gost_section]:
| Параметр | Значение |
|---|---|
| engine_id = gost-astra | |
| dynamic_path = /usr/lib/x86_64-linux-gnu/engines-1.1/gost-astra.so | |
| default_algorithms = ALL | Разрешает использование движком всех алгоримов, имеющихся в движке. Проверить список доступных алгоритмов можно командой openssl engine gost-astra -c При установленном и включенном движке libgost-astra ответ команды будет выглядеть примерно так: # openssl engine gost-astra -c |
| CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet | Параметр CRYPT_PARAMS применяется только для библиотеки gost-astra. Позволяет пользователю выбирать наборы параметров симметричного алгоритма защитного преобразования. Без этой опции не будет работать опция -gost89, что, в свою очередь, приведёт к тому, что для защитного преобразования вместо GOST 28147-89 будет использоваться rc2-cbc. |
Создание сертификатов
Для создания ключа и сертификата пользователя используется кнопка«Создать сертификат».При нажатии на эту кнопку, будет открыт диалог со следующими полями:
Имя пользователя – имя сертификата. Имя сертификата должно быть уникальным, не может быть пустым и не может содержать пробелы.
Страна – двухбуквенный код страны. Если поле пустое, то по умолчанию будет установлено значение RU;
Область – название области. Если поле пустое, то по умолчанию будет установлено значение MO;
Город – название города. Если поле пустое, то по умолчанию будет установлено значение Moscow;
Организация – название организации. Если поле пустое, то по умолчанию будет установлено значение none;
Email – адрес электронной почты. Если поле пустое, то по умолчанию будет установлено значение none;
Отдел – название подразделения организации; Если поле пустое, то по умолчанию будет установлено значение none;
Имя –имя пользователя. Если поле пустое, то по умолчанию будет установлено значение noname.
При нажатии на кнопку «Да» будут созданы следующие файлы:
будет создан новый файл закрытого ключа для клиента с указанным именем клиента (ivanov.key)
будет создан файл сертификата открытого ключа, подписанный удостоверяющим центром (ivanov.crt)
для удобства последующей передачи клиенту, созданные файлы будут скопированы в каталог /etc/opnvpn/clients-keys/имя_клиента (/etc/opnvpn/clients-keys/ivanov в используемом примере)
дополнительно, в это же каталог /etc/opnvpn/clients-keys/имя_клиента, будут скопированы и другие, необходимые для работы клиента, файлы:
файл сертификата удостоверяющего центра (по умолчанию – ca.crt) и
файл дополнительной аутентификации TLS (ta.key).
ВАЖНО! Клиентские ключи генерируются в открытой (без защитного преобразования) форме, чтобы избежать ввода паролей при подключении клиента к серверу.
Списки аннулированных сертификатов
УЦ выпускает сертификат только после проверки той информации, которая включается в содержание сертификата. Если информация неверна или сертификат утратил валидность, УЦ должен его аннулировать.
Существует множество причин, по которым сертификат аннулируется до истечения срока его действия: компрометация секретного ключа, политика безопасности конкретной организации в отношении сертификатов уволившихся служащих и др.
Традиционным инструментом распространения информации об аннулировании сертификатов являются публикуемые в репозитории списки аннулированных сертификатов (САС), которые содержат уникальные серийные номера всех аннулированных сертификатов. Цифровая подпись, сопровождающая САС, обеспечивает его целостность и аутентичность.
Статус сертификата на предмет аннулирования должен проверяться перед каждым его использованием. Поэтому PKI должна поддерживать масштабируемую систему аннулирования сертификатов. Удостоверяющий центр должен иметь возможность безопасно публиковать информацию о статусе каждого сертификата данного PKI-домена.
Клиентское программное обеспечение перед использованием любого сертификата должно проверять эту информацию от имени пользователя. Существуют три способа проверки статуса сертификата[80].
- Способ извлечения (“pull”) или проверки с опросом наличия изменений. Этот способ заключается в том, что клиентское приложение периодически выполняет поиск в репозитории последней версии САС и использует ее для проверки статуса сертификата. Приложение выполняет “вытягивание” списка аннулированных сертификатов при каждом запланированном обновлении списка.
- Способ проталкивания (“push”) или принудительной рассылки изменений, при котором удостоверяющий центр рассылает приложениям, использующим сертификаты, новый САС всякий раз, когда какой-либо сертификат аннулируется.
- Способ онлайновой верификации или использования онлайнового протокола статуса сертификата ( Online Certificate Status Protocol – OCSP ). Сервер удостоверяющего центра, известный как OCSP-респондер, в режиме реального времени обрабатывает запросы приложений о статусе сертификатов и предоставляет заверенные цифровой подписью ответы о текущем состоянии каждого сертификата. Ответ содержит информацию об идентификаторе сертификата, его статусе (нормальный, аннулированный, неизвестный), периоде действия, а при необходимости – о времени и причине аннулирования[2].
К механизмам периодической публикации информации об аннулированных сертификатах относятся:
В полной системе аннулирования сочетаются публикация и последующее использование информации об аннулировании сертификатов. УЦ аннулирует сертификат, включая его серийный номер в САС. СинтаксисСАС также разрешает УЦ приостанавливать действие сертификатов.
Список отозванных сертификатов не актуален электронный бюджет
Список отозванных сертификатов не актуален – с такой ошибкой я столкнулся в Электронном Бюджете. Хотя признаться честно это единичный случай, даже при установке на новый компьютер с нуля всего софта для ЭБ, эта ошибка ни когда не возникала. Немного погуглив наткнулся на совет обновить Континент TLS – обновил (хотя тут и ёжику понятно на что он ругается и что ему нужно), ошибка осталась пошел гуглить дальше (в яндексе почему то в топе выдачи по запросу с моей ошибкой, выходили сайты где небыло решений, либо они имели вообще неверное направление, предлагалось установить новые корневые сертификаты и т.д).
Гугл запестрил выдачой – где предлагалось скачать вордовский файл аж на 13 листов!!!
Правда там как то все через пень колоду было в описании решении моей проблемы.
Что нам нужно? Скачать сам список отозванных сертификатов – он расположен на сайте roskazna, весит файлик порядка 3.4 мегабайт и обновляется раз в неделю.
Жмем на файлике правой кнопкой мыши, выбираем как на картинке Установить список отзыва (CRL).
Появляется мастер импорта сертификатов, жмем кнопку «далее».
Ставим галку «поместить все сертификаты в следующее хранилище»
Жмем кнопку «Обзор» и в появившемся окне отмечаем галкой в низу “Показать физические хранилища”, затем нажимаем плюсик около строки “Доверенные корневые центры сертификации” и выбираем “Локальный компьютер”.
Жмем кнопку «ОК».
Жмем кнопку «Далее».
Жмем кнопку «Готово».
Жмем кнопку «ОК»
Требования к рабочему месту
Используемая версия браузера должна быть Internet Explorer 11.
Выполнить настройки браузера можно с помощью скрипта (пункт 6.1) или вручную (пункт 6.2).
6.1. Настройка браузера Internet Explorer с помощью скрипта
Выполнить настройки браузера Internet Explorer, приведенные в пункте 6.2, можно с помощью скрипта.
Cкачать скрипт и выполнить его с помощью программы Microsoft Windows Based Script Host.
6.2. Настройка браузера Internet Explorer вручную
Видеоинструкция по настройке браузера Internet Explorer 11
Запустите Internet Explorer, в правом верхнем углу выберите значок с изображением шестерёнки («Сервис»).
В открывающемся меню выбрать пункт «Свойства браузера».
Откроется окно свойств обозревателя/браузера. Выбрать вкладку «Безопасность».
На вкладке безопасность нажать на зеленую галочку «Надежные сайты», а затем на кнопку «Сайты».
Откроется окно «Надежные сайты». В поле «Добавить в зону следующий узел» вписать адрес веб-портала Белстата без префикса “http(s)://” (e-respondent.my-sertif.ru). Убрать галочку напротив фразы: «Для всех сайтов этой зоны требуется проверка серверов (https:)» и нажать кнопку «Добавить». После чего адрес появится в списке Веб-узлов. Нажать кнопку «Закрыть». Вновь откроется вкладка «Безопасность». Нажать кнопку «Другой».
Откроется окно с названием «Параметры безопасности – зона надежных сайтов». Пролистать список вниз до заголовка «Элементы ActiveX и модули подключения». ВСЁ, что относится к этому заголовку за исключением «Включить фильтрацию ActiveX», должно быть ВКЛЮЧЕНО. Пролистать этот список до конца вниз и включить ВСЕ элементы параметров безопасности, относящиеся к элементам ActiveX, за исключением «Включить фильтрацию ActiveX», после чего нажать кнопку «ОК».
После нажатия кнопки «ОК» появится окно с предупреждением: «Вы действительно хотите изменить настройку для этой зоны?». Нажать кнопку «Да».
6.3. Дополнительные настройки браузера Internet Explorer
В некоторых случаях при возникновении каких-либо ошибок при входе, необходимо проверить выполнение предыдущих пунктов и проделать дополнительные настройки браузера.
Необходимо запустить Internet Explorer. Далее:
• проверьте наличие интернет-соединения (например, загрузив другую страницу);
• нажмите «Очистить ssl» в свойствах браузера (меню «Сервис») на вкладке «Содержание»;
• проверьте наличие Вашего сертификата и его срок действия на вкладке «Содержание» по кнопке «Сертификаты»;
• проверьте наличие и включите плагин «AVEST CryptMail X Web Plugin» в свойствах браузера на вкладке «Программы» по кнопке «Настроить надстройки» и «Отобразить» → «Все надстройки» (версия плагина должна быть 1.1.5.0 или выше);
• очистите временные файлы и файлы-cookie на вкладке «Общие» → «Удалить…».
Перезапустите Internet Explorer и снова выполните вход.
Для корректной работы Веб-портала Вам следует в браузере Internet Explorer обновить страницы, нажав на клавиатуре комбинацию клавиш Ctrl F5. Также рекомендуется периодически чистить кэш браузера, удаляя временные файлы и файлы-cookie в свойствах браузера во вкладке «Общие».
Формат списка аннулированных сертификатов
Формат списка аннулированных сертификатов определен в рекомендациях Международного Союза по телекоммуникациям ITU (X.509) и документах PKIX [167]. Существуют две различные версии САС, первая версия описывалась в первых спецификациях X.509.
Сейчас списки САС первой версии не используются, поскольку они не позволяют решать проблемы масштабируемости и добавлять необходимые функции, а также не способны противостоять атакам подмены. В настоящее время общепринята вторая версия списков САС (см. табл. 8.1), в которой перечисленные проблемы решены при помощи дополнений.
Дополнения могут быть помечены как критичные и некритичные. Некритичные дополнения могут быть проигнорированы, если доверяющая сторона их не понимает (без каких-либо действий с ее стороны). Критичные дополнения должны обрабатываться доверяющей стороной и быть понятны ей.
Даже если некоторые дополнения не распознаются, доверяющая сторона должна, по крайней мере, понимать, что сертификаты, перечисленные в списке, аннулированы. Однако без распознавания определенных дополнений невозможно оценить, является ли САС полным.
Список аннулированных сертификатов (Certificate Revocation List – CRL) представляет собой структурированную двоичную запись в формате абстрактной синтаксической нотации ASN.1.
- первое поле tbs Cert List – это заверенное цифровой подписью содержание списка аннулированных сертификатов, который должен быть подписан (tbs – сокращение от английского выражения “to-be-signed”, означающего “быть подписанным”);
- второе поле Signature Algorithm содержит идентификатор алгоритма цифровой подписи, который применил издатель САС для подписания этого списка. Идентификатор алгоритма задается при помощи соответствующего идентификатора объекта (OID). Значение поля должно совпадать со значением идентификатора алгоритма, указываемого в соответствующем поле САС ;
- третье поле Signature Value содержит значение цифровой подписи, вычисленной на основе содержания САС ; значение подписи – это строка битов в формате ASN.1.
После этой структуры следует непосредственно содержание списка, который подписывается. САС состоит из набора обязательных полей и нескольких опциональных дополнений. В содержании всегда указывается идентификатор алгоритма цифровой подписи, имя издателя и дата выпуска САС.
В соответствии со стандартом RFC 3280 [167] рекомендуется включать дату выпуска нового САС, несмотря на то, что поле Next Update (следующее обновление) считается необязательным, а использование этого поля значительно усложняет валидацию сертификата.
Часто задаваемые вопросы | фнс россии | 77 город москва
В случае, если известен пароль администратора на носитель, то возможно сбросить пароль пользователя. Если пароль и PIN-код от токена не удается вспомнить, то восстановить его не получится. Удостоверяющий центр, выпустивший сертификат, не хранит пароли электронной подписи и токенов. В этом случае необходимо будет перевыпустить сертификат электронной подписи. Использование старого токена, возможно в случае успешного форматирования носителя.
Что необходимо предоставить индивидуальному предпринимателю/ юридическому лицу/нотариусу для получения квалифицированного сертификата ключа проверки электронной подписи в удостоверяющем центре ФНС России?Какими способами осуществляется идентификация Заявителя, обратившегося за получением квалифицированного сертификата ключа проверки электронной подписи в удостоверяющий центр ФНС России?
Идентификация Заявителя, обратившегося за получением квалифицированного сертификата ключа проверки электронной подписи (далее – КСКПЭП) в удостоверяющий центр ФНС России (далее – УЦ ФНС России) проводится следующими способами:
1. при его личном присутствии по основному документу, удостоверяющему личность лица, обратившегося за получением КСКПЭП.
2. без его личного присутствия (планируется к реализации с 01.01.2022)
с использованием действующей КСКПЭП и с применением информационных технологий путем предоставления сведений из единой системы идентификации и аутентификации и единой информационной системы персональных данных, обеспечивающей обработку, сбор и хранение биометрических персональных данных, их проверку и передачу информации о степени их соответствия предоставленным биометрическим персональным данным физического лица.
Идентификация заявителя при первом получении КСКПЭП в УЦ ФНС России осуществляется в точке выдачи (в любом налоговом органе, осуществляющем функции УЦ ФНС России) при его личном присутствии.
Идентификация гражданина иностранного государства осуществляется по паспорту гражданина данного государства или по иному документу, удостоверяющему личность гражданина иностранного государства.
Идентификация беженца, вынужденного переселенца и лица без гражданства осуществляется на основании документа, установленного законодательством Российской Федерации в качестве удостоверяющего личность данных категорий лиц.
Источник:
Федеральный закон от 06.04.2021 № 63-ФЗ «Об электронной подписи»Федеральный закон от 06.04.2021 №63-ФЗ «Об электронной подписи»
Какими способами Заявитель может подать документы на создание квалифицированного сертификата ключа проверки электронной подписи в удостоверяющий центр ФНС России?Как скопировать сертификат, выданный УЦ ФНС России, на различные носители?
Квалифицированные сертификаты, выданные Удостоверяющим центром ФНС России, являются неэкспортируемыми по требованию регулятора – ФСБ России.
Можно ли проверить подлинность ЭП и документа, подписанного этой ЭП?
Да, можно. Это можно сделать с помощью специальных программ и сервисов.
Кроме того на портале государственных услуг Российской Федерации есть возможность проверить действительность электронной подписи, созданной для конкретного документа.
Срок действия электронной подписи, выданной УЦ ФНС России?В каких случаях происходит смена ключа квалифицированной электронной подписи по инициативе владельца КСКПЭП?Какие установлены основания для отказа в предоставлении услуги по выпуску квалифицированного сертификата ключа проверки электронной подписи удостоверяющим центром ФНС России? В каких случаях осуществляется прекращение действия квалифицированного сертификата ключа проверки электронной подписи?В каких случаях осуществляется аннулирование квалифицированного сертификата ключа проверки электронной подписи?Какие установлены основания для прекращения действия квалифицированного сертификата ключа проверки электронной подписи по инициативе удостоверяющего центра ФНС России?Можно ли прекратить действие квалифицированного сертификата ключа проверки электронной подписи по инициативе пользователя?В какой удостоверяющий центр необходимо обратиться Заявителю, если потеряли носитель с ключами электронной подписи?Что такое токен квалифицированного сертификата ключа проверки электронной подписи?
Токен – это один из видов защищенных ключевых носителей, на котором возможно хранить контейнер с закрытым ключом электронной подписи и сертификат квалифицированной электронной подписи.
Для получения услуги по выпуску сертификатов ключей проверки электронной подписи УЦ ФНС России необходимо предоставить носитель ключей электронной подписи, сертифицированный ФСТЭК России или ФСБ России.
Ключевой носитель должен отвечать требованиям:
- носитель ключей электронной подписи должен иметь действительный сертификат соответствия, выданный ФСБ России или ФСТЭК России;
- носитель ключей электронной подписи должен быть форм-фактора USB Type-A.
Какой удостоверяющий центр выдает квалификационную электронную подпись юридическим лицам, индивидуальным предпринимателям, нотариусам, кредитным организациям и должностным лицам, замещающие государственные должности?Какой вид электронной подписи подходит для работы на официальном сайте ФНС России www.nalog.gov.ru?Какая ЭП подходит для работы на порталах: mos.ru, gosuslugi.ru?Какое программное обеспечение необходимо для работы с ЭП?
Для работы с ЭП необходимо использование криптопровайдера, драйверов для корректной работы носителей ключей электронной подписи, специализированного ПО,а также специализированных плагинов.
Криптопровайдер – это специальное программное обеспечение, позволяющее создавать ЭП, осуществлять ее проверку, шифровать и расшифровывать информацию.
Можно ли работать с ЭП на мобильных устройствах или иных устройствах подвижной связи?
Возможно при условии установленного на мобильное устройство сертифицированного криптопровайдера с возможностью подключения отчуждаемых носителей. УЦ ФНС России выпускает сертификаты исключительно на сертифицированные ФСБ России или ФСТЭК России носители (USB-A форм-фактора).
Можно ли, вывезти свою электронную подпись за границу и оттуда работать на порталах, сайтах и торговых площадках Российской Федерации?
По вопросу вывоза за границу СКЗИ необходимо обратиться в ФСБ России, ФТС России и ФСТЭК России.
Как получить и подключиться к программным средствам ЕГАИС?
По вопросам применения электронной подписи необходимо обратиться к регулятору в сфере использования электронной подписи – Минцифры.
По вопросам подключения и получения доступа к информационной системе ЕГАИС необходимо обратиться к оператору информационной системы – Росалкогольрегулирование.
На сайте ФНС России есть сервисы с использованием электронной подписи физических лиц. В частности, “Государственная регистрация ИП”. Может ли физическое лицо после того, как зарегистрировался в качестве индивидуального предпринимателя со своей электронной подписью, пользоваться в последствии этой электронной подписью, но уже в статусе индивидуального предпринимателя? Или ему в любом случае необходимо обращаться в УЦ ФНС России за выпуском сертификата?
По вопросам применения электронной подписи необходимо обратиться к регулятору в сфере использования электронной подписи – Минцифры.
КСКПЭП физического лица не содержит сведений ОГРНИП.
При регистрации ИП в ЛК ФЛ будет возможность подать заявку на выпуск КСКПЭП в ТНО и записаться на личную идентификацию и получение КСКПЭП.
Можно ли внести изменения в документ, подписанный электронной подписью?
Усиленная квалифицированная электронная подпись позволяет обнаружить факт внесения изменений в электронный документ после момента его подписания. Поэтому при внесении изменений в документ, подписанный электронной подписью, документ необходимо подписать заново электронной подписью.
Допускается ли генерация закрытых частей ключа и запись сертификатов на один ключевой носитель в случае, когда заявитель является одновременно индивидуальным предпринимателем и руководителем юридического лица, имеющим право действовать без доверенности?Может ли один налогоплательщик иметь более одной ЭП?
Удостоверяющий центр ФНС России бесплатно выдает квалифицированные сертификаты исключительно юридическим лицам (лицам, имеющим право действовать от имени юридического лица без доверенности), индивидуальным предпринимателям и нотариусам.
В соответствии с пунктом 37 Порядка реализации Федеральной налоговой службой функций аккредитованного удостоверяющего центра и исполнения его обязанностей, утвержденного Приказом ФНС России от 30.12.2020 № ВД-7-24/982@, отзыв сертификата, выданного УЦ ФНС России, производиться в случае поступления заявления владельца о прекращении действия КСКПЭП или нового заявления на получение КСКПЭП.
Необходимо ли перевыпускать сертификат электронной подписи в случае смены налогоплательщиком реквизитов (паспорт, ФИО и пр.)?Можно ли повторно записать КЭП, в случае нарушения целостность ключа?
Необходимо перевыпустить КСКПЭП в удобной точке выдачи. Услуга бесплатная.
Состав списков отзыва
Перед планированием состава и срока действия списков отзыва необходимо понять назначение списков отзыва и оптимальные параметры в зависимости от условий их эксплуатации. Как известно, каждый ЦС периодически публикует списки отзывов, которые включают списки всех отозванных конкретным ЦС сертификатов.
Даже при наличии высокоскоростных подключений трафик списков отзыва будет существенным по размеру, т.к. все потребители сертификатов нуждаются в актуальной версии списка отзыва. Для уменьшения трафика списков отзыва предусматривают публикацию двух типов CRL:
базовый (Base CRL) и дифференциальные (Delta CRL). Базовый список включает полный список отзыва. Дифференциальный список включает в себя только список отозванных сертификатов, которые были отозваны с момента последней публикации базового CRL. Это позволяет вам публиковать базовый список реже и на более длительный срок, а для ускорения времени реакции клиентов на отозванные сертификаты в промежутке выпускать несколько короткоживущих дифференциальных CRL.
Подбор параметров зависит от несколько факторов. Например, планируемый объём издаваемых сертификатов и планируемый объём отзыва. Рассмотрим типовые сценарии.
Корневой ЦС
Корневой ЦС выписывает сертификаты только промежуточным ЦС, количество которых обычно в пределах десятка. Срок действия промежуточных ЦС сопоставим со сроком жизни сертификата корневого ЦС. Также предполагается, что риск отзыва нижестоящих ЦС весьма низкий, поскольку они управляются обученным персоналом и в отношении них обеспечиваются надлежащие меры безопасности.
Справка: как посчитать планируемый размер файла CRL исходя из объёмов отзыва? Типичный пустой CRL занимает примерно 600-800 байт. Каждая запись об отозванном сертификате занимает 88 байт. Исходя из этих значений можно высчитать размер CRL в зависимости от количества отозванных сертификатов.
Отсюда следует, что на протяжении всей жизни корневого ЦС список отзыва будет в пределах 1кб и смысла в дифференциальном CRL нет.
Издающий ЦС
Для издающего ЦС картина меняется. Объём издаваемых сертификатов уже высок, он может составлять тысячи и миллионы штук. Потребителями являются пользователи и устройства, которые обладают высоким риском отзыва, поскольку они не находятся под постоянным контролем квалифицированного персонала, и невозможно обеспечить надлежащие меры.
Как следствие, список отзыва может достигать серьёзных размеров. Например, если заложить 10% риск отзыва, то на миллион изданных сертификатов приходится порядка 100к отозванных. 100к записей по 88 байт будет составлять немногим меньше 10мб. Очень часто обновлять файл на 10мб не очень практично, целесообразней его публиковать реже, а в интервале между публикациями основного CRL распространять несколько облегчённых дифференциальных Delta CRL. Т.е. если для корневого ЦС достаточно только базового списка отзыва, то для ЦС, выпускающих сертификаты конечным потребителям, следует применять и дельты.