Нет полного доверия к сертификату подписи КриптоАрм — как исправить ошибку

2-й способ.

Второй способ заключается в переходе на систему шифрования от Microsoft, делается это так.
Идем по пути Свойства — S/MIME И TLS

раздел

Реализация S/MIMEи сертификаты TLS

включаем радиокнопку (отмечаем пункт)

Microsoft CryptoAPI

и нажимаем

ОК

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

Неизвестный сертификат СА,

не должно больше появляться, у меня все получилось.

Других способов решения этой проблемы, я к сожалению, не знаю.

Удачи!

Re: “сервер не представил корневой сертификат в сессии…”

Сообщение от MacroN

Будет он с вами добрый

Начать стоит с того, что перестать употренезадачать каннабис и немножко попытаться думать головой, желательно своей… и глюки отпустят

Объясняю подробно и прошу переместить в FAQ, если этого еще там нет

Аксиомы1. Сертификаты имеют иерархическую и сколь угодно глубокую иерархическую систему выпуска (Root CA — промежуточный CA — промежуточный CA- … — сертификат хоста) 2. В отличие от прочих MUA, известных в природе, Мыш проверяет валидность не только представленного серовером сертификата, но и всех его “родителей”, до упора, то есть до самоподписанного корневого сертификата. Зачем?

С целью обеспечения не псевдобезопасности, а более менее реальной, устраняя возможность атаки типа “man in the middle” (что это такое — спросить у Гугля Сергеевича) 3. Вне зависимости от выбранного вида реализации S/MIME (внутренняя или КриптоАПИ)

TLS-соединения всегда использует внутреннюю имплементацию, и проверку представленной цепочки сертификатов проводит по собственным адресным книгам (RootCA и IntermediateCA) Следствия из аксиом0. Кнопки “просмотр сертификата” и “добавление” неактивны оттого, что во время сессии север не представил корневой сертификат для сертификата сервера, а только свой, что в случае несамоподписнного серификата делает сертификат сервера бесполезным 1.

Все использованные для для выпуска конечного сертификата промежуточные сертификаты и корневой — должны быть известны-доступны в во время сессии 2. Windows Update бесполезен, поскольку он не обновит .abd 3. Если это происходит не на всех тазиках, то синхронизация адресбук сертификатов с работающими без предупреждений экземпляров есть решение проблемы

Thebat! vs gmail: сервер не предоставил корневой сертификат в сессии

Windows 7

С «семёркой» дела обстоят иначе – её официальная поддержка уже прекращена, поэтому настоятельно рекомендуем установить Windows 10. Но если это по тем или иным причинам неприемлемо, выход из ситуации есть – действуйте так:

1. Перейдите по указанной ниже ссылке.

   Каталог центра обновлений Microsoft

2. На этой странице воспользуйтесь поисковой строкой, в которую введите запрос KB2813430 и нажмите Enter.



3. Появится перечень доступных файлов. Воспользуйтесь сочетанием Ctrl F для вызова поиска, и в качестве запроса введите Windows 7. Внимательно осмотрите найденные ссылки – версии для пользовательских компьютеров называются «Обновление для системы безопасности Windows 7 для систем на базе … (KB2813430)» с указанием разрядности. Выберите соответствующий вашей версии ОС и воспользуйтесь кнопкой «Загрузить».



4. После скачивания установочного файла запустите его и инсталлируйте, следуя инструкциям на экране.



Обновления ОС весьма эффективно устраняют рассматриваемую проблему.

Windows имеет внутренний список неудаляемых корневых сертификатов

Какая информация содержится в корневом сертификате

Корневой сертификат представляет собой файл, который содержит свойства и данные: 

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

Какой срок действия корневого сертификата удостоверяющего центра

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

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

Получить электронную подпись

Настройка шифрования почты в the bat. –

Как настроить шифрование почты (S/MIME) в The Bat .
Это продолжение статьи Защита электронной почты. Шифрование почты. Получение сертификата.

The Bat поддерживает две технологии защиты информации: PGP и PKI (S/MIME). В этой статье речь пойдет только о технологии PKI (S/MIME).

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

Загружаем Bat, открываем настройки шифрования в меню Свойства -> Настройки S/MIME и TLS…
Здесь перед нами встает выбор: использовать внутреннюю реализацию S/MIME или Microsoft CryptoAPI.
При выборе внутренней реализации сертификаты будут находиться в хранилище Bat. Импорт/экспорт сертификатов будет осуществляться через интерфейс Bat. Также для корректной работы потребуется импорт корневых сертификатов и внесение их в список доверенных.
При выборе Microsoft CryptoAPI используется хранилище сертификатов Windows. Импорт/экспорт осуществляется через стандартные процедуры операционной системы. Лично я считаю этот вариант более удобным.
Однако, если вы работаете в Windows XP, и вам нужен максимальный уровень безопасности, в этом случае следует использовать криптопровайдер Bat. Он обеспечивает лучший набор алгоритмов шифрования по сравнению с стандартным Microsoft Enhanced Cryptographic Provider v1.0 (доступны алгоритмы AES 128 и 256-бит). В Vista добавлена встроенная поддержка AES, поэтому данная рекомендация относиться только к XP.

Для начала рассмотрим настройку с помощью Microsoft CryptoAPI (Win XP).

В списке криптопровайдеров выбираем Microsoft Enhanced Cryptographic Provider v1.0 (как обеспечивающий наилучшее шифрование). В списке также присутствует Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype), однако, с его помощью зашифровать письмо у меня не получилось (вместо AES 256-бит, письмо зашифровывалось алгоритмом RC2). Использовать это криптопровайдер не рекомендую.
Алгоритм шифрования: 3DES.
Хеш-алгоритм подписи: SHA-1.
Отмечаем опции “Помнить связи e-mail адресов с сертификатами для подписи” и “Помнить связи e-mail адресов с сертификатами для шифрования”.

Импорт сертификата из подписанного письма.
Выделяем письмо, далее в меню Инструменты -> Криптография и безопасность -> Импортировать ключ (сертификат).
Откроется мастер импорта сертификатов. Нажимаем Далее. В следующем окне оставляем выбранной опцию “Автоматически выбрать хранилище на основе типа сертификата” и Далее. Если появится предупреждение об импорте корневого сертификата, нажимаем Да, затем Готово.
Теперь по указанному в сертификате адресу можно отправлять зашифрованные письма.

Настройка шифрования с помощью внутреннего криптопровайдера Bat.

Алгоритм шифрования выбираем: AES (256-бит).
Хеш-алгоритм подписи: SHA-1.

Следующий этап – импорт сертификата вашего почтового ящика в хранилище Bat. Если вы следовали предыдущей статье, то ваш сертификат находится в хранилище Windows из которого его надо предварительно экспортировать. Если же у вас уже есть файл сертификата в формате PKCS#12 (.PFX), то вы можете сразу перейти к разделу Импорт сертификата.

Экспорт сертификата
Открываем Панель управления -> Свойства обозревателя -> вкладка Содержание -> кнопка Сертификаты
Переходим на закладку Личные, выделяем нужный сертификат, нажимаем кнопку Экспорт.
Откроется мастер экспорта сертификатов. Нажимаем Далее. В следующем окне необходимо выбрать опцию “Да, экспортировать закрытый ключ”, нажимаем Далее.
Выбор формата файла сертификата. Оставляем значения по умолчанию: файл обмена личной информацией – PKCS#12 (.PFX), опция “Усиленная защита” включена. Нажимаем Далее.
Вводим пароль закрытого ключа. Этот пароль будет запрашиваться каждый раз при доступе к закрытому ключу. Т.е. каждый раз при расшифровке/зашифровке письма (учтите это). Можно ввести пустой пароль, но это сильно понизит уровень безопасности.
Далее выбираем имя и расположение экспортируемого файла. Нажимаем Далее и затем Готово.

Импорт сертификата
Открываем Адресную книгу и создаем контакт для СВОЕГО адреса e-mail. Если включен внутренний криптопровайдер Bat, то в адресной книге будет доступна вкладка Сертификаты. Открываем ее и нажимаем кнопку Импортировать. Выбираем сохраненный сертификат. Появится окно для ввода пароля закрытого ключа:

Вводим пароль. Появится похожее окно, в него опять вводим тот же пароль. После этого в списке сертификатов должен появится новый сертификат.

Теперь двойным щелчком открываем его. Если в сведениях о сертификате будет надпись – “Этот S/MIME сертификат недействителен”, в этом случае необходимо добавить корневой сертификат в список доверенных. Для этого открываем вкладку Путь сертификации:

Выделяем корневой сертификат (в примере AAA Certificate Services) и нажимаем кнопку Добавить к доверенным. На вопрос, действительно ли мы хотим это сделать, отвечаем Да.
На этом импорт сертификата завершен.

Импорт сертификата из подписанного письма.
Выделяем письмо, далее в меню Инструменты -> Криптография и безопасность -> Импортировать ключ (сертификат). После этого появится сообщение о количестве импортированных сертификатов (может быть более одного, если импортируются отсутствующие вышестоящие сертификаты). Сертификаты автоматически добавляются к существующим контактам в адресной книге. Если адрес e-mail не был заведен, то соответствующий ему контакт будет создан автоматически. Для некоторых сертификатов может потребоваться процедура добавления корневого сертификата в список доверенных. В этом случае выполняем описанную выше процедуру.

Теперь мы готовы к отправке подписанных и/или зашифрованных сообщений.

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

Странность Bat.
Я так и не нашел где можно узнать с помощью какого алгоритма зашифровано письмо… Непонятно…

Настройка эцп the bat

Важное замечание. При запросе программы The Bat включить шифрование почтового ящика «On-the-fly encryption» следует отказаться.

Для настройки почтового ящика на работу с электронной подписью выполните следующие действия:

Заполните поля «Ваше имя», «Электронный адрес», «Пароль», «Протокол» в соответствии с Таблицей 1.

Укажите параметры IMAP и проверьте соединение нажав кнопку «Проверить»

Разрешите доступ приложению

Укажите параметры SMTP. Нажимать кнопку «Проверить» не рекомендуется, так как вероятен сбой программы

Укажите сведения об учётной записи

Откройте настройки S/MIME и TLS в программе The Bat

Выберите криптопровайдер Crypto-Pro и соответствующие алгоритмы

Откройте свойства почтового ящика

Включите простановку электронной подписи перед отправкой сообщений

Создайте электронное сообщение для одного из абонентов согласно Таблице 1, и убедитесь, что нажат переключатель простановки электронной подписи

Нажмите кнопку «Отправить». Выберите сертификат.

Для проверки электронной подписи сообщения нужно выбрать подписанное сообщение в разделе «Входящие» и нажать кнопку проверки

Появится окно с результатами проверки электронной подписи

При нажатии «Посмотреть свойства сертификата» будут выведены полные характеристики сертификата подписавшего лица

источник

Ооо “цифровые технологии”

Ошибка создания подписи: не удается построить цепочку сертификатов 0x800b010a – как исправить

Чтобы исправить ошибку создания подписи: «Не удается построить цепочку сертификатов» (0x800B010A) необходимо правильно диагностировать проблемный сертификат. Сделать это можно с помощью специализированного ПО, либо – с помощью Internet Explorer.

1. Следует запустить браузер Internet Explorer. В операционных системах Windows он является предустановленным;
2. Открыть меню браузера, нажав на значок шестеренки в верхнем правом углу окна;
3. Выбрать пункт «Свойства браузера»;
   
   Альтернативный вариант – зайти в свойства браузера, воспользовавшись встроенным поиском Windows;
   
   Альтернативный вариант – зайти в свойства браузера, воспользовавшись встроенным поиском Windows;
   
4. Перейти во вкладку «Содержание»;
5. Нажать кнопку «Сертификаты»;
   
6. Выбрать сертификат, которым необходимо подписать документ и нажать кнопку «Просмотр»;
7. Перейти во вкладку «Путь сертификации»;
8. Сертификат отмеченный красным крестиком или восклицательным знаком – и есть причина возникновения ошибки создания подписи: «Не удается построить цепочку сертификатов» (0x800B010A).
   

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

Сложности

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

Сложность вторая. Законодательство говорит о том, что УЦ – это юридическое лицо, и ГУЦ должен подписать сертификат этого УЦ. Ситуация, когда у одного юридического лица несколько комплексов УЦ и несколько сертификатов этих УЦ, толком в законах не прописана.

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

Сложность третья. Если сертификат отозвали, УЦ обязан его добавить в список отозванных сертификатов (СОС), обязанность эта прописывается в RFC, если они приняты как стандарт в стране, или в регламенте ГУЦ, к которому обязаны присоединиться все аккредитованные УЦ.

В случае когда СОС (CRL) большой, УЦ для удобства пользователей выпускает дельта СОС (deltaCRL) с изменениями за короткий период. В регламенте ГУЦ прописана периодичность обновления 12 часов или по факту отзыва сертификатов. В реальности различные УЦ свои СОС публикуют как хотят, существуют некоторые УЦ, которые обновляют их 1 раз в несколько месяцев.

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

Сложность четвертая, связная. Построение цепочки доверия в PKI так или иначе требует наличия связи с УЦ и ГУЦ и работу в онлайне. Работа в офлайне не предусмотрена. Существует ряд мест и приложений, где работа с подписями и сертификатами в офлайне очень бы пригодилась.

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

И только если на пути пользователя эти проблемы не встретились, цепочка доверия должна построится. В случае использования OCSP/TSP-служб проблемы тоже существуют, но это тема для отдельной статьи.

Способ 1: установка правильного времени

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

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



2. Первым делом нужно активировать переключатель «Установить время автоматически» – после этого ОС при подключении к интернету самостоятельно подгрузит правильные значения.



3. Если же подключение к сети на целевом компьютере не предполагается, воспользуйтесь кнопкой «Изменить» под строкой «Установка даты и времени вручную».

   

   Здесь самостоятельно задайте корректные значения.



4. Если же показания сбиваются после каждой перезагрузки или выключения ПК/ноутбука, это зачастую говорит о севшей резервной батареи BIOS и, следовательно, её необходимо заменить. Для начала сходите в любой магазин электроники или хозтоваров и приобретите элемент CR2032. Дальнейшие действия включают в себя частичную разборку устройства – если вы сомневаетесь в своих силах, к вашим услугам инструкция от нашего автора, применимая как для настольных ПК, так и для ноутбуков.

   Подробнее: Как поменять батарейку BIOS

Способ 4: установка сертификатов geotrust

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

Обратите внимание! Выполнение следующих действий может нарушить безопасность вашего компьютера, поэтому вы делаете это на свой страх и риск!

Ресурс компании GeoTrust

1. Посетите ресурс компании GeoTrust Primary Certification Authority по представленной выше ссылке.
2. Вверху таблицы должен быть блок с именем «GeoTrust Primary Certification Authority», взгляните на него – внизу должна быть ссылка, озаглавленная как «Root Download Link», кликните по ней ПКМ и выберите «Сохранить как…». Должен загрузиться документ в формате PEM.



3. После получения нужных файлов откройте окно «Выполнить» сочетанием клавиш Win R, введите в нём запрос certmgr.msc и нажмите «ОК».



4. После открытия требуемой оснастки найдите в меню слева пункт «Доверенные корневые центры», щёлкните по нему ПКМ и последовательно выберите опции «Все задачи» – «Импорт».



5. В первом окне «Мастер импорта сертификатов» нажмите «Далее».



6. Здесь кликните «Обзор».

   

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

   

   Нажмите «Далее».



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



8. Система сообщит, что импорт завершён, и предложит закрыть «Мастер…». Сделайте это и перезагрузите компьютер.



9. После загрузки ОС проверьте наличие ошибки. Если она не пропала, повторите действия из инструкции, но на шаге 4 выберите «Сторонние корневые центры сертификации».

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

Цепочка сертификации и цепочка доверия

Прежде чем рассматривать вопрос методики построения трансграничного доверия, хотелось бы разобрать вопрос построения цепочки доверия внутри страны, взяв за пример РФ.

Для этого кратко опишу, как вообще строится базовая инфраструктура PKI и какие есть методы обеспечения доверия в PKI.Доверие в PKI строится по принципу поручительства – например, если два человека не знают друг друга, но хотят вступить в отношения, которые требуют взаимного доверия, они ищут третьего, кому бы могли доверять они оба и кто бы поручился за каждого из них перед другим. Аналог такого человека в PKI называется третья доверенная сторона.

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

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

Аккредитация означает, что это юридическое лицо отвечает ряду требований законодательства, у него есть соответствующие лицензии ФСБ, Минкомсвязи и иногда ФСТЭК России, должным образом оборудованные помещения, обученный персонал с правильными дипломами и сертифицированные ПО и оборудование в роли удостоверяющего центра (УЦ).

Так вот, этот удостоверяющий центр уполномочен государством подтверждать вашу электронную подпись другим лицам. Процедура подтверждения вашей электронной подписи удостоверяющим центром является процессом создания цепочки сертификации, так как сертификат УЦ так же подписывается Главным удостоверяющим центром (ГУЦ), который является единой точкой доверия.

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

Аналогом этого являются 2-я и 3-я страницы внутреннего паспорта гражданина РФ, там тоже стоит ваша уникальная подпись, ФИО и указано, какой орган эти данные заверил. Но есть небольшое различие – в случае паспорта доверие к его носителю строится через подтверждение подлинности самого паспорта, а потом уже через данные, которые в нем указаны.

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

Такой путь хорош, когда УЦ не много, но если каждое ведомство развернет себе свой УЦ, получится ситуация, которая возникла в РФ к 2002–2005 годам: множество УЦ по стране, а единого пространства доверия нет, так как кросс-сертификация среди 800 УЦ – штука технически нереальная.

И вот тут возникает вопрос – как построить единое пространство доверия в отдельно взятой стране так, чтобы оно работало. Подход, который используется в РФ и не только – создание Главного удостоверяющего центра (государственного) (ГУЦ), подпись его сертификатом всех сертификатов УЦ в стране, как результат – построение цепочки доверия через проверку действительности всех сертификатов в подписи через ГУЦ.

Такой подход подразумевает, что проверяются подпись пользователя, действительность сертификата пользователя, действительность всех сертификатов в цепочке (УЦ–ГУЦ). Проверка действительности сертификатов в различных странах производится по-разному. В Эстонии и на Украине для этого требуется обратиться к OCSP/TSP-службе ГУЦ, которая ответит – действующий сертификат или же срок действия истек или сертификат отозван.

В России для проверки надо запросить у каждого УЦ в цепочке список отозванных сертификатов (СОС) и проверить, что сертификат в нем не указан. Пожалуй, наиболее развитым вариантом построения системы PKI следует считать схему с использованием мостообразующего УЦ, в том виде, в котором она используется в США.

Итоги

30 сентября после окончания срока действия сертификата DST Root CA X3 часть пользователей старых устройств столкнутся с тем, что не смогут корректно открывать сайты, использующие сертификаты Let’s Encrypt. Я бы выделил в первую очередь пользователей старых устройств Apple, для которых нет возможности обновиться хотя бы на iOS 10.

В то же время, для администраторов серверов с не очень современным софтом, которые могут взаимодействовать с сервисами, использующими сертификаты Let’s Encrypt, еще есть несколько дней на то, чтобы всё проверить и подготовиться к часу X.

Update: Добавил важное дополнение про необходимость проверки всех используемых контейнеров

Update2: Добавил, как добавить ISRG Root X1 в доверенные сертификаты в Debian/Ubuntu, спасибо @Kenshouten

Update3: Еще один метод решения проблемы для старых OpenSSL, процедура по добавлению сертификата ISRG Root X1 в доверенные в Windows для тех, кто еще не разобрался