Ошибка 0x800B0109 или сообщение «сертификат не является доверенным» при установке APPX-пакета почти всегда означает одно: пакет либо вообще не подписан, либо подписан сертификатом, которого нет в хранилище доверенных корневых центров Windows. Без действительной цифровой подписи система отказывается разворачивать APPX и MSIX пакеты — это жёсткое требование платформы, обойти которое штатными средствами нельзя.
В этой статье разберём, как подписать appx-пакет самоподписанным сертификатом через SignTool, как добавить сертификат в доверенные и что проверить, если установка всё равно завершается ошибкой. Материал ориентирован на разработчиков, тестировщиков и пользователей, устанавливающих приложения вне Microsoft Store.
Зачем APPX-пакету цифровая подпись
Формат APPX (и его наследник MSIX) спроектирован так, что Windows проверяет целостность и происхождение пакета до начала установки. Подпись подтверждает, что содержимое не изменялось после сборки, а издатель — тот, за кого себя выдаёт. Если подписи нет или она недействительна, диспетчер развёртывания блокирует установку ещё на этапе проверки манифеста.
Важный нюанс: издатель в манифесте пакета (поле Publisher в файле AppxManifest.xml) должен точно совпадать с полем Subject сертификата, которым выполняется подпись. Даже одно лишнее слово или другой регистр в строке вида CN=MyCompany приведёт к ошибке несоответствия издателя.
- 🔐 Подпись гарантирует целостность пакета после сборки
- 🏢 Windows сверяет издателя из манифеста с сертификатом
- 🚫 Неподписанный пакет невозможно установить штатно
- 🧪 Для тестов допустим самоподписанный сертификат
Что понадобится для подписи
Для работы потребуется утилита SignTool.exe — она входит в состав Windows SDK. Если SDK установлен, инструмент обычно находится в каталоге вида C:\Program Files (x86)\Windows Kits\10\bin\<версия>\x64\signtool.exe. Точный путь зависит от установленной версии SDK, поэтому при отсутствии файла проверьте соседние подкаталоги.
Также понадобится сертификат в формате PFX (с закрытым ключом). Его можно создать самостоятельно через PowerShell — об этом ниже. Для распространения приложения широкой аудитории тестовый сертификат не подойдёт: понадобится сертификат подписи кода от доверенного удостоверяющего центра.
Создание тестового сертификата
Для локальной разработки и тестирования сертификат генерируется одной командой PowerShell. Важно, чтобы значение -FriendlyName и Subject совпадали с издателем, указанным в манифесте пакета.
New-SelfSignedCertificate -Type Custom -Subject "CN=MyCompany" -KeyUsage DigitalSignature -FriendlyName "MyCompany Test" -CertStoreLocation "Cert:\CurrentUser\My" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")
После создания сертификат нужно экспортировать в файл .pfx с паролем. Делается это командлетом Export-PfxCertificate, где указывается путь к сертификату в хранилище и защищённая строка пароля. Храните PFX-файл и пароль отдельно от исходников проекта — любой, кто получит их, сможет подписывать пакеты от вашего имени.
⚠️ Внимание: самоподписанный сертификат подходит только для тестирования. На чужих машинах пакет, подписанный им, не установится, пока сертификат вручную не добавят в доверенные корневые центры.
Подпись пакета через SignTool
Сама подпись выполняется одной командой. Укажите алгоритм хеширования SHA256, путь к PFX-файлу, пароль и путь к пакету:
signtool sign /fd SHA256 /a /f "C:\certs\MyCompany.pfx" /p MyPassword "C:\packages\MyApp.appx"
Если сертификатов в файле несколько, параметр /a выберет подходящий автоматически; при необходимости конкретный сертификат задают через /sha1 <отпечаток>. После успешного выполнения SignTool выведет сообщение о том, что файл подписан, — ошибок быть не должно.
☑️ Проверка перед подписью пакета
Проверить результат можно командой signtool verify /pa "C:\packages\MyApp.appx". Для тестового сертификата утилита может сообщить, что цепочка не ведёт к доверенному корню — это ожидаемо, пока сертификат не добавлен в хранилище доверенных.
Добавление сертификата в доверенные
Чтобы Windows приняла пакет, сертификат издателя должен находиться в хранилище Trusted Root Certification Authorities локального компьютера (а не только текущего пользователя). Экспортируйте открытую часть сертификата в файл .cer и импортируйте его:
Import-Certificate -FilePath "C:\certs\MyCompany.cer" -CertStoreLocation Cert:\LocalMachine\Root
Альтернатива — графическая оснастка certlm.msc: откройте узел «Доверенные корневые центры сертификации» → «Сертификаты», через контекстное меню выберите импорт и укажите CER-файл. В доменной среде сертификат удобнее распространять через групповую политику, чтобы не настраивать каждую машину вручную.
⚠️ Внимание: добавление неизвестного сертификата в корневые доверенные центры снижает безопасность системы — любой пакет, подписанный им, будет считаться легитимным. Импортируйте только те сертификаты, происхождение которых вы контролируете.
Нужен ли режим разработчика или Sideloading?
Для установки подписанных пакетов вне Store в современных версиях Windows достаточно, чтобы была разрешена установка приложений из любых источников (параметр в разделе «Для разработчиков»). Режим разработчика требуется в основном для отладки и развёртывания из Visual Studio. Точное название переключателя может отличаться в зависимости от версии Windows.
Типичные ошибки и их причины
Даже правильно подписанный пакет иногда не устанавливается. Ниже — наиболее частые коды и ситуации, с которыми сталкиваются при развёртывании APPX.
| Ошибка | Вероятная причина | Что проверить |
|---|---|---|
0x800B0109 | Цепочка сертификата не ведёт к доверенному корню | Наличие сертификата в LocalMachine\Root |
| Несоответствие издателя | Publisher в манифесте ≠ Subject сертификата | Точное совпадение строки CN |
0x80073CF0 | Пакет повреждён или не может быть открыт | Целостность файла, повторная сборка |
| Ошибка зависимостей | Отсутствуют пакеты-зависимости (например, VCLibs) | Установку зависимостей до основного пакета |
| SignTool: «No certificates found» | PFX без закрытого ключа или неверный пароль | Повторный экспорт PFX с ключом |
Отдельный случай — пересборка чужого пакета. Если вы распаковали APPX, изменили содержимое и запаковали заново через MakeAppx.exe, старая подпись становится недействительной: хеш содержимого изменился. Такой пакет нужно подписывать своим сертификатом и соответственно менять издателя в манифесте, иначе проверка не пройдёт.
Подпись для публикации в Microsoft Store
Если конечная цель — Microsoft Store, ручная подпись не нужна: при публикации через Partner Center пакет переподписывается сертификатом Microsoft автоматически. Вам достаточно загрузить собранный пакет, ассоциированный с вашим приложением в центре партнёров.
Для корпоративного распространения без Store (через MDM, SCCM или прямую установку) потребуется коммерческий сертификат подписи кода, цепочка которого уже ведёт к доверенному корню в Windows. Тогда на целевых машинах ничего настраивать не придётся.
Часто задаваемые вопросы
Можно ли установить APPX без подписи?
Штатными средствами — нет. Проверка подписи встроена в механизм развёртывания, и отключить её безопасным способом нельзя. Единственный корректный путь — подписать пакет и добавить сертификат в доверенные.
Чем отличается подпись APPX от подписи MSIX?
Технически процедура одинакова: используется тот же SignTool и те же требования к сертификату. MSIX — более новый формат упаковки, но механизм проверки подписи у них общий.
Где взять SignTool, если Windows SDK не установлен?
SignTool распространяется в составе Windows SDK, который можно установить отдельно от Visual Studio, выбрав только нужные компоненты. Сторонние источники утилиты использовать не стоит — подлинность файла в этом случае проверить сложно.
Почему после подписи пакет всё равно не устанавливается на другом ПК?
Наиболее вероятная причина — сертификат не импортирован в хранилище доверенных корневых центров локального компьютера на целевой машине. Также проверьте, что пакет установлен для той же архитектуры (x64/x86/ARM) и что установлены необходимые пакеты-зависимости.
Можно ли подписать пакет сертификатом с истёкшим сроком действия?
SignTool может выполнить подпись, но Windows отклонит такой пакет при установке, если при подписи не была добавлена метка времени (timestamp). С меткой времени действительность подписи определяется на момент её создания, а не на момент установки.