- А что не так с меткой времени и когда она должна заработать?
- Сложный функционал проверки полномочий в дтс
- Какие неочевидные проблемы «краткосрочности» обычной электронной подписи существуют сегодня?
- Выводы: уже куда-то бежать или ждать?
- Постановление девятнадцатого арбитражного апелляционного суда от 25.05.2022 n 19ап-2889/2022 по делу n а64-9083/2022 требование: о признании незаконными действий службы судебных приставов, выраженных в рассмотрении жалоб ооо не по существу. решение: в удовлетворении требования отказано. – консультантплюс
- Как изменит ситуацию появление доверенной третьей стороны?
- Какие решения для обхода «краткосрочности» базовой эп обычно используют?
- Вместо p.s. будущее рынка уц и дтс
- Проблема с подписанием эпц
- Проблемы при авторизации
- Что делать если не найден сертификат или не верен
- Как проявляется данная ошибка и что сделать, чтобы исправить
- Проверка метки доверенного времени
- Что такое метка доверенного времени
- Процесс формирования метки доверенного времени
- Причина №4. для доступа в интернет используется прокси или vpn-сервис
- Проблема с сертификатом
- Причина №7. повреждено скзи
- Причина №3. установлены два криптопровайдера
- Причина №5. доступ к ресурсу заблокирован антивирусом
- Причина №1. на компьютере установлено неправильное время
А что не так с меткой времени и когда она должна заработать?
Подчеркну, что, в первую очередь, меня интересует правовое закрепление использования метки времени и унификация формата ЭП с меткой времени, а не сами расширенные форматы ЭП (основанные на разных международных стандартах), в которых метка времени давно уже используется.
К сожалению, законодатель (до декабря 2022) и регуляторы (до сентября 2020) не раскрывали функционал «метки времени». Отсюда пошли различные несовместимые между собой форматы ЭП. Они вроде бы и являлись усиленными квалифицированными и были выполнены на сертифицированных средствах, но обмен документами с такими ЭП с автоматическим доверием между разными информационными системами в обход системы межведомственного электронного взаимодействия (СМЭВ) был невозможен.
На сегодня с меткой времени больше ясности, но пока она так и не закреплена в нормативно-правовых актах.
«Метка доверенного времени» (именно так указано в законе об ЭП, но я везде пишу просто «метка времени») добавлена изменениями к закону об ЭП от 27.12.2022 г. Правда этот термин упоминается однократно в ст. 2 «Основные понятия, используемые в настоящем Федеральном законе», и больше нигде не используется. Норма о метке времени вступает в силу одновременно с нормой о ДТС (с 01.01.2021 года), поскольку они связаны между собой.
Закон определяет «метку времени» так:
«Достоверная информация в электронной форме о дате и времени подписания электронного документа электронной подписью, создаваемая и проверяемая доверенной третьей стороной, удостоверяющим центром или оператором информационной системы […]».
Таким образом, метка времени может создаваться и проверяться ДТС, УЦ и оператором ИС, если она получена:
«[…]в момент подписания электронного документа электронной подписью в установленном уполномоченным федеральным органом порядке с использованием программных и (или) аппаратных средств, прошедших процедуру подтверждения соответствия требованиям, установленным в соответствии с настоящим Федеральным законом».
Почти год спустя (14 сентября 2020 г.) после появления метки времени в законе об ЭП вышел
«Об утверждении Формата электронной подписи, обязательного для реализации всеми средствами электронной подписи»
. Он, наконец-то:
Далее. В дополнение к приказу Минцифры России № 472 (где, как я написал выше, нет ни определения метки времени, ни ссылки на нее, но есть требование к размещению в составе ЭП
«времени создания ЭП»
) появилось 2 проекта правовых актов:
Очевидно, что ДТС для фиксирования
«определенного момента времени»
также нужна метка времени или сертификат ЭП, срок действия которого еще не истек. Метка времени должна быть одновременно и
«доверенной»
, и
«правильной»
(ДТС должна ее понимать). И, скорее всего, идеальный алгоритм проверки электронных документов с ЭП, в которых реализована метка времени, в ДТС будет следующем:
- Создание электронного документа с ЭП, где ЭП реализована средствами и в формате с поддержкой метки времени (приказ Минцифры России №472).
- Получение метки времени в ДТС или где-то еще (в УЦ или у оператора ИС).
- Встраивание метки времени (выданной «аккредитованным» сервисом – ДТС/УЦ/оператор ИС) в документ с ЭП.
И только если все эти этапы будут пройдены, ДТС сможет
«подтвердить действительность электронной подписи»
со всеми «плюшками и расширенными отчетами». Что из этого следует? Все, кто пожелает использовать ДТС для проверки документов с ЭП после истечения срока действия сертификата ЭП, должны иметь:
Нормативно-правовые акты регуляторов еще не приняты, тем не менее пазл с меткой времен начинает сходиться:
Сложный функционал проверки полномочий в дтс
Вернемся к ДТС и функционалу проверок правильности применения сертификатов ЭП и полномочий. В соответствии с изменениями в законе об ЭП от 27.12.2022 ДТС выступает в том числе в роли «авторизационного» центра, выполняющего:
При этом первый пункт также должен включать проверку правильности применения сертификата квалифицированной электронной подписи (КЭП):
Отдельно разберемся со вторым пунктом – проверкой полномочий. Кроме правильности применения типа сертификата выданного на физлицо, юрлицо или ИП, здесь должна выполняться проверка документа о полномочиях, который должен быть
«подписан КЭП уполномоченного в установленном порядке на принятие соответствующих решений должностного лица соответствующего государственного органа или органа местного самоуправления»
. Сами же полномочия должны быть
«определены на основании классификатора полномочий, который уполномоченный федеральный орган формирует, актуализирует»
. В соответствии со статьями 17.2 и 17.3 закона об ЭП необходимо также проверить наличие и содержимое электронной доверенности, поскольку именно она уполномочивает сторону на те или иные правоотношения. Таким образом, при проверке полномочий ДТС должна также проверять:
Выполнять данные проверки, конечно же, сможет прикладная система. Она понимает контекст электронных правоотношений, знает, какие полномочия и доверенности допустимы с сертификатами КЭП и с какими УЦ можно/нужно работать. Другой вопрос, как будет проводить такие проверки ДТС, ведь она не обладает информацией о контексте правоотношений.
«Авторизационные» операции при использовании сертификатов ЭП, с одной стороны, унифицировались. Специфицированные OID-ы в сертификатах ЭП теперь должны игнорироваться, а схемы авторизаций по принципу свой/чужой OID с 01.06.2020 вне закона. С другой стороны, разграничение полномочий и правила применения сертификатов ЭП трансформировались в более сложные процессы, которые еще должны быть отрегулированы к 01.01.2022.
В
проекте приказа ФСБ России«Об утверждении Требований к средствам доверенной третьей стороны, включая требования к используемым доверенной третьей стороной средствам электронной подписи»
разъяснений по «авторизационным» функциям ДТС так и не последовало. Например, пункт 2.3 проекта требований гласит:
«Компонент проверки полномочий должен осуществлять проверку полномочий должностного лица – отправителя электронного документа, являющегося владельцем сертификата ключа проверки электронной подписи».
Не ясно, где, например, проверка полномочий физического лица, действующего на основании документа о полномочиях или действующего на основании электронной доверенности? И какие именно полномочия должностного лица тут будут проверяться? Будем надеяться, что требования к применению доверенностей и полномочий, которые вступают в силу только с 01.01.2022, еще будут уточнены.
Сам же проект приказа определяет требования к набору компонентов средств ДТС и к функционированию компонентов средств ДТС. Большинство требований технические и организационно-технические и касаются информационной безопасности, что также несомненно очень важно, потому что позволит начать создавать «аккредитованные» ДТС.
Какие неочевидные проблемы «краткосрочности» обычной электронной подписи существуют сегодня?
Я работаю в подразделении, которое занимается прикладной интеграцией. Так сложилось, что нам не приходилось внедрять «штатную» ЭП для документооборота «из коробки» или внедрять готовые клиентские приложения для работы с ЭП. Почти всегда задачи внедрения сводились к встраиванию ЭП (включая разного рода автоматизации по обслуживанию жизненного цикла сертификатов, ключей и их носителей) в существующие и совсем не коробочные документообороты или в информационные системы, в том числе с длительным хранением документов.
На первых этапах проектирования процесс формирования ЭП больших сложностей обычно ни у кого не вызывал. Казалось бы, ну что тут? Сформировать хеш на документ и подписать его закрытым ключом с использованием базовых форматов электронной подписи, например, CAdES-BES или XAdES-BES.
А вот потребность в дальнейшем среднесрочном и долговременном хранение документов с ЭП, проверка ЭП в документообороте (в том числе автоматизированная) всегда в конечном итоге влияли на архитектуру решения. Усложнялись форматы ЭП, начиная от CAdES-T и XAdES-T (с метками времени) и заканчивая их расширенными и специальными «A»-версиями (Archival).
Так как осуществить проверку ЭП документа, хотя бы лет так через 10-15? (Опустим такую подробность, что, скорее всего, спустя столько лет не будет сертифицированных средств криптографической защиты информации (СКЗИ), поддерживающих нужные криптографические алгоритмы и нужные форматы, а необходимые средства просмотра электронных документов не будут запускаться на текущих ОС.)
Обратимся к закону об ЭП (от 06.04.2022 № 63-ФЗ). Какие условия признания (проверки) квалифицированной ЭП содержатся в статье 11 «Признание квалифицированной электронной подписи» (приведу только пункт 2 статьи, потому что именно он влияет на проверку документов с ЭП во времени):
Квалифицированная электронная подпись признается действительной […] при одновременном соблюдении следующих условий:
2) квалифицированный сертификат действителен на момент подписания электронного документа (при наличии достоверной информации о моменте подписания электронного документа) или на день проверки действительности указанного сертификата, если момент подписания электронного документа не определен.
Ключевая информация (особенно в контексте длительного хранения документов) тут взята в скобки. Квалифицированный сертификат не просто должен быть действительным на момент подписания электронного документа, но и сам момент подписания электронного документа должен быть зафиксирован, причем
«достоверно»
, – и это обязательное условие.
Законодатель не предложил и даже не намекнул на способы подтверждения достоверности информации о моменте подписания электронного документа. Впрочем, это нормально. Требования к процедуре должны раскрывать ответственные регуляторы. И спустя 9 лет, после того, как в конце 2022 года вышли изменения к закону об ЭП, Минцифры России и ФСБ России (в части работы с меткой времени, но об этом дальше), наконец-то, разработали проекты приказов.
Пока же бремя доказывания достоверности момента подписания все еще лежит на плечах разработчиков СКЗИ и на владельцах информационных систем. Например, полагаясь на открытые международные спецификации и стандарты, они вынуждены сами выбирать форматы ЭП, в том числе с меткой времени, и ждать, подтвердит или скорректирует их подход судебная практика.
Выводы: уже куда-то бежать или ждать?
«Легализация» хранения и дистанционного использования средствами УЦ облачной ЭП с 01.01.2021 должна запустить новый виток ее развития. Это касается увеличения количества внедряемых услуг на базе ЭП (особенно в наше ковидное время) и удобных сервисов работы с ЭП для мобильных клиентов и клиентов на рабочих местах, которые, в свою очередь, будут нуждаться во внешних обслуживающих сервисах проверки ЭП (на базе ДТС).
Скорее всего, либо под новый год, либо сразу же после праздников упомянутые мною приказы примут. Потом разработчикам СКЗИ потребуется еще месяца 3-4 для корректировки клиентского ПО и библиотек под новый формат ЭП с меткой времени и сервисы служб меток доверенного времени. К слову, последние у ключевых разработчиков СКЗИ уже реализованы и эксплуатируются как TSP-службы штампов времени.
Далее потребуется еще некоторое время на разработку функционала ДТС, явно не завязанного на какие-либо форматы, но необходимого по закону об ЭП:
С учетом всех необходимых доработок ПО, а также организационных процедур на аккредитацию, ждать появления первых ДТС раньше лета 2021 года, думаю, не стоит. Может быть, ФНС и ключевой разработчик СКЗИ выпустят что-то раньше в качестве тестовой версии ДТС.
Услуги ДТС, очевидно, не будут бесплатными для всех, и все затраты прямо или косвенно лягут на участников электронного взаимодействия.
Появление на рынке ДТС должно в итоге способствовать появлению полезных сервисов (в первую очередь, в виде API для встраивания), которые смогут обеспечивать:
Эти сервисы можно будет встраивать в информационные системы, например:
Сервисы найдут применение и в мобильных клиентах разных информационных систем, в том числе для работы с облачной ЭП. Второй вариант соответствует недавно озвученному предложению Максута Шадаева, министра цифрового развития, связи и массовых коммуникаций России:
«Нам кажется, основной сценарий — использование электронной подписи на смартфоне. Такое техническое решение мы с коллегами согласовали, такая возможность есть».
Сказано это было в контексте поддержки министерством инициативы по бесплатной выдаче ЭП пользователям портала госуслуг.
Итого: заявленные изменения в законе об ЭП и предложенный функционал ДТС действительно интересны, долгожданны и обязательно будут востребованы. Метка времени (которая вводится одновременно с ДТС с 01.01.2021) «автоматически» решит проблемы среднесрочного хранения документов.
ДТС и унифицированный формат ЭП с меткой времени позволят осуществлять доверенный оборот документов с ЭП старше 1 года и проверять их после отчуждения из системы. Конечно, многое зависит от реализации, и в том числе от регламентов и приказов Минцифры России и приказов ФСБ России, которые в идеале должны привести к единому знаменателю технические решения по всем ДТС.
Постановление девятнадцатого арбитражного апелляционного суда от 25.05.2022 n 19ап-2889/2022 по делу n а64-9083/2022 требование: о признании незаконными действий службы судебных приставов, выраженных в рассмотрении жалоб ооо не по существу. решение: в удовлетворении требования отказано. – консультантплюс
<noscript><div><img src=”https://mc.yandex.ru/watch/21509128″ style=”position:absolute; left:-9999px;” alt=”” /></div></noscript>
<script type=”text/javascript” >
(function (d, w, c) {
(w[c] = w[c] || []).push(function() {
try {
w.yaCounter21509128 = new Ya.Metrika({id:21509128,
clickmap:true,
trackLinks:true,
accurateTrackBounce:true});
} catch(e) { }
});
(w[c] = w[c] || []).push(function() {
try {
w.yaCounter16796329 = new Ya.Metrika({
id:16796329,
clickmap:true,
trackLinks:true,
accurateTrackBounce:true
});
} catch(e) { }
});
var n = d.getElementsByTagName(“script”)[0],
s = d.createElement(“script”),
f = function () { n.parentNode.insertBefore(s, n); };
s.type = “text/javascript”;
s.async = true;
s.src = “https://mc.yandex.ru/metrika/watch.js”;
if (w.opera == “[object Opera]”) {
d.addEventListener(“DOMContentLoaded”, f, false);
} else { f(); }
})(document, window, “yandex_metrika_callbacks”);
</script>
<noscript><div><img src=”https://mc.yandex.ru/watch/16796329″ style=”position:absolute; left:-9999px;” alt=”” /></div></noscript>
<script type=”text/javascript”>
(function(i,s,o,g,r,a,m){i[‘GoogleAnalyticsObject’]=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,’script’,’//www.google-analytics.com/analytics.js’,’ga’);
ga(‘create’, ‘UA-42995600-1’, ‘ecpexpert.ru’);
ga(function(tracker) {
var dimensionCid = tracker.get(‘clientId’);
ga(‘set’, ‘dimension1’, dimensionCid);
});
ga(‘send’, ‘pageview’);
ga(‘create’, ‘UA-98488889-1’, ‘auto’, {‘name’: ‘Version’});
ga(‘Version.send’, ‘pageview’);
</script>
<script type=”text/javascript”; src=”https://www.ecpexpert.ru/js/counter.js”></script>
<script type=”text/javascript”>
$(‘iframe’).load(function() {
$(this).contents().on(‘click’, ‘.open_doc_goal’, function(event) {
yaCounter21509128.reachGoal(‘Open_doc’);
}).on(‘click’, ‘.open_specprice_goal’, function(event) {
yaCounter21509128.reachGoal(‘Open_Specprice’);
}).on(‘click’, ‘.docOrderBtn’, function(event) {
yaCounter21509128.reachGoal(‘NIV_ozd’);
});
});
</script>
“>
Как изменит ситуацию появление доверенной третьей стороны?
Мы добрались до самого главного. В дополнениях к 63-ФЗ «Об электронной подписи» от 27.12.2022 вместе с целым рядом изменений, в том числе юридическим признанием облачной ЭП, появляется институт доверенной третьей стороны (статья 18.1). Это новый вид организации, которая призвана обеспечить доверие при обмене электронными документами с ЭП.
Законом определяется перечень услуг, которые ДТС будут оказывать участникам электронного взаимодействия:
- по подтверждению действительности электронных подписей, используемых при подписании электронного документа, в том числе установлению фактов того, что соответствующие сертификаты действительны на определенный момент времени, созданы и выданы аккредитованными удостоверяющими центрами, аккредитация которых действительна на день выдачи этих сертификатов;
- по проверке соответствия всех квалифицированных сертификатов, используемых при подписании электронного документа, требованиям, установленным настоящим Федеральным законом и иными принимаемыми в соответствии с ним нормативными правовыми актами;
- по проверке полномочий участников электронного взаимодействия;
- по созданию и подписанию квалифицированной электронной подписью доверенной третьей стороны квитанции с результатом проверки квалифицированной электронной подписи в электронном документе с достоверной информацией о моменте ее подписания;
- по хранению данных, в том числе документированию выполняемых доверенной третьей стороной операций.
Иными словами, появляется аккредитованная организация (а не просто набор сервисов при аккредитованном УЦ), предоставляющая такой необходимый набор услуг:
По сути это все те задачи и соответствующие «аккредитованные» решения по проверке ЭП во времени, которые призваны обеспечить внешний доверенный электронный документооборот с ЭП и минимум среднесрочное хранение документов.
Какие решения для обхода «краткосрочности» базовой эп обычно используют?
Единый стандарт для формата ЭП с меткой времени в процессе разработки. Самым очевидным, с точки зрения среднесрочного (5-10 лет) и долгосрочного хранения документов с ЭП, является реализация квалифицированной ЭП в одном из расширенных форматов (на усмотрение владельца ИС) как минимум:
К менее очевидным и менее распространенным решениям, обеспечивающим проверку ЭП документа через N-лет, относится создание доверенных сред хранения. В такую среду документ с ЭП помещается чаще всего еще во время действия выданного пользователю квалифицированного сертификата ЭП (например, сразу после подписания) с максимальным набором метаданных.
При помещении документа с ЭП в доверенную среду проверяется ЭП, статус сертификата, формируются расширенные отчеты о фактах проверок. После этого целостность документа и всех связанных с ним метаданных обеспечивается доверенной средой. К таким решениям можно отнести, например, и внутренние/отраслевые реестры крупных организаций, в которых регистрируется максимально возможный набор метаданных документа с ЭП (как минимум, атрибуты документа и его хеш, ЭП, идентификатор сертификата и сам сертификат ЭП, факт проверки сертификата с меткой времени, отдельно метка времени на ЭП).
При желании все это может быть подписано сверху технической подписью «архивариуса». В целом это подходит для внутренних нужд крупных компаний и организаций, где документы с ЭП не отчуждаются из системы или сама ЭП первично реализовывалась без метки времени.
Громоздкие доверенные среды хранения документов помогают избегать некоторых потенциальных проблем с компрометацией ЭП, так как подписанный документ сохраняется со всем набором метаданных. Но все же они не способствуют осуществлению электронного документооборота с ЭП между организациями.
Вместо p.s. будущее рынка уц и дтс
И напоследок хотелось бы написать про возможное схлопывание рынка УЦ.
Этим же законом изменен срок аккредитации УЦ с 5 до 3 лет. Аналогичный срок – 3 года – определен для аккредитации ДТС. При этом значительно возросли требования к УЦ. Теперь необходимо:
По оценкам экспертов, увеличение требований к минимальному капиталу приведет к сокращению количества УЦ более чем в 10 раз уже в 2021 (примерно с 450 до 20-40). По аналогии не ожидается и появления значительного количества ДТС, которые, скорее всего, будут созданы при ключевых УЦ (Центробанке, налоговой службе, казначействе), чтобы обслуживать их внутренние потребности. Возможно, они появятся и при нескольких крупных «выживших» коммерческих аккредитованных УЦ.
Пользователям или разработчикам небольших прикладных систем (тех, кто хотел бы внедрить документооборот с облачной ЭП), конечно же, интереснее работать с независимыми от удостоверяющих центров ДТС, а также взаимодействовать со всеми или большинством крупных УЦ.
Существующим УЦ, полагаю, было бы интересно создать свои ДТС. Для них это фактически процессинговый центр по проверке постоянного потока документов с ЭП, выполненный на собственных продуктах и решениях. Тем более что закон явно не запрещает совмещать УЦ и ДТС в одном юрлице.
Проблема с подписанием эпц
Причины, вызывающие подобную ошибку весьма разнообразны. Тут можно выделить такие основные направления:
- Закрытый ключ со съемного носителя (диска, флешки, Токена), не соответствует имеющемуся ключу открытого сертификата. Банальный человеческий фактор выбора не того носителя информации с ЭЦП. Если же «правильный» ключ утерян, придется обращаться в Удостоверяющий центр для перевыпуска.
- Недействительный сертификат. Чтобы устранить подобную ошибку потребуется переустановить открытый сертификат. Важно учитывать требования криптопровайдера (инструкции по необходимым действиям) для установки открытых сертификатов.
- Сертификат подписи определяется как не проверенный. Потребуется выполнить переустановку корневого сертификата, сформировавшего ЭП Удостоверяющего центра.
- Закончился срок действия криптопровайдера. Необходимо получить новый лицензионный ключ, позволяющий работать с программным обеспечением криптопровайдера. Информация запрашивается через УЦ, либо владельца ПО.
- Не виден сертификат на носителе. Помогает простая перезагрузка компьютера для устранения ошибка генерации.
- Алгоритм сертификата ЭЦП не поддерживается. Подобная ошибка может возникать при подписании электронной отчетности в налоговую. Потребуется переустановить КриптоПро CSP и проверить его на совместительство с имеющейся у вас на компьютере операционной системой.
Проблемы при авторизации
Часто с подобными неприятностями сталкиваются владельцы ЭЦП, пытающиеся пройти регистрацию, либо авторизацию на различных электронных торговых площадках. Пользователю появляется уведомление, что его подпись не авторизирована.
Обычно проблема кроется:
- Отсутствие регистрации. Потребуется попросту зарегистрироваться на избранном вами ресурсе.
- Не зарегистрирован сертификат. Возникает после обновления ключа ЭЦП. Устраняется путем регистрации нового сертификата ключа ЭЦП.
В дальнейшем, при работе на самой электронной площадке и попытке подписать электронные документы, могут возникать дополнительные трудности, связанные с такими моментами:
- Необходимости присоединиться к регламенту. Система не даст возможность полноценно работать, если вы не согласитесь с ее условиями.
- Невозможность загрузить файл (файлы). Обычно это ошибка превышения размера информации, что допустима для загрузки. Просто смените формат разрешения файла, чтобы уменьшить его размер.
- Требование использовать определенный браузер (определенную версию браузера). Это системные требования владельца площадки, которые необходимо соблюдать.
- Проблемы со считыванием сертификатов. Потребуется проверить не просрочены ли ваши сертификаты, а также все ли они установлены на ПК.
Что делать если не найден сертификат или не верен
Когда сертификат отсутствует в списке «Ваши Сертификаты», проблема может оказаться в отсутствии коренного сертификата УЦ.
Для устранения этой проблемы необходимо:
- проверить наличие такого сертификата на вашем ПК по пути: «Пуск» — дальше «Все программы» — после этого плагин «КриптоПро» — а уже там «Сертификаты»;
- дальше находим вкладку «Личное», выбираем «Сертификаты»;
- потребуется открыть не отображенный во вкладке сертификат и просмотреть его «Путь сертификации»;
- тут отображаются все цепочки сертификатов в порядке ранжирования. Важно чтобы напротив какого-то из них не стоял желтый, либо красный значок предупреждения. Если подобное присутствует – нажмите на сам сертификат и ознакомьтесь с ошибкой, что выдаст система;
- в зависимости от причины (обычно это окончание действия сертификата, либо не верифицирован) выполните ее устранение.
Чтобы устранить ошибку и перезагрузить отозванный сертификат потребуется выполнить несколько не сложных действий:
Следующей распространенной проблемой, когда компьютер не видит сертификат на носителе, является сбой в работе программных продуктов компьютера либо Токена (флешки). Обычно помогает простая перезагрузка ПК. Среди прочих популярных проблем этого направления можно выделить такие:
Как проявляется данная ошибка и что сделать, чтобы исправить
Ошибка исполнения функции с информированием о невозможности подписать документ ЭЦП обычно появляется в момент подписания документа.
Система сразу выводит на экран уведомление о непредвиденной ошибке с кратким указанием причины ее возникновения.
Обычно для ее исправления требуются такие действия:
- проверка наличия, срока действия, подлинности сертификатов и выполнение их замены;
- выполнение проверки корректной работы операционной системы компьютера, ее обновление до минимальных допустимых параметров;
- проверка состояния съемного носителя закрытого ключа;
- выявление и устранение ошибок работы криптопровайдера.
Важно. Причина, из-за которой владелец ЭЦП не может нею воспользоваться, может быть комплексной. Поэтому, если не сработал один из предложенных вариантов, проверьте по другим направлениям.
Проверка метки доверенного времени
Служба меток доверенного времени проводит проверку меток по следующей схеме:
- Проверка математической корректности ЭП, то есть соответствует ли метка цифровым шаблонам, установленным законодательством.
- Проверка применимости метки к ЭП, для которой она создавалась.
- Сравнение даты и времени в полученной для ЭП метке времени со сроками действия ее сертификата ключа проверки. При этом дата и время должны быть в рамках срока действия сертификата.
- Получение данных об аннулировании сертификата ключа проверки ЭП на момент выдачи метки для нее. Дата и время аннулирования должны быть позже даты и времени в полученной для подписи метке.
Что такое метка доверенного времени
Метка доверенного времени — информация в электронной форме о дате и времени подписания документа электронной подписью, создаваемая и проверяемая доверенной третьей стороной, удостоверяющим центром или оператором информационной системы (ч. 19 ст. 2 закона «Об электронной подписи» от 06.04.2022 № 63-ФЗ, далее — закон об ЭП).
Процесс формирования метки доверенного времени
Этот процесс с технической точки зрения выглядит так:
- Подписание электронного документа стороной правоотношений.
- Проверка электронной подписи по времени поставщика меток.
- Проставление метки времени.
- Усовершенствование подписи с включением метки времени.
Причина №4. для доступа в интернет используется прокси или vpn-сервис
Попросите вашего системного администратора открыть доступ к ресурсам, указанным в технических требованиях. Настройте подключение в СБИС Плагине.
Проблема с сертификатом
Распространенным явлением во время подписания электронных документов ЭЦП является получение уведомления, что системе не удалось получить доступ к сертификатам, пригодным для формирования подписи.
Здесь причины возникновения неисправности могут быть такими:
Причина №7. повреждено скзи
Удалите СКЗИ и установите заново. Это крайняя мера — используйте данное решение, только если не помогло ни одно из предыдущих.
Причина №3. установлены два криптопровайдера
На одном компьютере нельзя работать с несколькими СКЗИ. Удалите оба и заново установите основной криптопровайдер.
Причина №5. доступ к ресурсу заблокирован антивирусом
Попросите вашего системного администратора проверить настройки антивируса. Он не должен блокировать доступ к ресурсам, указанным в технических требованиях.
Причина №1. на компьютере установлено неправильное время
Проверьте, верно ли указано время и часовой пояс на ПК. Если нет, исправьте.