Цифровая подпись программы недействительна программа теперь выйдет что это

Ошибка «Этот сертификат содержит недействительную подпись» возникает при работе с личными сертификатами, которые используются для подписи электронных документов с использованием КриптоПРО. На разных форумах предлагают разные решения и судя по отзывам многие из них действительно помогают. Один из таких советов меня подтолкнул к решению проблемы. Я хочу поделиться всеми способами решения, которые я узнал, потому-что причины появления этой ошибки могут быть разными.

Наиболее частая причина появления ошибки «Этот сертификат содержит недействительную подпись» кроется в некорректных путях сертификации от личного сертификата до головного удостоверяющего центра, поэтому ее рассмотрим в первую очередь.

Другие причины появления ошибки: неисправность алгоритмов шифрования КриптоПРО CSP и нарушение прав доступа к ветке реестра.

Некорректный путь сертификации

Эта та самая проблема, с которой пришлось столкнуться мне.
Удивительно, но при такой ошибке одни сайты без проблем работают с сертификатом, а другие его просто не замечают. Вероятно, в тех случаях, когда такой сертификат действует, не проверяется путь до головного удостоверяющего центра.

Как подписать программу цифровой подписью

Чтобы устранить ошибку «Этот сертификат содержит недействительную подпись» необходимо восстановить всю цепочку сертификации, установив в хранилище сертификаты всех промежуточных УЦ и Головного удостоверяющего центра.

Открываем хранилище сертификатов при помощью консоли certmgr.msc

Переходим в Личное/Сертификаты. Открываем сертификат, который не работает и переходим на вкладку Путь сертификации.

Как видно на рисунке в качестве корневого удостоверяющего центра указан «Минкомсвязь России», а промежуточного удостоверяющего центра ООО «КОМПАНИЯ «ТЕНЗОР».

В поле состояние сертификата наблюдаем ошибку: «Этот сертификат содержит недействительную подпись».

Теперь нам надо отследить всю цепочку сертификатов, которая содержит промежуточные сертификаты и сертификат головного удостоверяющего центра.

Вернемся на вкладку «Общие», чтобы проверить кем выдан личный сертификат. Сертификат выдан той же организацией, что указана в пути сертификации в качестве промежуточно центра. Здесь все правильно.

Переходим в Промежуточные центры сертификации и проверяем промежуточный сертификат. Здесь видно сообщение «Этот сертификат не удалось проверить, проследив его до удостоверяющего центра сертификации». Вот то место где обрывается путь.

Как отключить проверку подписи для загруженных программ

Переходим по ссылке http://e-trust.gosuslugi.ru/CA и находим свой удостоверяющий центр.

Находим в списке сертификат, который соответствует условиям.
Средства УЦ: КриптоПРО УЦ 2.0
Кем выдан: CN=Головной удостоверяющий центр
Действует: текущая дата входит в указанный промежуток дат.

Щелкаем по ссылке в поле «Отпечаток» и скачиваем сертификат.

Этот сертификат необходимо установить в промежуточные центры сертификации.

Переходим в личные сертификаты и проверяeм путь сертификации. Если ошибка исчезла значит все сделано правильно.

В дополнение приведу советы с различных форумов, которые так же помогали в устранении данной ошибки.

Не работают алгоритмы шифрования КриптоПРО CSP

Открываем КриптоПРО CSP и переходим на вкладку «Алгоритмы».
Если увидите, что поля алгоритмов пустые значит программа работает некорректно. Переустановите КриптоПРО CSP.

Для переустановки КриптоПРО CSP может потребоваться инструмент «Утилита очистки следов установки КриптоПРО» для полного удаления программы из операционной системы. Скачать его можно отсюда .

Нарушение прав доступа к ветке реестра.

Решить эту проблему так же поможет полное удаление КриптоПРО CSP с использованием указанной ранее утилиты по очистке следов программы.

Если не поможет, то попробуйте предоставить пользователю, работающему с КриптоПРО CSP, права администратора.

Источник: soft-setup.ru

Устранение ошибок подписи пакета приложения

Сбой развертывания приложения может быть вызван сбоем проверки цифровой подписи пакета приложения. Узнайте, как распознать эти сбои и что делать с ними.

При развертывании упаковаемого приложения Windows Windows всегда пытается проверить цифровую подпись в пакете приложения. Сбои во время развертывания блока проверки подписи пакета. Но почему пакет не был проверен, может быть неявным. В частности, если вы подписываете пакеты с помощью частных сертификатов для локального тестирования, часто необходимо управлять доверием для этих сертификатов. Неправильная конфигурация доверия сертификатов может привести к сбоям проверки подписи.

Это важно знать

Технологии

• Упаковка, развертывание и запрос приложений Windows
• Проверка доверия сертификатов

Предварительные требования

• Windows журнал событий для диагностики сбоев установки.
• Задачи Certutil для управления сертификатами для манипуляции с хранилищем сертификатов во время устранения неполадок

Инструкции

Шаг 1. Изучение журналов событий для получения диагностических сведений

В зависимости от того, как вы пытались развернуть приложение, возможно, вы не получили значимый код ошибки для сбоя развертывания. В этом случае код ошибки обычно можно получить непосредственно из журналов событий.

Получение кода ошибки из журналов событий

1. Запустите eventvwr.msc.
2. Перейдите в раздел Просмотр событий (локальные)>приложения и службы LogsMicrosoft> >Windows.
3. Первый журнал для проверки — AppxPackagingOMMicrosoft-Windows-AppxPackaging/Operational. >
4. Ошибки, связанные с развертыванием, записываются в AppXDeployment-ServerMicrosoft-Windows-AppXDeploymentServer/Operational. > Для ошибок развертывания найдите последнее событие ошибки 404. Это событие ошибки содержит код ошибки и описание причины сбоя развертывания. Если событие ошибки 465 предшествовало событию 404, возникла проблема при открытии пакета.

Если ошибка 465 не произошла, ознакомьтесь с общими сведениями об устранении неполадок, связанных с упаковкой, развертыванием и запросом приложений Windows. В противном случае ознакомьтесь с этой таблицей для распространенных кодов ошибок, которые могут отображаться в строке ошибки для события ошибки 465:

Код ошибки Error Описание Предложение

0x80073CF0	ERROR_INSTALL_OPEN_PACKAGE_FAILED	Не удалось открыть пакет приложения.	Эта ошибка обычно указывает на проблему с пакетом. Необходимо создать и подписать пакет еще раз. Дополнительные сведения см. в разделе «Использование упаковщика приложений».
0x80080205	APPX_E_INVALID_BLOCKMAP	Пакет приложения был изменен или имеет недопустимую карту блоков.	Пакет поврежден. Необходимо создать и подписать пакет еще раз. Дополнительные сведения см. в разделе «Использование упаковщика приложений».
0x800B0004	TRUST_E_SUBJECT_NOT_TRUSTED	Пакет приложения был изменен.	Содержимое пакета больше не соответствует его цифровой подписи. Вам нужно снова подписать пакет. Дополнительные сведения см. в разделе «Как подписать пакет приложения с помощью SignTool».
0x800B0100	TRUST_E_NOSIGNATURE	Пакет приложения не подписан.	Можно развернуть только подписанные Windows пакеты приложений. Сведения о подписании пакета приложения см. в разделе «Как подписать пакет приложения с помощью SignTool».
0x800B0109	CERT_E_UNTRUSTED_ROOT	Цепочка сертификатов, используемая для подписывания пакета приложения, заканчивается корневым сертификатом, который не является доверенным.	Перейдите к шагу 2, чтобы устранить неполадки доверия с сертификатом.
0x800B010A	CERT_E_CHAINING	Цепочка сертификатов не может быть создана для доверенного корневого центра из сертификата, который использовался для подписи пакета приложения.	Перейдите к шагу 2, чтобы устранить неполадки доверия с сертификатом.

Шаг 2. Определение цепочки сертификатов, используемой для подписи пакета приложения

Чтобы выяснить сертификаты, которым должен доверять локальный компьютер, можно проверить цепочку сертификатов для цифровой подписи в пакете приложения.

Определение цепочки сертификатов

1. В проводник щелкните правой кнопкой мыши пакет приложения и выберите пункт «Свойства».
2. В диалоговом окне «Свойства» выберите вкладку «Цифровые подписи» , в которой также отображается возможность проверки подписи.
3. В списке подписей выберите подпись и нажмите кнопку «Сведения «.
4. В диалоговом окне сведений о цифровой подписи нажмите кнопку «Просмотреть сертификат «.
5. В диалоговом окне «Сертификат» выберите вкладку «Путь сертификации «.

Верхний сертификат в цепочке — это корневой сертификат, а нижний — сертификат подписи. Если в цепочке находится только один сертификат, сертификат подписи также является собственным корневым сертификатом. Вы можете определить серийный номер для каждого сертификата, который затем используется с Certutil:

Определение серийного номера для каждого сертификата

1. В области пути сертификации выберите сертификат и нажмите кнопку «Просмотреть сертификат».
2. В диалоговом окне «Сертификат» выберите вкладку «Сведения» , в которой отображается серийный номер и другие полезные свойства сертификата.

Шаг 3. Определение сертификатов, доверенных локальным компьютером

Чтобы иметь возможность развернуть пакет приложения, он должен быть не только доверенным в контексте пользователя, но и в контексте локального компьютера. В результате цифровая подпись может отображаться допустимой при просмотре на вкладке «Цифровые подписи» из предыдущего шага, но при развертывании пакета приложения по-прежнему завершается сбоем.

Чтобы определить, является ли цепочка сертификатов, используемая для подписи пакета приложения, является ли он доверенным локальным компьютером.

Выполните следующую команду:

CertUtil.exe -store Root rootCertSerialNumber
CertUtil.exe -store TrustedPeople signingCertSerialNumber

Если не указать серийный номер сертификата, Certutil выводит список всех сертификатов, доверенных локальным компьютером для этого хранилища.

Пакет может не установиться из-за ошибок цепочки сертификатов, даже если сертификат подписи не является самозаверяющим, а корневой сертификат находится в корневом хранилище локального компьютера. В этом случае может возникнуть проблема с доверием для промежуточных центров сертификации. Дополнительные сведения об этой проблеме см. в разделе «Работа с сертификатами».

Remarks

Если вы определили, что пакет не удалось развернуть, так как сертификат подписи не является доверенным, не устанавливайте пакет, если вы не знаете, где он был создан, и вы доверяете ему.

Если вы хотите вручную доверять приложению для установки (например, для установки собственного пакета приложения, подписанного тестом), вы можете вручную добавить сертификат в доверие к сертификату локального компьютера из пакета приложения.

Добавление сертификата вручную в доверие к сертификату локального компьютера

1. В проводник щелкните правой кнопкой мыши пакет приложения и в всплывающем контекстном меню выберите «Свойства».
2. В диалоговом окне «Свойства» выберите вкладку «Цифровые подписи «.
3. В списке подписей выберите подпись и нажмите кнопку «Сведения «.
4. В диалоговом окне сведений о цифровой подписи нажмите кнопку «Просмотреть сертификат «.
5. В диалоговом окне «Сертификат» нажмите кнопку «Установить сертификат. «.
6. В мастере импорта сертификатов выберите локальный компьютер и нажмите кнопку «Далее». Чтобы продолжить, необходимо предоставить права администратора.
7. Выберите «Поместить все сертификаты в следующее хранилище » и перейдите в хранилище «Доверенные люди «.
8. Нажмите кнопку «Далее», а затем нажмите кнопку «Готово «, чтобы завершить работу мастера.

После этого добавления вручную вы увидите, что сертификат теперь является доверенным в диалоговом окне «Сертификат «.

Сертификат можно удалить после того, как он больше не нужен.

Удаление сертификата

1. Запустите Cmd.exe от имени администратора.
2. В командной строке администратора выполните следующую команду:

Certutil -store TrustedPeople
Certutil -delStore TrustedPeople certID

Рекомендуется избегать ручного добавления корневых сертификатов в хранилище сертификатов доверенных корневых центров сертификации локального компьютера.

Наличие нескольких приложений, подписанных сертификатами, которые связаны с тем же корневым сертификатом, например бизнес-приложениями, могут быть более эффективными, чем установка отдельных сертификатов в хранилище доверенных лиц. Хранилище «Доверенные люди» содержит сертификаты, которые считаются доверенными по умолчанию, поэтому не проверяются более высокими центрами сертификации или списками доверия сертификатов или цепочками. Рекомендации по добавлению сертификатов в хранилище сертификатов доверенных корневых центров сертификации см. в разделе «Рекомендации по подписи кода».

Вопросы безопасности

Добавив сертификат в хранилища сертификатов локальной машины, вы меняете доверие сертификатов всех пользователей на компьютере. Рекомендуется установить все сертификаты подписи кода, которые требуется для тестирования пакетов приложений в хранилище сертификатов доверенных лиц. Немедленно удалите эти сертификаты, когда они больше не нужны, чтобы предотвратить их использование для компрометации доверия системы. Если вы создаете собственные тестовые сертификаты для подписывания пакетов приложений, мы также рекомендуем ограничить привилегии, связанные с тестируемым сертификатом. Сведения о создании тестовых сертификатов для подписывания пакетов приложений см. в статье «Создание сертификата подписи пакета приложения».

Связанные темы

Примеры

Основные понятия

Источник: learn.microsoft.com

Цифровые подписи в исполняемых файлах и обход этой защиты во вредоносных программах

Хабрапривет!

Ну вроде как удалось решить вопросы с кармой, но они ником образом не касаются сегодняшней темы, а лишь объясняют некоторое опоздание её выхода на свет (исходные планы были на ноябрь прошлого года).

Сегодня я предлагаю Вашему вниманию небольшой обзор по системе электронных подписей исполняемых файлов и способам обхода и фальсификации этой системы. Также будет рассмотрен в деталях один из весьма действенных способов обхода. Несмотря на то, что описываемой инфе уже несколько месяцев, знают о ней не все. Производители описываемых ниже продуктов были уведомлены об описываемом материале, так что решение этой проблемы, если они вообще считают это проблемой, на их ответственности. Потому как времени было предостаточно.

ТЕОРИЯ

Идея и технология электронной подписи для исполняемых файлов возникла ещё в эпоху Windows NT. C момента появления Windows Vista компания Microsoft начала активную компанию по продвижению этой технологии. По задумке производителя, подписанный код может идти только от доверенного автора этого кода, а следовательно гарантированно не наносит вреда системе и защищён от ошибок (три ха-ха).

Тем не менее, поскольку в механизме подписи чаще всего используется довольно сложный криптоустойчивый механизм, общее доверие к подписанному коду распространилось. Не ушли от этого и антивирусные вендоры. Верно: если код подписан, то он явно не может быть вирусом, а потому ему можно доверять априори, тем самым снизив вероятность ложных срабатываний. Поэтому в большинстве современных антивирусных продуктов по умолчанию стоит обход проверки подписанных файлов, что повышает скорость сканирования и снижает вероятность ложных срабатываний. Более того, зачастую подписанные программы автоматически заносятся в категорию «доверенных» поведенческих анализаторов ака хипсов.

Становится ясно, что подписав свои творения валидной подписью, вирусмейкер получает довольно богатую аудиторию клиентов, у которых даже с активным и регулярно обновляемым антивирусом произойдёт заражение. Очевидно, что это — весьма лакомый кусочек, что легко заметно на примере уже ставшего знаменитым вируса Stuxnet, где код был подписан валидными сертификатами Realtek (позже сообщалось и о подписях от JMicron).

Но у этого подхода есть и оборотная сторона: после выявления скомпрометированной подписи она немедленно отзывается, а по самому факту подписи АВ-вендоры ставят сигнатурный детект, понятно, что с 100%-ным срабатыванием. Учитывая то, что приобрести украденный сертификат, необходимый для подписывания крайне дорого, ясно, что вирусмейкеры заинтересованы в тотальном обходе механизма проверки подписи, без валидных private-ключей или с помощью самостоятельной генерации таких ключей. Это позволит обходить защиту не только антивирусных продуктов, но и устанавливать драйвера и ActiveX-компоненты без предупреждений, да и вообще как-то пробиться в мир х64, где без подписей ничего не установить вообще.

Но об этом — подробнее на практике.

Кто-то из великих сказал, что чтобы опередить врага, надо начать мыслить как он. Итак, если мы вирусмейкеры, то что мы можем сделать?

1. Скопировать информацию о сертификате с какого-нибудь чистого файла.

Это наиболее популярный способ на данный момент. Копируется информация подписи до мельчайших подробностей, вплоть до цепочки доверенных издателей. Понятно, что такая копия валидна только на взгляд пользователя. Однако то, что отображает ОС вполне может сбить с толку неискушённого и быть воспринято как очередной глюк — ещё бы, если все издатели правильные, то почему это подпись невалидна? Увы и ах — таких большинство.

2. Использовать самоподписанные сертификаты с фэйковым именем.

Аналогично выше описанному варианту за исключением того, что даже не копируется цепочка в пути сертификации.

3. Подделать MD5.

Несмотря на то, что слабость алгоритма MD5 уже давно описана (тут и тут), он до сих пор часто используется в электронных подписях. Однако реальные примеры взлома MD5 касаются или очень маленьких файлов, или приводят к неправильной работе кода. На практике не встречаются вирусы с поддельными взломанными подписями на алгоритме MD5, но тем не менее такой способ возможен теоретически.
4. Получить сертификат по обычной процедуре и использовать его в злонамеренных целях.

Одна из наиболее распространённых методик авторов так называемых riskware, adware и фэйковых антивирусов. Примером может послужить фэйковый Perfect Defender (стандартный развод: «просканируйтесь бесплатно — у вас вирус — заплатите нам и мы его удалим») существует с подписями нескольких контор:
• Jeansovi llc
• Perfect Software llc
• Sovinsky llc
• Trambambon llc

Как это делается хорошо могут рассказать наши отечественные разработчики винлокеров, мелкими буквами пишущие про «программу-шутку» и т.д., таким образом оберегаясь от статьи о мошенничестве. Так и живём…

Интересно, что реально существуют абсолютно нормальные программы с такими именами владельцев:
• Verified Software
• Genuine Software Update Limited
• Browser plugin

Понятно, что если уж этому верить, то ошибиться при первом взгляде на сертификат несложно.

Справедливости ради отмечу, что подписать х64-драйвер далеко не так просто, в этом случае пока нарушений не замечено.

5. Найти какого-нибудь работника доверенной компании и попросить его подписать Ваш код.

Без комментариев. Все любят деньги. Вопрос только в сумме 🙂

6. Украсть сертификат.

На данный момент известно три больших семейства троянцев, «заточенных», в частности, под похищение сертификатов. Это:
• Adrenalin
• Ursnif
• Zeus
• SpyEye (возможно)

Тем не менее пока не замечено массовых случаев использования украденных сертификатов в новых версиях этих троянцев. Возможно, это козырь в рукаве? Время покажет…

7. Заразить систему разработки доверенного разработчика и внедрять злонамеренный код в релизы до подписания.

Яркий пример такого заражения — вирус-концепт Induc.a. Вирус внедряет код на этапе компиляции, заражая систему разработки. В итоге разработчик даже не знает, что в его программе появился невидимый «довесок». Релиз проходит подпись и выходит в свет с полноценным сертификатом. Видишь суслика? А он есть! 😉

К счастью, Induc.a является только PoC, выполняя только заражение систем разработки без реализации какого бы то ни было дополнительного вредоносного функционала.

Ну а теперь — обещанные вкусняшки.

УЯЗВИМОСТЬ ИЛИ КАК Я ПРОВЁЛ ЭТИМ ЛЕТОМ

Как видим, вариантов обхода подписи достаточно много. В нашем примере будет рассмотрен модифицированный вариант 1 и 2, описанные выше.

Итак, что нам потребуется?
— MakeCert.exe
— cert2spc.exe
— sign.exe
— ruki.sys
— mozg.dll

Думаю, что для хабрачитателя не составит труда найти эти компоненты, но для самых ленивых выкладываю первые три здесь. Последние два не выкладываю в виду жёсткой привязки к железу, полному отсутствию кроссплатформенности и специфичности кода 🙂

Итак, создадим какой-либо сертификат доверенного издателя. Попробуем максимально скопировать информацию о том же VeriSign:
MakeCert.exe -# 7300940696719857889 -$ commercial -n CN=»VeriSign Class 3 Code Signing 2009-2 CA» -a sha1 -sky signature -l «https://www.verisign.com/rpa» -cy authority -m 12 -h 2 -len 1024 -eku 1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.3 -r -sv veri.pvk veri.cer

В результате выполнения мы получим veri.pvk и veri.cer, пригодные для подписывания.

Теперь создадим дочерний сертификат с использованием полученных только что:

MakeCert.exe -# 8928659211875058207 -$ commercial -n CN=»Home Sweet Home» -a sha1 -sky signature -l «http://habrahabr.ru/» -ic veri.cer -iv veri.pvk -cy end -m 12 -h 2 -len 1024 -eku 1.3.6.1.5.5.7.3.3 -sv kl.pvk kl.cer

В итоге получим kl.pvk и kl.cer, которые будут доверенными сертификатами от недоверенного издателя. Цепочку можно продолжать долго, задуривая наивного пользователя. Но итог будет один: сертификат не будет валидным, потому как в цепочке есть один недоверенный элемент. НО!

В Windows имеется возможность установки любого сертификата, в том числе и самоподписанного, в качестве доверенного. Это удобно: в ряде случаев разработчик может сделать себе самоподписанный сертификат, ввести его в доверенные и спокойно работать со своими приложениям. В нашем случае это удобно вдвойне, потому как такой внос — очевидно, простое внесение информации в реестр. при чём информации отнюдь не специфичной для конкретной системы.

Установим на нашу тестовую виртуалку любой монитор реестра, после чего внесём наш искомый сертификат от якобы VeriSign в доверенные. Отследим, где произошло изменение — и voila! Мы можем сделать дамп соответствующей ветки реестра, после чего засунуть её в инсталлер. В итого, наш инсталлер вносит в реестр инфу, автоматически превращая сертификат первичного издателя в доверенный и валидируя всю цепочку.

Чтобы окончательно не открывать все карты, скажу только, что в моём случае дамп реестра имел вид
Windows Registry Editor Version 5.00

ну или если только для текущего пользователя, то
Windows Registry Editor Version 5.00

Внеся в реестр эти данные, программа с фэйковой цепочкой подписи автоматом проходила проверку по sigverif.exe. Ну а подписать наш код с помощью полученного сертификата вообще просто, достаточно батника:

cert2spc.exe kl.cer kl.spc
sign.exe -spc kl.spc -v kl.pvk -n «My Installer» -i «http://habrahabr.ru» -ky signature -$ commercial -a sha1 -t «http://timestamp.verisign.com/scripts/timstamp.dll» myprogram.exe
del kl.spc

Обратите внимание на использование таймстампа timestamp.verisign.com/scripts/timstamp.dll — теоретически вполне возможно использование собственного сервера на собственном домене, что позволит каждый раз видеть, что кто-то проверил подпись нашей программы на своём компьютере, а значит получать IP и время проверки. Правда удобно? 😉

Самое забавное, что на момент написания материала в далёком октябре-ноябре 2010-го Kaspersky Internet Security 2011 не отслеживала указанные ветки реестра, а проверку валидности цепочки оставляла на усмотрение ОС, которую мы довольно просто надули. Не знаю, что сейчас, но вроде как некоторые ветки заблокировали… Проверяйте, отписывайтесь!

Нужно отметить, что для простановки подписей возможно использование и специфичного, недоступного в паблике софта. Понятно, что подписи он не ломает, но даёт куда более гибкие возможности для заполнения полей X500, что ещё лучше создаёт видимость валидности. Вот тут возможно скачать любопытный пример. В архиве — файл популярной замены Блокноту bred3_2k (офсайт) с и без подписи Microsoft 🙂 Чтобы подпись полностью стала валидной, достаточно внести в реестр изменения, содержащиеся в файле key +.reg. Аналогично, файл key -.reg эти изменения отменяет. Отследите путь сертификации — он любопытен 🙂

Сразу обращаю внимание на то, что автор «примера» прописал собственный таймстамп-сервер, так что любые манипуляции приведут к тому, что автор узнает Ваш IP — и дальше, как описывалось. Если хотите, то можете отследить эти обращения и отписаться в комментах 😉

Если потребуется, в следующей статье я расскажу, как настроить хипс для защиты соответсвующих веток реестра во избежание описанного внесения сертификатов в доверенные. Отписывайтесь в комментах — возможно, что эту уязвимость уже пофиксили.

В статье использован материал презентации Jarno Niemela (F-Secure).

• цифровая подпись
• malware
• доверенное приложение

Источник: habr.com

Как исправить ошибку «Этот сертификат содержит недействительную цифровую подпись»

В данной статье мы расскажем о путях решения ошибки «Этот сертификат содержит недействительную цифровую подпись» на примере «Тензор» и Казначейства. Вы узнаете, что такое цепочка доверия¸ как её настроить и многое другое.

Для возможности использования квалифицированной электронно-цифровой подписи (далее — КЭЦП) необходимо, чтобы криптопровайдер счёл сертификат пользователя достоверным, то есть надёжным. Этого можно добиться только в том случае, если корректно выстроена линия доверия сертификата, которая состоит из трёх элементов:

• Сертификат ключа проверки ЭП (далее — СКПЭП).
• Промежуточный сертификат (далее — ПС).
• Корневой сертификат (далее — KC).

Изменения хотя бы одного из этих документов повлечёт за собой недействительность сертификата, из-за чего он не сможет быть применён для заверки электронной документации. Также причинами ошибки может оказаться некорректная работа криптопровайдера, невозможность интегрирования с браузером и т.п.

Ниже мы рассмотрим, по каким причинам возникает ошибка «Этот сертификат содержит недействительную подпись», и что делать, чтобы ее исправить.

В сертификате содержится недействительная цифровая подпись: разбор ситуации, на примере «Тензор»

О том, что в сертификате присутствует недействительная ЦП, пользователь может понять в момент заверения цифрового документа КЭЦП, когда на дисплее отобразится соответствующие системное сообщение.

Для того, чтобы узнать о состоянии ключа, следует:

1. Войти в меню «Пуск».
2. Открыть раздел «Все программы» и перейти в «КриптоПро».
3. После этого нужно нажать л.к.м. на «Сертификаты».
4. В строке хранилище, отметить нужное.
5. Кликнуть на выбранный сертификат.
6. Открыть раздел «Путь сертификации».

В строке «Состояние» будет отражён статус неактивного сертификата.

Во вкладке «Общие» отображается причина, к примеру, «Этот сертификат не удалось проверить, проследив его до доверенного центра».

Сообщение об ошибке может отображаться по следующим причинам:

• Линия доверия была нарушена (неправильно прописан путь сертификации), произошло повреждение одного или всех сертификатов (кодирование соединения не будет доверенным, либо просто не будет работать).
• Некорректно инсталлирован криптопровайдер КриптоПро.
• Алгоритмы шифрования СКЗИ не работают, или работают некорректно.
• Нет доступа к реестровым документам.
• Версия браузера устарела.
• На компьютере выставлены неправильные хронометрические данные.

Из всего этого следует, что ошибка может быть вызвана: напрямую сертификатом, криптопровайдером, либо некорректными настройками компьютера. При этом, все эти варианты предполагают разные способы решения проблемы.

Цепочка доверия, от министерства цифрового развития и связи до пользователя

До того, как приступить к выяснению причины ошибки, в первую очередь, необходимо разобраться в алгоритме строения цепочки доверия сертификатов (далее, — ЦДС) – она является обязательной для правильной работы КЭЦП на всех существующих информационных ресурсах.

Принцип построения ЦДС

Первая ступень в построении ЦДС – это корневой сертификат ключа проверки министерства цифрового развития и связи. Именно Минкомсвязь производит аккредитацию удостоверяющих центров и предоставляет им разрешение на выпуск КЭЦП. Список аккредитованных УЦ представлен на официальном сайте Министерства цифрового развития и связи.

КС выдаётся пользователю при получении КЭЦП, также его можно загрузить с сайта roskazna.ru, либо с официального портала УЦ. В цепи доверия он занимает не последнее значение — и служит подтверждением подлинности КЭЦП.

Вторая ступень – это ПС, он предоставляется в комплекте с КС и включает в себя:

• Данные об УЦ и срок действия ключа.
• Электронный адрес для связи с реестром организации.

Данные сведения поступают в закодированном формате и применяются криптопровайдером для подтверждения подлинности открытого ключа КЭЦП.

В теории КЭЦП может быть украдена у владельца, но использовать её без инсталлированного сертификата УЦ не представляется возможным. Все эти меры направлены на то, чтобы минимизировать риски незаконного применения КЭЦП посторонними лицами.

СКПЭП последнее звено цепи доверия. УЦ предоставляет его вместе с открытым и закрытым ключом. Сертификат может быть предоставлен в бумажном, либо электронном виде, на него записаны основные сведения о владельце КЭЦП.

СКПЭП объединяет открытый ключ с определенным человеком, иными словами, подтверждает факт принадлежности ЭП конкретному лицу.

КС министерства цифрового развития и связи действителен, вплоть до 2036 года, а ПС предоставляется только на год, затем необходимо оплатить новый и инсталлировать его на свой компьютер.

Причиной возникновения ошибки «Этот сертификат содержит недействительную цифровую подпись» может служить повреждение любого отрезка ЦДС, начиная с Минкомсвязи РФ и заканчивая пользователем.

Пути решения ошибки

Для начала необходимо убедиться в том, что КС активен и верно инсталлирован. Для этого применяется стандартный путь: «Пуск» → «Все программы» → «КриптоПро» → «Сертификаты» → «Доверенные центры сертификации» → «Реестр». В появившемся перечне должен находиться файл от ПАК «Минкомсвязь России». Если сертификата нет, или он не активен, требуется его инсталлировать:

• Запустите скачанный файл на компьютере и, в разделе «Общие», нажмите «Установить».
• Поставьте отметку рядом со строчкой «Поместить в следующее хранилище».
• Укажите хранилище «Доверенные корневые центры сертификации».
• Для продолжения инсталляции, кликните на кнопку «ОК» и дайте согласие в окне, предупреждающем о безопасности.

После инсталляции сертификата, перезагрузите ПК.

Файл предоставляется УЦ одновременно с остальными средствами для генерации КЭЦП, если он потерян или удалён, необходимо обратиться в УЦ, предоставивший СКПЭП.

Когда с КС Минкомсвязи всё в порядке, но статус по-прежнему неактивен, необходимо его переустановить (удалить и инсталлировать повторно).

Существует ещё один вариант исправления ошибки, но он срабатывает не каждый раз. В случае, если предыдущий способ не помог, войдите в «Пуск», в строке поиска наберите regedit, после чего войдите в редактор и самостоятельно удалите следующие файлы.

На форуме CryptoPro CSP предлагается еще один вариант решения проблемы. Но работает он не всегда. Если установка документа не помогла, откройте меню «Пуск» и выполните поиск редактора реестра по его названию regedit. В редакторе найдите и вручную удалите следующие ветки:

Они могут быть как полностью, так и частично, поэтому следует удалить все, что имеется. Проверьте статус, он должен стать активным.

Следует помнить, что самовольное редактирование реестровых ключей может отразиться на работе системы, поэтому лучше поручить данную работу специалистам.

Исправление ошибки, на примере казначейства

Наиболее популярная причина недействительности сертификата – это нарушение путей сертификации. Причём неполадки могут быть не только в файлах министерства цифрового развития и связи, но и в промежуточных, а также личных СКЭП.

Ниже мы разберём причину ошибки, на примере Управления Федерального казначейства (УФК).

Изменение или повреждение файла УФК

Обязанности УЦ исполняются в территориальных органах Росказны по всей России. Для проведения аукционов и размещения на платформах сведений о госзакупках, участники должны подписывать отчёты цифровой подписью, полученной в УФК.

В случаях, когда не получается подписать документ, предоставленной казначейством ЭП, и высвечивается ошибка « Этот сертификат содержит недействительную цифровую подпись», необходимо:

• Зайти в раздел «Личное».
• Указать неработающий СКПЭП, после чего открыть раздел «Путь сертификации». В таком случае, основным УЦ будет выступать Мнкомсвязи РФ, а подчинённым УФК. Самым последним элементом в доверительной линии будет СКПЭП пользователя.
• Если после этого, статус до сих пор недействительный, то следует проследить всю доверительную линию и определить слабый элемент.
• Вернуться обратно во вкладку «Общие» и проверить, правильно ли указаны данные организации, выпустившей СКПЭП.
• После чего перейти в «Промежуточные центры сертификации». Если выявится, что причина в данном звене, в разделе «Общие» появятся следующие данные: «Этот сертификат не удалось проверить, проследив его до . ».

• На сайте УФК войти во вкладку «Корневые сертификаты».
• Загрузить «Сертификат УЦ Федерального казначейства».
• Переместить файл на компьютер. Процедура перемещения такая же, как и для основного центра, но как хранилище необходимо указать «Промежуточные центры сертификации».
• Выключите и включите ПК.

На последнем этапе нужно открыть вкладку «Личное» и указать необходимый СЭП, после чего сделать проверку пути сертификации.

Если всё прошло удачно, и проблема решена, в строке со статусом отобразится «Этот сертификат действителен». Значит, система произвела проверку ЦДС и не обнаружила отклонений.

Истечение срока

Каждый календарный год пользователю необходимо инсталлировать новый промежуточный ключ на ПК, с которого применяется КЭЦП. ОС должна в автоматическом режиме извещать пользователя, когда подойдёт срок. Если своевременно этого не сделать, то при подписании электронных документов, может отобразиться сообщение о том, что ключ не действителен. Процесс инсталляции, будет таким же, как и описанные выше. При этом удалять устаревший ПС не нужно, система просто пометит его как неактивный.

Для установки новых ключей не требуется подключения к интернету, файл будет проверен в автоматическом режиме, как только устройство выйдет в сеть.

Ошибка с отображением в КриптоПро

Когда возникает подобная ошибка, некоторые сайты могут отклонять СЭП, зато остальные с лёгкостью интегрируются с ней, потому что не все сайты производят проверку пути до основного УЦ. Исправление появившихся вследствие этого ошибок может усложняться, потому что в таких ситуациях вся цепь доверия не имеет нарушений и обозначается как активная.

В таких ситуациях может оказаться что неполадка связана с работой криптопровайдера, либо браузера.

Неправильная работа КриптоПро

Для того, чтобы убедиться в корректности работы, нужно зайти в КриптоПро CSP и открыть раздел «Алгоритмы». Если их характеристики пустые, это означает, что программа работает неправильно и её следует переустановить:

Для того, чтобы произвести переустановку, необходимо наличие специального программного обеспечения (КриптоПро), которую можно загрузить с портала разработчика. Она создана для экстренного удаления криптопровайдера. Этот способ даёт возможность полностью удалить КриптоПро с компьютера, что необходимо для качественной переустановки.

Сервисы инициализации

СЭП может высвечиваться как недействительный, в случаях, когда не активирована служба распознавания КриптоПро CSP.

Для того, чтобы проверить активность службы:

• Активируйте системное окошко «Выполнить», зажав на клавиатуре Win+R.
• После чего вбейте в командной строке services.msc.
• В перечне служб, укажите «Службы инициализации».
• Зайдите в подраздел «Свойства» и если служба неактивна, запустите её.

Выключите и включите компьютер, если всё сделано правильно КЭЦП будет работать корректно.

Что делать, если ошибка вызвана сбоем браузера

Если после коррекции цепочки доверия, устранения неисправностей криптопровайдер, ошибка всё равно высвечивается, существует вероятность того, что она вызвана сбоем браузера. В основном, так происходит при заверении документов на государственных порталах, либо сайтах контролирующих органов.

Создатели CryptoPro советуют пользоваться для работы с КЭП, только Internet Explorer, так как он уже вшит в Windows, но даже с ним может произойти сбой.

Вход под администраторскими правами

Чаще всего, после того как пользователь входит под паролем администратора, всё налаживается, и ключи начинают функционировать в стандартном режиме.

Что нужно сделать:

• Правой кнопкой мыши нажмите на значок браузера.
• Выберите строку «Запуск от имени администратора».

После того, как ошибка исчезнет:

• Правой кнопкой мыши нажмите на значок браузера.
• Кликните на «Дополнительно»
• И выберите «Запуск от имени администратора».

Теперь каждый раз при загрузке ПК, права администратора будут вступать в силу автоматически и больше не потребуется постоянно изменять настройки.

Выключение антивирусника

Некоторые антивирусные программы, к примеру, Symantec или AVG, распознают КриптоПро, как угрозу, и начинают блокировать программные процессы. В результате возникают всевозможные ошибки с СКПЭП, поэтому для того, чтобы подписать цифровой документ, желательно на некоторое время выключить антивирусную программу, для этого:

• Нажав правой кнопкой мыши на значок антивирусной программы, выберите «Сетевые экраны» или «Управление экранами».
• После чего, отметьте временной отрезок, на который предусмотрено отключение ПО.

Когда электронный документ будет подписан, активируйте антивирусную программу обратно.

Настройка хронометрических данных

Также необходимо проверить, актуально ли на компьютере выставлено число и время, для этого:

• Правой кнопкой мыши кликните на значок часов в правом нижнем углу монитора.
• Выберите «Настройка даты и времени».
• Выставьте нужный часовой пояс и правильные значения.
• Сохраните изменения.

По окончанию настроек выключите, а потом включите ваш ПК.

Нужна ЭЦП? Подберем подходящий вариант электронной подписи для вашего бизнеса.

Оставьте заявку и получите бесплатную консультацию специалиста.

Источник: kkmsale.ru