Подписи приложений, использующих этот идентификатор, не совпадают

Обновлено: 23.03.2023

"Ошибка установки приложения. Идентификатор пакета этого приложения не соответствует его идентификатору подписи кода"

В консоли отображается следующее сообщение:

Если я соберу проект из Carthage/Checkouts/grpc-swift/SwiftGRPC-Carthage.xcodeproj напрямую с Xcode, то получившийся BoringSSL.framework выглядит просто отлично. Но при сборке с Carthage этот идентификатор BoringSSL-55554944d9392e62a01539918cc12380119f014f каким-то образом появляется в BoringSSL.framework/BoringSSL (несмотря на то, что идентификатор пакета — BoringSSL в Info.plist и в настройках Xcode).

Ожидаемый результат
Carthage должен преуспеть, если Xcode преуспеет.

Текст был успешно обновлен, но возникли следующие ошибки:

ikesyo прокомментировал 21 августа 2018 г.

Это проверка Apple. Проекты Xcode, сгенерированные SwiftPM как есть, не предназначены для создания платформ iOS для отправки приложений iOS. Проверьте и измените проект Xcode вручную.

JonasVautherin прокомментировал 21 августа 2018 г.

Спасибо за быстрый ответ! Попробую уточнить:

Я запускаю carthage update --platform ios , и он создает все фреймворки, включая BoringSSL.framework .
Я открываю свой проект и устанавливаю его на симуляторе. Это работает.
Я пытаюсь установить свой проект на iPad и получаю сообщение об ошибке идентификатора пакета.
Я добавляю проект, создающий BoringSSL.framework ( Carthage/Checkouts/grpc-swift/SwiftGRPC-Carthage.xcodeproj ), чтобы отслеживать изменения.
Я открываю Carthage/Checkouts/grpc-swift/SwiftGRPC-Carthage.xcodeproj с помощью Xcode и создаю его для iOS.
Я проверяю BoringSSL.framework и понимаю, что он отличается от созданного Carthage. В частности, BoringSSL.framework/BoringSSL от Carthage содержит этот BoringSSL-55554944d9392e62a01539918cc12380119f014f , а от Xcode — нет.
Я проверяю с помощью git, изменил ли Xcode файл SwiftGRPC-Carthage.xcodeproj, но это не так.
Я заменяю Carthage/Build/iOS/BoringSSL.framework новым BoringSSL.framework из Xcode и пытаюсь установить проект на iPad. Ошибка исчезла.

Похоже, что Xcode и Carthage не получают одинаковых результатов, хотя я запускаю их на одном и том же xcodeproj, и Xcode, похоже, не изменяет его.

Я полностью за проверку и изменение проекта Xcode вручную, и я потратил часы, пытаясь понять, почему идентификатор сборки, поступающий от Carthage, имеет этот BoringSSL-55554944d9392e62a01539918cc12380119f014f (это просто BoringSSL, когда я открываю настройки в Xcode или прочитайте xcodeproj). Единственное место, где появляется этот BoringSSL-55554944d9392e62a01539918cc12380119f014f, — это двоичный файл BoringSSL.framework/BoringSSL. И то же самое касается всех других продуктов этого xcodeproj, созданного из SwiftPM.

Есть ли у вас какие-либо идеи о том, что может пойти не так? Есть ли требование к формату идентификатора пакета (например, это должно быть ext.domain.name и не может быть name?). А знаете ли вы, чем сборка carthage отличается от сборки Xcode?

ikesyo прокомментировал 21 августа 2018 г. •

идентификатор сборки, полученный от Carthage, будет иметь этот BoringSSL-55554944d9392e62a01539918cc12380119f014f (это просто BoringSSL, когда я открываю настройки в Xcode или читаю xcodeproj)

Error Domain=MIInstallerErrorDomain Code=77 "Идентификатор подписи кода (BoringSSL-55554944d9392e62a01539918cc12380119f014f) не соответствует идентификатору пакета (BoringSSL)

поэтому BoringSSL-55554944d9392e62a01539918cc12380119f014f — это не идентификатор пакета, а идентификатор подписи кода.

Вы знаете, почему сборка carthage отличается от сборки Xcode?

JonasVautherin прокомментировал 21 августа 2018 г.

поэтому BoringSSL-55554944d9392e62a01539918cc12380119f014f не является идентификатором пакета, но является идентификатором подписи кода.

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

Я попытался специально установить CODE_SIGN_IDENTITY="" (и я вижу, что это находится в xcodeproj в Carthage/Checkouts/grpc-swift ), и это значение для "Не подписывать код". Но тем не менее, я получаю этот BoringSSL-55554944d9392e62a01539918cc12380119f014f в результирующем двоичном файле.

Похоже, что Carthage неправильно подписывает продукт. Есть ли в этом смысл?

JonasVautherin прокомментировал 21 августа 2018 г.

Также обратите внимание, что у них, по-видимому, была точно такая же проблема, и они решили ее, каким-то образом изменив идентификатор пакета 🤔 .

Этот документ помогает устранить неполадки, связанные с неудачной проверкой подписи, которые могут возникнуть при архивации приложения в 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, подписанный для распространения, в архиве приложения?

Выполните действия, описанные в разделе «Бета-тестирование приложения 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 устройств, связанных с профилем, например:

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

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

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

Сообщение об ошибке «Извините, это не сработало. Вернитесь на сайт office.com и повторите попытку», пожалуй, одно из самых расплывчатых, которые я когда-либо видел. что нормально, если вы не являетесь администратором.

Ниже приведен пример случая, когда всем пользователям не удавалось войти в Office 365. Они получали вышеупомянутое сообщение "Извините, это не сработало" и не предпринимали дальнейших действий.

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

Окружающая среда и симптомы

Эта среда объединена с Azure AD с помощью AD FS 2019. Присутствуют как AD FS, так и WAP, которые развернуты в корпоративной сети и демилитаризованной зоне соответственно. Накануне все вроде работало, а вдруг вышло из строя.

Немедленно мы получаем вышеупомянутую ошибку - извините! Насколько это канадский? Это извинение за то, чего оно не вызвало, но мы увидим это ниже.

Для удобочитаемости показана ошибка "Извините, это не сработало. Вернитесь на Office.com и повторите попытку".

А как насчет IE? Кто-то настраивал поддерживаемые строки браузера или встроенные настройки аутентификации? Давайте просто попробуем IE11, чтобы проверить, работает ли он.

Нет. Та же проблема.

Нет. Но мы начинаем получать нашу первую значимую подсказку.

X-Auth-Error OpenIdConnect Microsoft.Exchange.Security.OpenIdConnect.OpenIdConnectIdpException

Это должно заставить вас задуматься о лежащем в основе процессе аутентификации. Мы еще вернемся к этому.

Как насчет того, чтобы попробовать Outlook ProPlus с приложениями Microsoft 365 для предприятий?

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

Подводя итог, мы видели следующие фрагменты:

ОпенИДКоннект
Ошибка X-Auth
Проблемы с токенами

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

Просмотр журналов входа в Azure AD

Для этого мы переходим на портал Azure AD и проверяем журналы входа. Для получения дополнительной информации о журналах просмотрите документацию.

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

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

Для справки полный текст ошибки:

Код ошибки входа 5000811 Не удалось проверить подпись токена. Идентификатор ключа подписи не соответствует ни одному допустимому зарегистрированному ключу.

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

Проверка конфигурации и работоспособности AD FS

В федеративном сценарии мы полагаемся на AD FS. Давайте проверим наличие ожидаемых строк пользовательского агента и включена ли встроенная проверка подлинности Windows (WIA).

Для этого мы можем запустить приведенное ниже в PowerShell.

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

Срок действия сертификата TLS истек?

Но обратите внимание на выделенную строку и тот факт, что ниже перечислены два сертификата.

Это стандартное обновление сертификата AD FS для сертификатов Token-Signing и Token-Decryption. Это самоподписанные сертификаты со сроком действия 12 месяцев.

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

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

Нет, нам нужно проверить WAP.

Проверка работоспособности прокси-сервера веб-приложения

Снимок экрана ниже даст вам представление.

Это не так. Поскольку WAP был нарушен, обновленный XML-код федерации был недоступен в Интернете. Поэтому, когда мы перешли на новый сертификат, Azure AD не удалось получить обновленную информацию.

Именно это привело к разрыву связи между AD FS и Azure AD.

Нам нужно исправить это, и это будет сделано в два этапа. Исправление WAP, а затем обновление Azure AD.

Исправление WAP

Серверы WAP потеряли связь с внутренней фермой AD FS. Им не удалось открыть подключение к TCP 443 в AD FS. Это произошло из-за изменения брандмауэра, когда был изменен не тот объект.

Правила брандмауэра были обновлены, чтобы позволить WAP-серверам взаимодействовать с AD FS по протоколу TCP 443.

Затем нам пришлось восстановить доверие с помощью этого процесса на каждом WAP-сервере. WAP снова заработал и смог пройти аутентификацию в AD FS.

Пора обновить Azure AD.

Обновите Azure AD

Теперь WAP работает и доступен в Интернете. Поскольку сертификаты для подписи токена и расшифровки токена были обновлены до новых версий, нам необходимо сообщить об этом Azure AD как можно скорее.

Для этого мы можем использовать Azure AD PowerShell для обновления метаданных федерации.

Приведенные ниже команды запускались с сервера управления, поэтому основной сервер AD FS нужно было указать вручную с помощью командлета Aet-MsolADFSContext.

Затем мы обновляем федеративный домен.

Ширина

Обратите внимание, что в этом сообщении предполагается, что вы объединяете один домен верхнего уровня с этой фермой AD FS, поэтому переключатель -SupportMultipleDomain не использовался.

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

Кроме того, вы также можете использовать Azure AD Connect для обновления доверия AD FS к Azure AD.

Давайте повторим проблему и ее решение.

Основная причина

AD FS создает новые сертификаты для подписи маркеров и расшифровки маркеров по мере того, как старые достигают значения CertificateGenerationThreshold. В этот момент старые сертификаты все еще использовались, и проблем не было, пока AD FS не переключилась на новые сертификаты. Обычно это не было бы проблемой, но поскольку Azure не смогла получить доступ к метаданным для этих новых сертификатов, она не смогла их принять, и это то, что мы видели в приведенных выше ошибках, касающихся неожиданного сертификата подписи. Причина, по которой метаданные не были обновлены, заключалась в том, что серверы WAP были отключены от внутренней фермы AD FS, поэтому WAP перестал работать.

Если оглянуться на журналы, то на самом деле отключение произошло за несколько месяцев до этого. Это никогда не было замечено, поскольку заказчику не удалось настроить мониторинг для каких-либо серверов AD FS или WAP. С переходом на современную аутентификацию пользователи обращались к серверу AD FS напрямую, а не через WAP, чтобы получить токен. Это результат современной аутентификации с использованием пассивного потока. Устаревшая проверка подлинности (базовая проверка подлинности) для Exchange Online использовала активный поток, который мог бы использовать WAP.

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

При развертывании упакованного приложения 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.

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

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

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

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

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