06100111 ошибка проверки электронной подписи не удалось проверить статус сертификата

Обновлено: 21.11.2024

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

Обзор

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

Диагностика ошибки проверки подписи

Сбой проверки подписи диагностируется следующими сообщениями об ошибках.

Листинг 1. Ошибка проверки приложения, указывающая, что приложение не подписано профилем распространения App Store.

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

Листинг 3. Недопустимое электронное письмо с отклонением двоичного кода, указывающее на обнаружение поврежденной подписи кода.

Устранение ошибки проверки подписи

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

Проверьте сигнатуру на наличие основной причины сбоя

Следующая команда терминала способна различать ряд проблем с подписью кода, которые следуют.

Важно: "/path/to/the.app" – это путь к файлу вашего приложения. Перетащите файл .app из окна Finder в окно терминала, чтобы автоматически указать путь к файлу.

Примечание. Чтобы найти файл приложения, связанный с архивом приложения Xcode, см. раздел Как найти файл .app, подписанный для распространения, из архива приложения?

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

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

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

Или связанная с этим ошибка:

Ниже приведены два варианта решения этой проблемы:

Файл с префиксом "._" является проблемным и является результатом копирования определенных файлов Mac OS X на диск, не отформатированный в формате HFS+. Эти файлы называются файлами Dot, файлами Apple Double или вилками ресурсов. Они невидимы для Finder, но их можно удалить с помощью утилиты dot_clean. Папка проекта Xcode является аргументом для dot_clean, как показано ниже.

Примечание: перетащите папку проекта Xcode из Finder в терминал, чтобы автоматически указать путь.

Важно: если терминал не может найти утилиту dot_clean, загрузите дополнительные инструменты командной строки через Xcode через «Настройки» > «Загрузки».

Кроме того, эту проблему можно обойти, создав новый проект с использованием последней версии Xcode. Переместите свой код, ресурсы и платформы в новый проект и повторите попытку проверки сборки дистрибутива.

Две немного отличающиеся версии этой ошибки:

Если (x) в приведенной выше ошибке представляет собой путь к файлу, который кажется *усеченным*, то решение этой проблемы состоит в том, чтобы сделать все, что в ваших силах, чтобы *укоротить* этот путь, например, установить "имя пакета" Info.plist на более короткое имя. Затем повторите попытку проверки сборки дистрибутива.

Если (x) в приведенной выше ошибке — это путь к файлу, который *не* кажется усеченным, но вы работаете в Mac OS X 10.6.x, обновите до OS X Lion 10.7.x и загрузите/установите последняя версия Xcode.

Чтобы устранить эту ошибку:

1) Убедитесь, что для свойства Info.plist "Исполняемый файл" установлено значение: $ .

2) Убедитесь, что папка Derived Data находится на диске с форматированием HFS+.

3) Эта проблема была распространена в более старых версиях Xcode. Убедитесь, что на вашем Mac установлена последняя версия Xcode, и если это так, переустановите Xcode.

4) Также известно, что эта ошибка возникает, когда утилита codesign не может найти утилиту codesign_allocate, что может произойти, если переменная среды CODESIGN_ALLOCATE не установлена, например:

Эта ошибка возникает, когда подписанные пакеты приложений размещаются на дисках других форматов, которые не поддерживают ветки ресурсов Mac OS X. Чтобы решить эту проблему, убедитесь, что и проект Xcode, и папка производных данных находятся на диске в формате HFS+. Параметр «Производные данные» находится в разделе «Настройки Xcode» > «Местоположения».

Если проверка OCSP и CRL временно отключена (в разделе «Связка ключей» > «Настройки» > «Сертификаты») и это устраняет сборку Xcode, переустановите Xcode (для восстановления собственной подписи), а также убедитесь, что на Mac нет проблем с сетевым подключением, которые работает Xcode.

Не распространяйте приложения из бета-версии OS X или бета-версии Xcode

Приложения для App Store должны создаваться с использованием версий GM OS X и Xcode. Если вместо этого приложения создаются с помощью бета-версии OS X или Xcode, они будут отклонены на этих основаниях. Бета-версия, исходная версия, предварительная версия программного обеспечения для разработчиков и предварительная версия являются синонимами в этом контексте.

Проверьте версию OS X, выбрав меню Apple > «Об этом Mac» > «Дополнительная информация» > «Системный отчет». Нажмите «Программное обеспечение» на боковой панели для версии системы. Сравните версию вашей системы и номер сборки с последним выпуском OS X, представленным в Mac App Store.

Чтобы проверить версию Xcode, откройте меню Xcode > О Xcode. Сравните версию и номер сборки с последней небета-версией Xcode, доступной на веб-сайте Dev Center.

Избегайте использования специальных символов в именах исполняемых файлов

Исполняемые файлы в вашем приложении, содержащие специальные символы (т. е. нечисловые и не буквенные), могут вызвать отклонение. Чтобы решить эту проблему, измените параметр сборки Product Name целевого объекта Xcode с $ на строку, содержащую только буквенно-цифровые символы. Кроме того, убедитесь, что значение ключа Info.plist «Исполняемый файл» равно $ . Если вы определили, что это является причиной, отправьте отчет об ошибке с помощью Apple Bug Reporter, указав проблемные символы.

Устранение неполадок с правами на подпись кода

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

Назначения прав во встроенном приложении

Чтобы диагностировать сбои проверки прав на подпись кода, сравните права в следующих двух местах на наличие несоответствий или непредвиденных значений:

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

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

Источники прав

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

<р>1. Права на предоставление профилей настраиваются с помощью идентификатора приложения на веб-сайте Certs IDs and Profiles или, что то же самое, с помощью панели Xcode Target > Capabilities.

<р>2. Права на источник подписи приложения из следующих мест:

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

Возможности, которые включены на панели Xcode > Target > Capabilities. (Это существенно влияет на права, связанные с идентификатором приложения, связанным с профилем подготовки, который Xcode попытается использовать для подписи приложения.)

Любые пользовательские права на подпись кода, которые могут быть предоставлены через файл «.entitlements», определенный в настройке целевой сборки Xcode «Права на подпись кода» (если есть).

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

Важно: «Изначально» выделено, потому что приложения могут быть повторно подписаны на панели Xcode > Организатор > Архивы для различных рабочих процессов распространения, в которых все права заменяются профилем повторной подписи *кроме* префикса идентификатора приложения. Дополнительную информацию см. в разделе Избегайте несоответствия префикса идентификатора приложения.

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

Рабочий процесс проверки прав приложения

Процесс проверки прав *точной* сборки, которую вы отправляете в App Store, используйте рабочий процесс в Технических вопросах и ответах QA1798 — Проверка прав на распространение .

Избегайте несоответствия префикса идентификатора приложения

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

Пример префикса идентификатора приложения показан ниже. Это 10-значный префикс идентификатора приложения, связанного с профилем подготовки. Итак, для идентификатора приложения:

Префикс идентификатора приложения:

Вот как решить эту проблему:

Проверьте префикс идентификатора приложения встроенного профиля вашего приложения, выполнив действия, описанные в разделе Как проверить права, связанные с моим профилем подготовки?

Затем сравните его с префиксом идентификатора приложения в подписи приложения, используя Как проверить права в подписи моего приложения?

Если префикс не совпадает, проще всего использовать один и тот же профиль инициализации на обоих этапах подписания:

Откройте цель проекта Xcode > Параметры сборки и разверните параметры сборки удостоверения подписи кода и профиля подготовки. Установите для параметра «Любой SDK iOS» значение «Распространение iOS» для выпуска.

Установите параметр сборки Provisioning Profile в соответствии с вашим профилем инициализации распространения.

Повторно заархивируйте приложение (через Xcode > меню «Продукт» > «Архивировать»).

Повторно отправьте приложение через Xcode Organizer и обязательно выберите тот же профиль распространения, чтобы подписать отправку.

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

Подпишите свое приложение, используя правильный профиль обеспечения

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

Вот два места, где можно убедиться, что вы подписываете правильный профиль обеспечения:

Архивация приложения, вызываемая через Xcode > меню «Продукт» > «Архив», использует настройку целевой сборки «Идентификатор подписи кода» и «Профиль подготовки», чтобы выбрать профиль подготовки для подписи приложения.

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

Установите для параметра «Идентификатор подписи кода» конфигурации сборки выпуска значение «Распространение iOS», а для параметра сборки «Профиль подготовки выпуска» конфигурации сборки «Выпуск» задайте профиль подготовки распространения распространения App Store.

Фаза распространения на вкладке Xcode > Organizer > Archives использует меню выбора Provisioning Profile для повторной подписи архива перед его отправкой. Обратите внимание, что префиксы идентификатора приложения никогда не обновляются в процессе повторной подписи. Дополнительную информацию см. в разделе Избегайте несоответствия префикса идентификатора приложения.

Примечание. Вы можете проверить свои результаты, проверив, подписано ли ваше приложение сертификатом распространения, выполнив действия, описанные в разделе Как узнать, какой сертификат использовался для подписи моего приложения? . В поле «Полномочие» должно быть напечатано «Распространение iPhone».

Установите центр сертификации Apple Root

Для проверки подписи кода приложения требуются сертификаты корневого центра сертификации (ЦС).

Рис. 1. Правильно установленный центр сертификации Apple Root.

Если эти файлы отсутствуют в вашей связке ключей, выполните следующие действия:

<р>2. Дважды щелкните загруженные файлы .cer, чтобы установить их в Keychain Access. Добавьте их в цепочку ключей входа по умолчанию.

<р>3. Если отправка по-прежнему не проходит проверку подписи, перейдите к следующим требованиям, описанным в этом руководстве.

Дополнительная информация

Как проверить, не повреждена ли подпись моего приложения?

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

Как узнать, какой сертификат использовался для подписи моего приложения?

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

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

Примечание. Перетащите файл .mobileprovision из Finder в Terminal, чтобы автоматически указать путь к файлу.

Проверьте поле "Полномочия" в результатах команды, чтобы узнать, кому принадлежит сертификат, используемый для подписи приложения:

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

Как проверить права подписи моего приложения?

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

Примечание. Перетащите файл .mobileprovision из Finder в Terminal, чтобы автоматически указать путь к файлу.

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

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

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

Как найти файл .app, подписанный для распространения, в архиве приложения?

Выполните действия, описанные в разделе «Бета-тестирование приложения iOS» в Руководстве по распространению приложений, чтобы создать файл .ipa, однако не забудьте подписать приложение, используя свой профиль подготовки распространения в App Store.

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

Просмотрите файл .app, подписанный для распространения, в папке ./Payload/Applications.

Как проверить права, связанные с моим профилем обеспечения?

Разрешения связаны с профилями подготовки и переносятся в подпись вашего приложения во время подписания кода.

Проверка прав профиля обеспечения

Примечание. Перетащите файл .mobileprovision из Finder в Terminal, чтобы автоматически указать путь к файлу.

Листинг 5. Соответствующие результаты команды отображаются в разделе Entitlements.

Рассмотрите пример, в котором этот профиль использовался для создания подписи приложения, как показано в разделе Как проверить права подписи моего приложения? Обратите внимание на следующие ожидаемые результаты при сравнении двух:

1) право на идентификатор приложения в подписи полностью подходит для заполнения части "*" этого права в профиле.

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

3) get-task-allow имеет значение false, как и должно быть для профилей распространения. Хотя это конкретное право игнорируется во время приема в App Store, оно должно быть ложным для профилей Ad Hoc (и подписей Ad Hoc). Если здесь в подписи указано значение true, это может означать, что вы собрали сборку дистрибутива с неправильной конфигурацией сборки, "Отладка" вместо "Выпуск".

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

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

Примечание. Перетащите файл .mobileprovision из Finder в Terminal, чтобы автоматически указать путь к файлу.

Как проверить, какие устройства связаны с моим профилем обеспечения?

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

Примечание. Перетащите файл .mobileprovision из Finder в Terminal, чтобы автоматически указать путь к файлу.

В результатах команды найдите раздел ProvisionedDevices для UDID устройств, связанных с профилем, например:

История изменений документа

Добавить требование сертификата корневого ЦС.

Новый документ, помогающий решить проблему с проверкой подписи.

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

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

Что вам нужно знать

Технологии

Предпосылки

для диагностики ошибок установки. для манипулирования хранилищем сертификатов во время устранения неполадок

Инструкции

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

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

Чтобы получить код ошибки из журналов событий

Запустите файл eventvwr.msc.

Выберите Средство просмотра событий (локальное) > Журналы приложений и служб > Microsoft > Windows.

Первый журнал для проверки — AppxPackagingOM > Microsoft-Windows-AppxPackaging/Operational.

Ошибки, связанные с развертыванием, записываются в AppXDeployment-Server > Microsoft-Windows-AppXDeploymentServer/Operational.

Чтобы узнать об ошибках развертывания, найдите самое последнее событие ошибки 404. Это событие ошибки содержит код ошибки и описание причины сбоя развертывания. Если событие ошибки 465 предшествовало событию 404, возникла проблема с открытием пакета.

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

Код ошибки	Ошибка	Описание	Предложение
0x80073CF0	ERROR_INSTALL_OPEN_PACKAGE_FAILED	Не удалось открыть пакет приложения.	Эта ошибка обычно указывает на проблему с пакетом. Вам нужно снова собрать и подписать пакет. Дополнительные сведения см. в разделе Использование App Packager.
0x80080205	APPX_E_INVALID_BLOCKMAP	Пакет приложения был изменен или имеет недопустимый карта блоков.	Пакет поврежден. Вам нужно снова собрать и подписать пакет. Дополнительные сведения см. в разделе Использование App Packager.
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. Определите цепочку сертификатов, используемую для подписи пакета приложения

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

Чтобы определить цепочку сертификатов

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

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

Чтобы определить серийный номер для каждого сертификата

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

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

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

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

Выполните эту команду:

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

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

Примечания

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

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

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

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

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

Вы можете удалить сертификат, если он вам больше не нужен.

Чтобы удалить сертификат

Запустите Cmd.exe от имени администратора.

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

Найдите серийный номер сертификата, который вы установили. Этот номер является certID.

Выполните эту команду:

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

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

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

В этом разделе описывается, как проверить подписи в XPS-документе и как проверить сертификаты, связанные с этими подписями.

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

В следующем примере кода проверяются цифровые подписи, найденные в документе XPS.

Чтобы проверить подписи в XPS-документе, выполните следующие действия:

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

Чтобы проверить цифровую подпись, сначала проверьте подпись, созданную сертификатом подписи, а затем проверьте сертификат подписи. Метод проверки, используемый в следующем примере кода, кэширует сертификаты во временном хранилище сертификатов, которое функции Crypto API используют при вызове позже в этом примере.

Чтобы создать временное хранилище сертификатов, выполните следующие действия:

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

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

Найдите сертификат подписи, перебирая сертификаты, используемые подписью.
Протестируйте сертификат, сверив подпись с сертификатом.Сертификат подписи найден, когда метод Verify возвращает XPS_SIGNATURE_STATUS XPS_SIGNATURE_STATUS_VALID или XPS_SIGNATURE_STATUS_QUESTIONABLE и не возвращает ошибку FACILITY_SECURITY.

Когда сертификат подписи найден, выполните следующие действия:

Сохранить возвращенный статус подписи.
При необходимости обновите локальный статус для выполнения последующих тестов сертификата:
1. Если статус подписи успешен, установите локальный статус на сомнительный, чтобы проверить сертификаты.
2. Если статус подписи не соответствует, оставьте локальный статус несоответствующим.
3. Если статус подписи нарушен или неполный, установите локальный статус на нарушенный.
Статус подписи XPS_SIGNATURE_STATUS_INCOMPLIANT означает, что части документа XPS, которые не должны были быть подписаны, были подписаны или части документа XPS, которые должны были быть подписаны, не были подписаны. Если Verify возвращает этот статус подписи, дальнейшая проверка подписи не требуется.

Чтобы проверить доверие сертификата, если статус подписи был действительным или сомнительным, выполните следующие действия:
1. Получить статус доверия сертификата.
2. Оцените возвращенный статус доверия сертификата.
3. Вернуть полученный статус.
В следующем примере кода не выполняется проверка каждого возможного статуса доверия сертификата. Дополнительные сведения о возвращаемых значениях состояния см. в разделе CERT_TRUST_STATUS.

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

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

Читайте также: