как подписать программу сертификатом windows
Подписание пакета приложения с помощью SignTool
SignTool — это средство командной строки, используемое для цифровой подписи пакета приложения или пакета приложений с помощью сертификата. Сертификат может быть создан пользователем (для тестирования) или выдан компанией (для распространения). Подписывание пакета приложения дает пользователю средство проверки отсутствия изменений в данных приложения после его подписи, при этом также подтверждается подлинность пользователя или компании, подписавшего пакет. SignTool может подписать зашифрованные и незашифрованные пакеты приложения и пакеты приложений.
Если для разработки приложения использовали Visual Studio, рекомендуется применять мастер Visual Studio для создания и подписывания пакета приложения. дополнительные сведения см. в статьях упаковка приложения UWP с Visual Studio и упаковка классического приложения из исходного кода с помощью Visual Studio.
Дополнительные сведения о подписи кода и сертификатах в целом см. в разделе Знакомство с процессом подписания кода.
Предварительные условия
Упакованное приложение
Подробнее о ручном создании пакета приложения, создания пакета приложения с помощью средства MakeAppx.exe.
Действительный сертификат подписи
Дополнительные сведения о создании или импорте действительного сертификата подписи см. в разделе Создание или импорт сертификата для подписания пакета.
SignTool.exe
В зависимости от пути установки пакета SDK SignTool может находиться в следующих расположениях на компьютере с Windows 10:
Применение SignTool
SignTool может использоваться для подписывания файлов, проверки подписей и меток времени, удаления подписей и другого. Так как нас интересует подписывание пакета приложения, мы рассмотрим команду sign. Подробные сведения об инструменте SignTool см. на справочной странице SignTool.
Определение хэш-алгоритма
При использовании SignTool для подписи пакета приложения или пакета приложений, хэш-алгоритм, применяемый в SignTool, должен совпадать с алгоритмом, использованном для упаковки приложения. Например, если вы применили MakeAppx.exe для создания пакета приложения с параметрами по умолчанию, то необходимо выбрать SHA256 в SignTool, поскольку это алгоритм, по умолчанию используемый в MakeAppx.exe.
Чтобы узнать, какой алгоритм хэширования применялся при упаковке приложения, извлеките содержимое пакета и изучите файл AppxBlockMap.xml. Инструкции по распаковке/извлечению пакета приложения см. в разделе Извлечение файлов из пакета приложения или пакета приложений. Хэш-метод указан в элементе BlockMap и имеет следующий формат:
В этой таблице показан каждое значение HashMethod и соответствующий хэш-алгоритм:
| Значение HashMethod | Хэш-алгоритм |
|---|---|
| http://www.w3.org/2001/04/xmlenc#sha256 | SHA256 |
| http://www.w3.org/2001/04/xmldsig-more#sha384 | SHA384 |
| http://www.w3.org/2001/04/xmlenc#sha512 | SHA512 |
Так как в SignTool по умолчанию применяется алгоритм SHA1 (которого нет в MakeAppx.exe), вам всегда необходимо указывать хэш-алгоритм при использовании SignTool.
Подпись пакета приложения
Если у вас есть все необходимые компоненты и вы определили, какой хэш-алгоритм применялся для упаковки приложения, то вы готовы подписать его.
Общий синтаксис командной строки при подписи пакета с помощью SignTool таков:
Сертификат, используемый для подписания приложения, должен быть либо PFX-файлом либо установлен в хранилище сертификатов.
Чтобы подписать пакет приложения с помощью сертификата из PFX-файла, примените следующий синтаксис:
Обратите внимание, что параметр /a позволяет SignTool автоматически выбрать наиболее подходящий сертификат.
Если ваш сертификат не является PFX-файлом, используйте следующий синтаксис:
Обратите внимание, что с некоторыми сертификатами пароль не используется. Если для вашего сертификата не требуется пароль, опустите параметр «/p » в примерах команд.
Подписав пакет приложения с помощью действительного сертификата, вы сможете отправить пакет в Store. Дополнительные рекомендации по загрузке и отправке приложений в Store см. в разделе Отправка приложений.
Code Signing в Windows, просто и недорого
Хотел бы рассказать тут о такой важной особенности разработки под Windows как Code Signing. А ведь многие достаточно серьёзные разработчики до сих пор ей не пользуются, и очень зря. Помимо того что при запуске вашего неподписанного приложения появляется противная красная иконка с крестом и неприятным текстом:
«Этот файл не имеет цифровой подписи которая может подтвердить производителя. Вы должны запускать программы только от производителей которым доверяете.»
Это ещё и пропуск на корпоративный рынок.
При запуске неподписанной программы появляется такое окно: 
А так выглядит окно когда программа подписана:
Один важный момент, прежде чем получать сертификат, очень желательно зарегистрировать вашу компанию или ИП в агенстве Dun & Bradstreet и получить DUNS номер. Этот номер очень уважается компаниями которые выдают сертификаты и при предъявлении этого номера, в абсолютном большинстве случаев, более никаких подтверждающих документов не спрашивают. Иначе придётся высылать сканы уставных документов, а иногда и каких-нибудь счетов на компанию, например за телефон. Для получения сертификата на ИП это один из главных шагов. Без этого в случае ИП может вообще ничего не получиться.
Сам процесс подписания программы/инсталлятора достаточно простой и легко автоматизируется, если надо могу описать и его.
Вот собственно и всё. Если вы работаете на рынке программного обеспечения для windows — сертификат это важная и необходимая вещь. Я надо признать и сам стал избегать неподписанных программ после этого.
Создание сертификата для подписи пакета приложения
MakeCert.exe не рекомендуется к использованию. Текущие рекомендации по созданию сертификата см. в разделе Создание сертификата для подписания пакета.
узнайте, как использовать MakeCert.exe и Pvk2Pfx.exe для создания тестового сертификата подписи кода, чтобы вы могли подписывать пакеты приложений Windows.
перед развертыванием пакетной Windows приложения необходимо подписать цифровой подписью. если вы не используете Microsoft Visual Studio 2012 для создания и подписи пакетов приложений, необходимо создать собственные сертификаты для подписи кода и управлять ими. сертификаты можно создавать с помощью MakeCert.exe и Pvk2Pfx.exe из набора драйверов Windows (WDK). Затем можно использовать сертификаты для подписывания пакетов приложений, чтобы их можно было развернуть локально для тестирования.
Это важно знать
Технологии
Предварительные требования
Инструкции
Шаг 1. Определение имени издателя пакета
чтобы сделать сертификат подписи, который вы создадите, использовать с пакетом приложения, который необходимо подписать, имя субъекта сертификата подписи должно соответствовать атрибуту Publisher элемента Identity в AppxManifest.xml для этого приложения. Например, предположим, что AppxManifest.xml содержит:
Эта строка параметра указывается в кавычках и является учетом регистра и пробела.
Шаг 2. создание закрытого ключа с помощью MakeCert.exe
Используйте служебную программу MakeCert для создания самозаверяющего тестового сертификата и закрытого ключа:
Эта команда предложит указать пароль для PVK-файла. Рекомендуется выбрать надежный пароль и защитить закрытый ключ в безопасном месте.
Рекомендуется использовать предлагаемые параметры из предыдущего примера по следующим причинам.
Создает самозаверяющий корневой сертификат. Это упрощает управление тестовым сертификатом.
Помечает базовое ограничение для сертификата как конечную сущность. Это предотвращает использование сертификата в качестве центра сертификации (ЦС), который может выдавать другие сертификаты.
Задает значения расширенного использования ключа (EKU) для сертификата.
Не ставьте пробел между двумя значениями, разделенными запятыми.
Задает дату окончания срока действия сертификата. Укажите значение параметра expirationDate в формате мм/дд/гггг. Рекомендуется выбирать дату истечения срока действия, если это необходимо для целей тестирования, как правило, меньше года. Эта дата окончания срока действия в сочетании с ключом времени существования подписывания может помочь ограничить окно, в котором сертификат может быть скомпрометирован и недоступен.
Дополнительные сведения о других параметрах см. в разделе MakeCert.
шаг 3. создание файла личных данных Exchange (. pfx) с помощью Pvk2Pfx.exe
Файлы MyKey. PVK и MyKey. cer являются теми же файлами, которые MakeCert.exe созданы на предыдущем шаге. С помощью необязательного параметра/по можно указать другой пароль для результирующего PFX-файла; в противном случае PFX-файл имеет тот же пароль, что и MyKey. PVK.
Дополнительные сведения о других параметрах см. в разделе Pvk2Pfx.
Remarks
После создания PFX-файла можно использовать файл с помощью средства SignTool для подписания пакета приложения. Дополнительные сведения см. в разделе как подписать пакет приложения с помощью средства SignTool. Но сертификат по-прежнему не является доверенным для локального компьютера для развертывания пакетов приложений, пока он не будет установлен в хранилище доверенных сертификатов на локальном компьютере. Вы можете использовать Certutil.exe, который поставляется вместе с Windows.
Установка сертификатов с помощью WindowsCertutil.exe
Запустите Cmd.exe от имени администратора.
Выполните следующую команду:
Рекомендуется удалить сертификаты, если они больше не используются. В той же командной строке администратора выполните следующую команду:
CertID — серийный номер сертификата. Выполните следующую команду, чтобы определить серийный номер сертификата:
Соображения безопасности
Добавив сертификат в хранилища сертификатов локальной машины, вы меняете доверие сертификатов всех пользователей на компьютере. Рекомендуется установить все сертификаты подписи кода, необходимые для тестирования пакетов приложений в хранилище сертификатов «Доверенные лица». Немедленно удалите эти сертификаты, когда они больше не нужны, чтобы предотвратить их использование для компрометации доверия системы.
Связанные темы
Примеры
Основные понятия
How to sign an app package using SignTool (Подписывание пакета приложения с помощью SignTool)
Подписывание пакета приложения Windows 10
Подписывание пакета приложения — это обязательный шаг в процессе создания развертываемых пакетов приложений Windows 10. В Windows 10 все приложения должны быть подписаны с помощью допустимого сертификата для подписи кода.
Для успешной установки приложения для Windows 10 пакет не только подписывается, но и настраивается как надежный на устройстве. Это означает, что сертификат должен быть связан с одним из доверенных корневых сертификатов на устройстве. По умолчанию в Windows 10 настроено доверие к сертификатам от большинства центров сертификации, предоставляющих сертификаты для подписи кода.
| Раздел | Описание |
|---|---|
| Необходимые условия для подписывания | В этом разделе описаны предварительные требования, которые нужно удовлетворить, прежде чем подписывать пакет приложения Windows 10. |
| Использование SignTool | В этом разделе описано, как подписать пакет приложения с помощью средства SignTool из пакета SDK для Windows 10. |
| Подписывание пакета MSIX с помощью подписи Device Guard | В этом разделе описывается, как подписать приложение с помощью подписи Device Guard. |
Установка меток времени
Настоятельно рекомендуется использовать метки времени при подписывании приложения с помощью сертификата. Это действие сохраняет подпись, обеспечивая принятие пакета приложений платформой развертывания приложения, даже если срок действия сертификата истек. Во время проверки пакета метка времени позволяет проверить подпись пакета с учетом времени подписывания. Такие пакеты будут приняты, даже если сертификат недействителен. Пакеты без меток времени будут проверяться с учетом текущего времени и, если сертификат недействителен, Windows не примет такой пакет.
Ниже описаны разные сценарии подписывания приложения с использованием меток времени и без них.
| Приложение подписано без метки времени | Приложение подписано с меткой времени | |
|---|---|---|
| Сертификат действительный | Приложение будет установлено. | Приложение будет установлено. |
| Сертификат недействительный (срок действия истек) | Приложение не будет установлено. | Приложение будет установлено, так как подлинность сертификата была проверена при подписывании центром меток времени. |
Если приложение установлено на устройстве, оно будет выполняться даже после истечения срока действия сертификата независимо от того, были ли установлены метки.
Режим устройства
Windows 10 позволяет пользователям выбирать следующие режимы работы устройства в настройках приложения: «Приложения Microsoft Store», «Неопубликованные приложения» и «Режим разработчика».
Приложения Microsoft Store — это самый безопасный режим, так как он разрешает установку приложений только из Microsoft Store. Приложения в Microsoft Store проходят процесс сертификации, гарантирующий, что приложения безопасны для использования.
Неопубликованные приложения и Режим разработчика — это менее строгие режимы использования приложений, которые были подписаны с помощью других сертификатов, которые являются доверенными и которые связаны с одним из доверенных корневых сертификатов на устройстве. Выбирайте режим разработчика, только если вы являетесь разработчиком, который создает или отлаживает приложения для Windows 10. См. подробнее о режиме разработчика.
Создание сертификата для подписания пакета
В этой статье объясняется, как создать и экспортировать сертификат для подписывания пакета приложений с помощью инструментов PowerShell. рекомендуется использовать Visual Studio для упаковки приложений UWP и упаковки настольных приложений, но вы по-прежнему можете упаковать приложение вручную, если вы не использовали Visual Studio для разработки приложения.
Необходимые компоненты
Упакованное или распакованное приложение
Приложение, содержащее файл AppxManifest.xml. При создании сертификата, который будет использоваться для подписывания окончательного пакета приложений, потребуется сослаться на этот файл манифеста. Сведения о том, как вручную упаковать приложение, см. в разделе Создание пакета приложений с помощью инструмента MakeAppx.exe.
Командлеты инфраструктуры открытых ключей (PKI)
Вам потребуются командлеты PKI для создания и экспорта сертификата для подписи. Дополнительные сведения см. в разделе Командлеты инфраструктуры открытых ключей.
Создание самозаверяющего сертификата.
Самозаверяющий сертификат полезен для тестирования приложения, прежде чем вы будете готовы опубликовать его в магазине. Выполните действия, описанные в этом разделе, чтобы создать самозаверяющий сертификат.
При создании и использовании самозаверяющего сертификата только пользователи, которые устанавливают и доверяют сертификату, могут запускать приложение. Это легко реализовать для тестирования, но это может препятствовать установке дополнительных пользователей в приложение. Когда вы будете готовы опубликовать приложение, рекомендуется использовать сертификат, выданный доверенным источником. Эта система централизованного доверия помогает убедиться, что экосистема приложений имеет уровни проверки для защиты пользователей от вредоносных субъектов.
Определение субъекта вашего упакованного приложения
Чтобы использовать сертификат для подписывания пакета приложений, значение в поле сертификата «Субъект» должно совпадать с данными в разделе «Издатель» манифеста вашего приложения.
Например, раздел «Идентификатор» файла AppxManifest.xml вашего приложения должен выглядеть примерно следующим образом:
«Издатель» в данном случае — «CN=Contoso Software, O=Contoso Corporation, C=US», и именно его следует использовать для создания сертификата.
Использование командлета New-SelfSignedCertificate для создания сертификата
Используйте командлет PowerShell New-SelfSignedCertificate для создания самозаверяющего сертификата. Командлет New-SelfSignedCertificate имеет несколько параметров для настройки, однако в этой статье мы сконцентрируемся на создании простого сертификата, который будет работать вместе с SignTool. Дополнительные примеры и варианты использования этого командлета см. в статье New-SelfSignedCertificate.
Основываясь на файле AppxManifest.xml из предыдущего примера, используйте следующий синтаксис для создания сертификата. В строке с повышенными привилегиями PowerShell:
Обратите внимание на следующие сведения о некоторых параметрах.
Кэйусаже. Этот параметр определяет, для чего может использоваться сертификат. Для самозаверяющего сертификата этот параметр должен иметь значение дигиталсигнатуре.
Текстекстенсион: этот параметр включает параметры для следующих расширений:
Расширенное использование ключа (EKU). это расширение указывает дополнительные цели, для которых может использоваться сертифицированный открытый ключ. Для самозаверяющего сертификата этот параметр должен включать строку расширения «2.5.29.37 =
Основные ограничения. это расширение указывает, является ли сертификат центром сертификации (ЦС). Для самозаверяющего сертификата этот параметр должен включать строку расширения «2.5.29.19 =
После выполнения этой команды сертификат будет добавлен в локальное хранилище сертификатов, как указано в параметре «-CertStoreLocation». Результат выполнения команды также будет выдавать отпечаток сертификата.
Сертификат можно просмотреть в окне PowerShell, выполнив следующие команды:
Это позволит отобразить все сертификаты в вашем локальном хранилище.
Экспорт сертификата
Чтобы экспортировать сертификат из локального хранилища в файл обмена личной информацией (PFX), используйте командлет Export-PfxCertificate.
При использовании командлета Export-PfxCertificate следует либо создать и использовать пароль, либо с помощью параметра «-ProtectTo» указать, какие пользователи или группы могут осуществлять доступ к файлу без пароля. Обратите внимание, что если вы не используете параметр «-Password» или «-ProtectTo», отобразится ошибка.
Использование пароля
Использование ProtectTo
После создания и экспорт сертификата вы готовы подписать пакет приложений с помощью SignTool. Следующий шаг в процессе упаковки вручную описан в разделе Подпись пакета приложения с использованием инструмента SignTool.
Вопросы безопасности
Добавив сертификат в хранилища сертификатов локальной машины, вы меняете доверие сертификатов всех пользователей на компьютере. Рекомендуется удалить эти сертификаты, когда они больше не требуется, чтобы их невозможно было использовать для нарушения доверия системы.