Корневой сертификат что это такое
Корневые и промежуточные сертификаты уполномоченных Удостоверяющих Центров России
Как и многие другие страны, Россия для официального электронного документооборота использует x509 сертификаты, выпускаемые уполномоченными Российскими Удостоверяющими Центрами (УЦ). И в отличие от многих других стран, использует свои собственные шифры.
Я давно хотел автоматизировать проверку подписей ответов органов власти (я много переписываюсь) и проверку «выгрузок» Роскомнадзора на подлинность (по роду общественной деятельности). Самой большой проблемой было достать промежуточные сертификаты из цепочки. Потому что существовал невнятный Excel-файл корневых УЦ на сайте Минсвязи и всё. А промежуточные надо было искать по сайтам соответствующих УЦ. Жизнь — боль.
Что такое «промежуточные сертификаты». Напомню как это работает. Допустим, мы хотим проверить некое подписанное письмо. Письмо подписано ключом. Есть сертификат, который удостоверяет этот ключ. Сертификат кем-то выдан и тоже подписан каким-то ключом с прилагаемым сертификатом. И тот сертификат точно также. И так до момента, когда сертификат выдан сам себе. При проверке мы имеем (принесли, поставили из пакета, нам выдали на флешке) некий набор вот этих конечных сертификатов, которым мы верим. Верим потому что мы верим тому, кто нам их выдал. В мире веба мы верим браузеру и их набору корневых сертификатов. В мире веба при соединении по HTTPS передаются от сервера к клиенту также и промежуточные сертификаты. Поэтому в мире веба у нас всегда есть вся цепочка.
Внезапно (я не знаю точно когда) и незаметно на сайте Госуслуг появилась вот такая ссылочка:
e-trust.gosuslugi.ru/CA
Я наскоро написал программку, которая превращает XML-файл со списком УЦ и сертификатами с этого сайта в привычный PEM формат.
Затем я автоматизировал её и получил постоянно поддерживаемый репозиторий сертификатов в привычном для *NIX мира виде.
Шифрование ГОСТ
Шифрование ГОСТ поддерживается в LibreSSL не помню с какой версии. Но в Alpine Linux от 3.5 уже поддерживается. С OpenSSL всё сложнее. Шифрование ГОСТ идёт с OpenSSL от версии 1.0.0 до версии 1.0.2 включительно. Но например в CentOS шифрования ГОСТ нет. Пользователи CentOS должны страдать. Для Debian, Mint, Ubuntu с OpenSSL версии 1.1.0 и выше требуется установка пакета libengine-gost-openssl1.1, поддерживаемого криптоэнтузиастом Вартаном Хачатуровым (кстати, можно ему помочь).
Ну и в 2018 году у нас есть Docker, а в Alpine Linux, как я уже упоминал, всё работает.
Как это использовать
Короткие примеры для проверки «выгрузки» Роскомнадзора с открепленной подписью. Файл «выгрузки» — dump.xml, открепленной подписи — dump.xml.sig. Даже я проверял их раньше только на целостность подписи, но не на соответствие источнику.
И с этого момента можно не пользоваться сайтом Госуслуг, Контура и странными программами вроде КриптоПро для простой задачи проверки подписи. А главное, что теперь можно и автоматизировать.
Что такое корневой сертификат (СА)
Корневой сертификат (СА) — часть ключа, которым центры сертификации подписывают выпущенные SSL-сертификаты. Выдавая корневой сертификат, каждый такой центр гарантирует, что пользователи или организации, запросившие SSL, верифицированы и действия с доменом легальны.
Центры сертификации с двадцатилетней историей: GlobalSign, Comodo, Symantec, TrustWave, GeoTrust. Они используют «именные» корневые сертификаты, которые распознаются большинством современных браузеров.
Это значит: если на сайт установлен корневой сертификат GlobalSign, браузер идентифицирует его как выпущенный доверенным «поручителем» и приступает к частной проверке сайта.
Если информация о корневом сертификате центра отсутствует в браузере, у сайта нет «поручителя», и браузер считает его недостоверным. Так иногда происходит с самоподписанными сертификатами безопасности (например, Let’s Encrypt):
Однако одного корневого сертификата недостаточно. Чтобы конкретный домен считался защищенным, помимо корневого сертификата необходимы промежуточный сертификат и индивидуальный сертификат домена, которые так же выдаются центром сертификации при выпуске SSL. Достоверность промежуточных и «индивидуальных» сертификатов подтверждается корневым сертификатом. Цепочка сертификатов, установленных на сайт, дает основание считать его «защищенным SSL-сертификатом» в сети Интернет.
Данные вашего сайта под защитой
Установите SSL-сертификат, и ваш сайт будет работать по безопасному соединению HTTPS
Где взять корневой сертификат?
Корневые сертификаты выдают сертификационные центры. REG.RU сотрудничает с шестью сертификационными центрами. Выберите SSL-сертификат, который подходит для ваших целей, и закажите его со страницы SSL-сертификаты.
Также вы можете воспользоваться специальным предложением REG.RU и получить бесплатный SSL-сертификат на 1 год при заказе домена или хостинга. Читайте об этом в статье: Как заказать бесплатный SSL-сертификат?
После заказа SSL и его активации на указанную контактную почту придет письмо с необходимыми данными для установки сертификата на сайт (в частности, корневой сертификат). Подробнее о содержимом письма в статье Где взять данные для установки SSL-сертификата.
Могу ли я создать корневой сертификат самостоятельно?
Чтобы создать корневой сертификат самому, нужно получить статус сертификационного центра. Эта процедура связана со значительными финансовыми затратами, поэтому в большинстве случаев мы рекомендуем обращаться к существующим центрам сертификации.
Установка цепочки сертификатов
Список доверенных сертификатов, использующихся для создания цепочки, приходит в информационном письме после выпуска и активации SSL. Для установки цепочки сертификатов (в том числе, корневого) воспользуйтесь подробными инструкциями справочного раздела: Установка SSL-сертификата.
Корневой сертификат что это такое
Основные понятия PKI
Сертификаты и удостоверяющие центры
Сертификаты
Для того, чтобы обеспечить эти требования, все открытые ключи хранятся и передаются в виде сертификатов.
Сертификат — это набор данных специального формата, содержащий сам открытый ключ и всю информацию о нем: кто владелец, адрес электронной почты владельца, когда ключ создан, назначение ключа (подпись или обмен), для какого алгоритма предназначен ключ и т.д.
Сертификаты являются основным инструментом, которым пользуются различные приложения для криптографической защиты информации. В отличие от секретных ключей, криптопровайдеров и прочих составляющих системы криптографической защиты, которые «неочевидны» пользователю, с сертификатами пользователю непосредственно приходится иметь дело при любых операциях, связанных с защитой информации. Поэтому пользователю необходимо знать, как и для чего используются сертификаты, и уметь с ними работать.
Удостоверяющие центры
Создает (выпускает) сертификаты специальный административный центр, называемый удостоверяющим центром (УЦ) или центром сертификации (ЦС).
Удостоверяющий центр устанавливает определенные требования к работе пользователей. Например, удостоверяющий центр определяет максимальный срок действия сертификатов, совокупность необходимых данных запросе на сертификат, способы передачи запроса от пользователя в УЦ, способы проверки корректности запросов пользователей и т.д.
Совокупность требований удостоверяющего центра называется регламентом удостоверяющего центра.
Удостоверяющий центр имеет собственные ключи подписи и подписывает на них все электронные документы, которые он выпускает.
Удостоверяющий центр выпускает сертификат на собственный открытый ключ. Такой сертификат называется сертификатом удостоверяющего центра.
Таким образом, каждый пользователь в любой момент может, воспользовавшись сертификатом удостоверяющего центра, проверить корректность любого сертификата.
Удостоверяющий центр и пользователи, чьи сертификаты зарегистрированы в удостоверяющем центре, вместе составляют криптосеть.
Криптографические операции и цепочки доверия
Понятие «Проверка подписи» подразумевает проверку соответствия подписи документу, который подписан этой подписью. Если подпись соответствует документу, документ считается подлинным и корректным.
Для проверки подписи используется открытый ключ подписи автора подписи. Но для того, чтобы результат проверки можно было считать надежным, необходимо удостовериться, что сам открытый ключ подписи автора подписи, имеющийся у проверяющего, корректен.
Для этого проводится проверка сертификата на этот ключ. Понятие «проверка сертификата» означает проверку подписи под этим сертификатом. Подпись под сертификатом проверяется на открытом ключе того, кто создал и подписал сертификат — т.е. на открытом ключе удостоверяющего центра.
Т.е. для того, чтобы результат проверки подписи под документом можно было считать надежным, кроме собственно проверки подписи и проверки сертификата на ключ подписи необходимо удостовериться также и в корректности сертификата удостоверяющего центра.
Таким образом, в процессе проверки подписи возникает цепочка сертификатов, каждый из которых проверяется на следующем. Такая цепочка сертификатов называется цепочкой доверия.
То же самое происходит и при зашифровании: прежде чем зашифровать сообщение для владельца открытого ключа обмена, необходимо удостовериться, что данный открытый ключ обмена корректен и подлинен. Для этого необходимо проверить подпись под сертификатом на этот ключ, и возникает точно такая же цепочка доверия.
Корневые сертификаты удостоверяющих центров
В каждой цепочке доверия рано или поздно встречается сертификат, на котором цепочка заканчивается. Т.е. для этого сертификата нет сертификата, на котором его можно было бы проверить.
Такие сертификаты называются корневыми.
Очевидно, что корневым сертификатом в цепочке доверия всегда является сертификат удостоверяющего центра (хотя необязательно каждый сертификат удостоверяющего центра будет корневым—могут, например, существовать сертификаты удостоверяющего центра, подписанные на корневом и т.д.)
Проверить такой сертификат электронными средствами невозможно. Для проверки этих сертификатов используются бумажные распечатки, содержащие определенную информацию: как правило, так называемые цифровые отпечатки, либо сами открытые ключи. Какая именно информация используется для проверки, зависит от регламента удостоверяющего центра.
Цифровой отпечаток документа — это последовательность символов, соответствующая документу таким образом, что каждому документу соответствует свой отпечаток, и по изменению документа нельзя определить, как изменится цифровой отпечаток. Таким образом, можно быть уверенными, что если цифровой отпечаток документа соответствует документу, документ подлинный и корректный. (Эта идея заложена также в основе формирования ЭП).
Для проверки корневого сертификата удостоверяющего центра необходимо получить в удостоверяющем центре бумажную распечатку, содержащую цифровой отпечаток этого сертификата либо открытый ключ, и заверенную подписью администратора удостоверяющего центра и печатью удостоверяющего центра, и сравнить информацию из распечатки с соответствующей информацией, содержащейся в сертификате (увидеть эту информацию можно при просмотре и при установке сертификата).
Если цифровой отпечаток или открытый ключ в распечатке и в сертификате совпадает, корневой сертификат считается корректным. Если цифровой отпечаток или открытый ключ в распечатке и в сертификате не совпадают, значит, файл корневого сертификата искажен. О факте искажения файла сертификата следует немедленно сообщить в удостоверяющий центр—это может означать компрометацию ключей удостоверяющего центра.
Промежуточные сертификаты удостоверяющих центров
Промежуточные сертификаты удостоверяющих центров—это сертификаты на ключи удостоверяющих центров, не являющиеся корневыми. Т.е. это сертификаты удостоверяющих центров, подписанные на других сертификатах удостоверяющих центров.
Если в цепочке доверия присутствует промежуточный сертификат удостоверяющего центра, она оказывается трехзвенной:
Корневой сертификат УЦ—промежуточный сертификат УЦ—сертификат пользователя.
Более длинные цепочки (с несколькими промежуточными сертификатами) возможны, но встречаются очень редко.
Запрос на сертификат на открытый ключ
Для того чтобы удостоверяющий центр выпустил сертификат на открытый ключ пользователя, пользователю необходимо отправить в удостоверяющий центр запрос на этот сертификат.
Точный набор данных, включаемых в запрос, определяется регламентом удостоверяющего центра. В запрос обязательно включается имя пользователя, назначение запрашиваемого сертификата (подпись или обмен), а также сам открытый ключ, на который создается сертификат. Таким образом, к моменту формирования запроса открытый ключ уже должен существовать.
Конец срока действия сертификата
Каждый сертификат имеет ограниченный срок действия. Конкретный максимальный срок действия сертификата устанавливается регламентом УЦ, но обычно он не превышает одного года.
По истечении срока действия сертификат становится недействительным.
По истечении срока действия сертификата удостоверяющего центра необходимо получить и установить в системе новый.
По истечении срока действия сертификата на открытый ключ пользователя необходимо сформировать запрос на новый сертификат.
Это может быть запрос на сертификат на уже существующие ключи или на новые ключи. Можно ли получать новые сертификаты на уже существующие ключи или необходимо создавать новые ключи после окончания срока действия сертификата, определяется регламентом удостоверяющего центра.
Отзыв сертификата
Существует ряд причин, по которым действие сертификата бывает необходимо прекратить до окончания его срока действия.
В таких ситуациях удостоверяющий центр отзывает соответствующий сертификат.
Если владелец ключей считает нужным отзыв имеющегося у него сертификата, ему необходимо сообщить об этом в удостоверяющий центр. Особенно это важно при компрометации ключей. Если владельцу ключей становится известно о факте их компрометации, ему необходимо сообщить о факте компрометации в удостоверяющий центр как можно скорее.
Удостоверяющий центр отзывает соответствующий сертификат, т.е. заносит его в так называемый список отзыва сертификатов (CRL — Certificate Revocation List). Все сертификаты, числящиеся в списке отзыва сертификатов, недействительны. Список отзыва сертификатов доводится до сведения всех пользователей в соответствии с регламентом удостоверяющего центра.
Владелец отозванного сертификата отправляет в удостоверяющий центр запрос на новый сертификат. Необходимость создания новых ключей в этом случае определяется конкретной ситуацией: если старые ключи скомпрометированы, необходимо создать новые; если речь идет о замене сертификата вследствие изменения актуальной информации о владельце, достаточно создать запрос на новый сертификат на имеющиеся ключи.
Для того чтобы быть полностью уверенным в подлинности и корректности подписи под сообщением, необходимо проверить, не отозван ли сертификат на ключ, на котором выработана проверяемая подпись, т.е. не включен ли этот сертификат в список отзыва сертификатов.
Российские ЭП для самых маленьких
Цифровой документооборот входит в нашу жизнь уверенными шагами и если для юридических лиц это уже суровые будни, то многие физические лица могли с этим еще не столкнуться. Но со временем оставаться в стороне становится всё сложнее и нужно приспосабливаться к меняющимся условиям, иначе можно получить не совсем приятные последствия.
Заключение договоров — дело привычное. Их заключают в банках, в больницах, при покупке мебели, оплате обучения. Прочитать договор, проверить реквизиты юридического лица, с которым заключается договор, убедиться в наличии печати и подписи — стандартная процедура, которая уменьшает риск обмана. Однако приобретённые навыки работы с бумажными договорами не могут просто так перейти в цифровой мир в силу специфики электронных документов.
В этой статье хочется рассказать о своем опыте знакомства с российскими электронными подписями (ЭП), которые используются для подписания договоров с физическими лицами в том числе и страховыми компаниями, а также подводных камнях, на которые наткнулся при этом.
Для меня эта история началась при заключении договора со страховой компанией ООО СК “Сбербанк страхование”. После оформления мне показались подозрительными некоторые факты (небольшой спойлер: всё оказалось хорошо) и я стал разбираться, как же мне проверить, что полученный документ действительно выдан страховой компанией, а не некими третьими лицами.
После расчёта суммы в калькуляторе на сайте и заполнения формы с паспортными и контактными данными мне на электронную почту пришло письмо, в котором кроме общей информации, полезных ссылок и контактов было 3 вложения: памятка, правила страхования и сам полис. Я ознакомился с документами, оплатил страховку и стал ждать подписанную версию полиса.
Через полчаса ожидания я стал волноваться, быстрый поиск показал, что у страховой компании есть аж 3 разных активных домена: www.sberbank-insurance.ru, www.sberins.ru и sberbankins.ru, что не добавляло мне уверенности в компании.
Звонок в контакт центр принёс информацию о том, что присланный полис и является финальным документом с ЭП страховой компании. Мне показалось странным, что компания отдаёт уже подписанный документ еще до факта оплаты клиентом и я стал проверять полученный pdf файл.
Глава первая: проверка ЭП
Все манипуляции с PDF документом приведены в чистой версии ОС Windows 10, русская домашняя редакция, как наиболее вероятной среде работы простого пользователя. Набор софта, используемый в статье, также является непрофессиональным и доступным для всех.
Для начала я открыл документ в просмотрщике Foxit Reader, который использую как основной:
Это выглядит очень и очень подозрительно — документ модифицирован непонятно кем, сертификат также не является доверенным. Система не может проверить цепочку доверия для данного сертификата и помечает его недействительным.
Кроме имени организации, которой выдан сертификат, видно наименование выдавшей его организации, ООО “ИТК”. Поиск по запросу “ООО ИТК сертификат” вывел меня на страницу Установка корневого сертификата Удостоверяющего центра ООО «ИТК». Это официальный сайт ООО «Интернет Технологии и Коммуникации», который является одним из удостоверяющих центров, выдающих сертификаты ЭП.
Следуем инструкции: нам нужно пройти по ссылке и скачать с Google Drive (!) RAR архив (!!) «Корневой квалифицированный.rar» (который ещё надо найти чем открыть, пришлось ставить 7-zip) и видим там 2 сертификата: корневой и промежуточный. Корневой выдан Минкомсвязи самим себе, а промежуточный — министерством для ООО “ИТК”. Устанавливаем их, соглашаемся с добавлением корневого сертификата (краем глаза замечая, что sha1 отпечаток устанавливаемого ключа и картинки в инструкции совпадает, но про такое сравнение в пунктах установки ничего нет).
Снова открываем сертификат из документа. И чуда не произошло, цепочка доверия от корневого до конечного не строится!
Изучаем ЭП подробнее: в Foxit Reader есть дополнительная информация о свойствах подписи:
Ага, алгоритм хеширования ГОСТовский, ЭП создана в КриптоПро PDF. Возможно, Windows не знает про ГОСТ шифрование и поэтому ему нужен дополнительный криптопровайдер.
Идём на сайт КриптоПро, регистрируемся, скачиваем пробную версию КриптоПро CSP 5.0 на 3 месяца. Что будет дальше — не совсем понятно, возможно всё превратится в тыкву, посмотрим.
Снова открываем просмотр сертификата ЭП:
Выглядит уже лучше. Видно, что система считает сертификат действительным, построена цепочка от корневого сертификата через промежуточный.
Сообщение о проверке немного улучшилось, но всё равно Foxit Reader не может проверить сертификат (вероятно дело в ГОСТовском алгоритме):
В Adobe Acrobat Reader DC проверка тоже не успешна:
И на этом вроде бы можно остановиться: Foxit Reader подтверждает, что документ не был изменен после подписания, руками можно проверить, что сертификат подтверждается системой и действителен. Но всё же хочется довести дело до конца, чтобы хотя бы одна программа сказала: да, документ действителен, всё хорошо.
Вспоминаем, что полис подписан в программе КриптоПро PDF. Вероятно, что раз она может создавать такие подписи, то уж наверняка должна их и проверять. Ставим.
+1 триал версия на 90 дней, хотя вроде бы надпись при установке успокаивает, что при использовании продукта в Adobe Acrobat Reader DC лицензия не нужна.
Ура, долгожданное сообщение о том, что всё хорошо.
Подведем промежуточный итог. Для проверки действительности ЭП на документе нужно:
Глава вторая: ещё одна ЭП
Порывшись в почте, я нашел еще один электронный договор. По счастливой случайности, им тоже оказался страховой полис, но на этот раз еОСАГО от АО “Тинькофф Страхование”. Открываем сертификат, смотрим выпустившую сертификат организацию. Ей оказывается АО “Тинькофф банк”. Да, оказывается у них есть свой УЦ, который выдает сертификаты дочерним организациям (у Сбербанка тоже есть свой УЦ, но в дочерних структурах он не используется).
По отработанному алгоритму идём в поисковую систему с запросом “тинькофф сертификат”, находим официальный сайт УЦ АО Тинькофф Банк. Тут нас встречает изобилие ссылок на корневые сертификаты, списки отозванных сертификатов и даже видеоинструкция по их установке. Скачиваем “Цепочка корневых сертификатов УЦ АО Тинькофф Банк ГОСТ Р 34.10.2012”, на этот раз ссылка ведёт не на сторонний сервис, а на сайт банка. Формат файла P7B не очень известный, но открывается Windows без установки стороннего софта и показывает находящиеся в нём сертификаты. Здесь уже привычный корневой сертификат от Минкомсвязи (другой, не тот, что в первом случае) и промежуточный сертификат УЦ банка.
Ставим оба, проверяем сертификат в полисе. Но нет, сертификат не является доверенным, т.к. система не может подтвердить поставщика сертификата. На сайте УЦ было 2 ссылки на 2 цепочки сертификатов, один для ГОСТ Р 34.10.2001, другой для ГОСТ Р 34.10.2012. Полис был выпущен в этом году, логичнее бы его подписать уже более современным криптоалгоритмом (тем более уже есть версия ГОСТ от 2018 года, алгоритмы обновляются довольно часто), но давайте проверим старый.
В новом файле формата P7B оказывается уже 3 файла сертификатов. Можно поставить все 3, однако стоит заметить, что сертификат “Головного удостоверяющего центра” мы поставили в первой главе из RAR архива ООО “ИТК”, они идентичны. А сертификат с не очень говорящим названием “УЦ 1 ИС ГУЦ” поставил КриптоПро CSP, т.к. галочка об установке корневых сертификатов была установлена по-умолчанию в его инсталляторе. Единственным новым является сертификат АО “Тинькофф Банк”, который мы и ставим.
После установки сертификатов из “Цепочка корневых сертификатов УЦ АО Тинькофф Банк ГОСТ Р 34.10.2001” путь в сертификате прорисовался и система радостно сообщила, что он является доверенным. Adobe Acrobat Reader DC также подтвердил, что подпись действительна.
На этом приключения с проверкой ЭП на полисе еОСАГО завершаются. Заметно, что после того, как в системе уже установлен необходимый софт, а пользователь понимает принципы работы и поиска промежуточных сертификатов, то проверка подписи занимает уже меньше времени.
Но проблемные места по-прежнему видны: необходимо искать в интернете официальные сайты удостоверяющих центров, разбираться в инструкциях по установке сертификатов. Даже при установленных корневых сертификатах необходимо искать промежуточный, иначе цепочка доверия будет не полной и система не сможет подтвердить достоверность подписи.
Глава третья: немного про корневые и промежуточные сертификаты
Проделав всю эту работу, меня не покидало чувство, что вся система построена не очень безопасно, требует от пользователя кучу дополнительных операций и доверия многим факторам: от поисковой системы, которая может не выдать первой строкой официальный сайт УЦ, до работы самого персонала УЦ, который выкладывает сертификаты без контрольных сумм на сторонние веб сервисы в проприетарных форматах контейнеров.
За дополнительной информацией я пошёл на сайт Минкомсвязи и нашёл такую страницу. Там можно скачать XLS файл, в котором будут перечислены все имеющие в настоящий момент аккредитацию УЦ, а также УЦ с приостановленной и прекращенной аккредитацией. В списке аккредитованных находится 494 УЦ, что немало.
Однако просто списка недостаточно, нужны хотя бы ссылки на сайты этих УЦ, а также надо найти корневые сертификаты непосредственно от первоисточника, Минкомсвязи. Следующий точкой в поиске этой информации стал портал pravo.gov.ru, где перечислены ссылки на некоторые корневые сертификаты. Страница доступна только по http протоколу, контрольных сумм опять нет.
Приглядевшись, можно заметить, что первые 4 ссылки ведут на портал https://e-trust.gosuslugi.ru. Не совсем понятно, почему именно поддомен сайта госуслуг стал центральным в системе корневых сертификатов, но, кажется, тут приведена вся актуальная информация по корневым и промежуточным сертификатам.
На странице головного УЦ https://e-trust.gosuslugi.ru/MainCA приведены 10 корневых сертификатов от Минкомсвязи, для разных ГОСТ алгоритмов и с разными сроками действия. Тут же доступны слепки ключей, можно проверить, что скачанный сертификат никто не подменил. Сам сайт имеет сертификат от Thawte.
На странице аккредитованных УЦ https://e-trust.gosuslugi.ru/CA находится полный список промежуточных удостоверяющих центров, можно скачать их сертификаты, проверить слепок. Кроме этого вся информация доступна в формате XML. Одним разом можно получить файл с данными о всех промежуточных УЦ, а также их сертификаты и ссылки для получения списка отозванных сертификатов.
У сертификатов есть поле точки распространения списка отзывов (CRL), в котором прописан путь получения списка отозванных сертификатов. При проверке ЭП на каком-то документе кроме установки промежуточного и корневых сертификатов нужно также установить и последний список отозванных и обновлять его перед каждой проверкой (данная процедура автоматизируется специализированным софтом, но штатные средства вроде бы так не умеют). На портале e-trust у каждого сертификата указан путь к такому списку и он может отличаться от того, что написано в самом сертификате. Чему верить? Не совсем понятно.
В заключение статьи хочется отметить, что проверка ЭП на электронных документах по силам каждому, однако это не совсем тривиальный процесс, требующий некоторых знаний. Возможно, что в будущем этот процесс упростится. Кроме этого остается открытым вопрос проверки ЭП на мобильных устройствах, а ведь они сейчас стали основным инструментом пользователей, давно опередив персональные компьютеры.
После написания статьи осталось несколько открытых вопросов, которые хотелось бы обсудить с сообществом:
UPD 0: В комментариях подсказали онлайн сервис на портале госуслуг для проверки ЭП документов: https://www.gosuslugi.ru/pgu/eds. К сожалению, не заработало в моём случае, но может быть полезно.
UPD 1: После написания статьи мне подсказали, что есть ещё один криптопровайдер, ViPNet CSP, который тоже может помочь с ГОСТовскими криптоалгоритмами в системе. Одновременная установка его с КриптоПро CSP под вопросом.