Podpisywanie pakietu MSIX

Podpisywanie pakietu aplikacji jest wymaganym krokiem procesu tworzenia pakietu MSIX, który można wdrożyć. Windows wymaga podpisania pakietów MSIX przy użyciu prawidłowego certyfikatu podpisywania kodu.

Aby pomyślnie zainstalować aplikację Windows, pakiet nie tylko musi być podpisany, ale również zaufany na urządzeniu. Oznacza to, że certyfikat musi być połączony z jednym z zaufanych certyfikatów głównych na urządzeniu. Domyślnie Windows ufa certyfikatom z większości urzędów certyfikacji, które zapewniają certyfikaty podpisywania kodu.

Ponadto, jeśli tworzysz pakiet MSIX, nie ma potrzeby podpisywania wszystkich pakietów w pakiecie indywidualnie. Tylko pakiet musi być podpisany; podpis obejmuje pakiety wewnątrz pakietu.

Opcje podpisywania

Wybierz podejście podpisywania w zależności od scenariusza:

Scenariusz Option Koszt
Programowanie i testowanie lokalne Certyfikat z podpisem własnym Bezpłatna
Dystrybucja produkcyjna (zalecana) Azure Podpisywanie artefaktów (wcześniej Trusted Signing) Podstawowa: ~$10/miesiąc
Dystrybucja produkcyjna (alternatywna) Certyfikat podpisywania kodu OV z urzędu certyfikacji 300–500 USD/rok
Microsoft Store - dystrybucja Podpisany przez Sklep podczas przesyłania Bezpłatna

Uwaga / Notatka

Azure Podpisywanie Artefaktów (wcześniej znane jako Zaufane Podpisywanie) jest usługą zarządzanego podpisywania kodu firmy Microsoft i jest zalecaną opcją podpisywania w środowisku produkcyjnym MSIX. Kluczowe cechy:

  • Reputacja oparta na tożsamości: reputacja jest powiązana z zweryfikowaną tożsamością wydawcy, a nie określonym certyfikatem, więc gromadzi się w ramach kompilacji. Jednak, podobnie jak w przypadku wszystkich dystrybucji innych niż Sklep, nowe aplikacje będą nadal wyświetlać ostrzeżenia filtru SmartScreen, dopóki nie zbuduje się wystarczająca historia pobierania — zwykle trwa to kilka tygodni. Zobacz reputację SmartScreen dla deweloperów aplikacji Windows.
  • Certyfikaty krótkotrwałe: Nowy certyfikat jest wystawiany codziennie, a każdy certyfikat pozostaje ważny przez około 3 dni, umożliwiając dokładne odwoływanie w razie potrzeby.
  • CI/CD gotowe: Obsługuje GitHub Actions (azure/trusted-signing-action) i Azure DevOps bez potrzeby konfiguracji.

Uprawnienia do certyfikatów zaufania publicznego: dostępne dla organizacji w USA, Kanadzie, Unii Europejskiej i Wielkiej Brytanii oraz dla indywidualnych deweloperów w USA i Kanadzie. Organizacje muszą mieć zweryfikowaną historię podatku od trzech lub więcej lat. Zobacz Ważne informacje na temat weryfikacji tożsamości.

Podpisywanie za pomocą SignTool wymaga dodatkowej konfiguracji: Narzędzie SignTool współpracuje z podpisywaniem artefaktów tylko wtedy, gdy używasz narzędzi klienckich podpisywania artefaktów, które obejmują wymaganą wtyczkę dlib i środowisko uruchomieniowe .NET 8. Musisz również podać plik z punktem końcowym konta i profilem certyfikatu metadata.json. Wywołanie standardowego narzędzia SignTool z Windows SDK samo w sobie nie będzie działać z podpisywaniem artefaktów. Najprostszą instalacją jest:

winget install -e --id Microsoft.Azure.ArtifactSigningClientTools

Aby uzyskać pełną konfigurację, zobacz Konfigurowanie narzędzia SignTool z podpisywaniem artefaktów .

AzureSignTool to oddzielne narzędzie społeczności do podpisywania przy użyciu certyfikatów przechowywanych w Azure Key Vault. Nie obsługuje podpisywania artefaktów — te dwa są odrębnymi usługami. Aby uzyskać informacje na temat podpisywania z użyciem Azure Key Vault w Visual Studio, zobacz Podpisywanie pakietów z Azure Key Vault.

Interfejs wiersza polecenia usługi WinApp

WinApp CLI udostępnia wygodne polecenia do podpisywania aplikacji.

  • winapp cert generate — tworzenie certyfikatu z podpisem własnym na potrzeby programowania
  • winapp sign — podpisywanie pakietu MSIX lub pliku wykonywalnego przy użyciu certyfikatu
  • winapp tool signtool — uzyskaj dostęp do narzędzia SignTool bezpośrednio z zestawu SDK Windows

Tematy dotyczące podpisywania

Temat Opis
Wymagania wstępne dotyczące podpisywania Wymagania wstępne wymagane do podpisania pakietu aplikacji.
Korzystanie z narzędzia SignTool Jak używać narzędzia SignTool z zestawu SDK Windows do podpisywania pakietu aplikacji.
Podpisz pakiety za pomocą Azure Key Vault Jak podpisywać pakiety przy użyciu certyfikatu przechowywanego w Azure Key Vault z Visual Studio.
Podpisz pakiet MSIX za pomocą podpisu Device Guard Jak podpisać aplikację przy użyciu podpisu Device Guard.
Tworzenie niepodpisanych pakietów na potrzeby testowania Jak utworzyć niepodpisany pakiet MSIX na potrzeby testowania.
Azure Podpisywanie artefaktów Usługa zarządzanego podpisywania Microsoft (wcześniej Trusted Signing) dla produkcyjnych pakietów MSIX.

Znaczniki czasu

Zdecydowanie zaleca się użycie znacznika czasu podczas podpisywania aplikacji przy użyciu certyfikatu. Znacznik czasu zachowuje podpis umożliwiający akceptowanie pakietu aplikacji przez platformę wdrażania aplikacji nawet po wygaśnięciu certyfikatu. W czasie inspekcji pakietu sygnatura czasowa umożliwia zweryfikowanie podpisu pakietu w odniesieniu do czasu jego podpisania. Dzięki temu pakiety mogą być akceptowane nawet po tym, jak certyfikat nie jest już ważny. Pakiety, które nie są opatrzone znacznikiem czasu, będą oceniane względem bieżącego czasu. Jeśli certyfikat nie jest już ważny, system Windows nie zaakceptuje pakietu.

Poniżej przedstawiono różne scenariusze dotyczące podpisywania aplikacji z/bez oznaczania czasem:

Scenariusz Aplikacja jest podpisana bez znacznika czasu Aplikacja jest podpisana przy użyciu znacznika czasu
Certyfikat jest prawidłowy Aplikacja zostanie zainstalowana Aplikacja zostanie zainstalowana
Certyfikat jest nieprawidłowy (wygasły) Instalacja aplikacji nie powiedzie się Aplikacja zostanie zainstalowana, ponieważ autentyczność certyfikatu została zweryfikowana podczas podpisywania przez autorytet stemplowania czasowego.

Uwaga / Notatka

Jeśli aplikacja została pomyślnie zainstalowana na urządzeniu, będzie ona nadal działać nawet po wygaśnięciu certyfikatu niezależnie od tego, czy jest to sygnatura czasowa, czy nie.

Wymuszanie integralności pakietów

Oprócz zapewnienia, że na urządzeniu są zainstalowane tylko zaufane aplikacje, dodatkową zaletą podpisywania pakietu MSIX jest umożliwienie Windows wymuszania integralności pakietu i jego zawartości po wdrożeniu na urządzeniu. Łącząc się z AppxBlockMap.xml i AppxSignature.p7x w podpisanym pakiecie, Windows jest w stanie przeprowadzić sprawdzanie integralności pakietu i jego zawartości podczas wykonywania oraz podczas skanowania przez Windows Defender. Jeśli pakiet zostanie uznany za naruszony Windows zablokuje uruchomienie aplikacji i uruchomienie przepływu pracy korygowania w celu naprawienia lub ponownego zainstalowania pakietu. W przypadku pakietów, które nie są dystrybuowane za pośrednictwem Microsoft Store, integralność pakietu jest wymuszana, jeśli pakiet deklaruje uap10:PackageIntegrity element i jest wdrażany w Windows 2004 i nowszych kompilacjach. Poniżej znajduje się przykładowa deklaracja wymuszania integralności pakietu w AppxManifest.xml:

<Package ...
xmlns:uap10="http://schemas.microsoft.com/appx/manifest/uap/windows10/10"  
IgnorableNamespaces="uap10">
...
  <Properties>
    <uap10:PackageIntegrity>
      <uap10:Content Enforcement="on" />
    </uap10:PackageIntegrity>
  </Properties>
...
</Package>

Tryb urządzenia

Windows 10 umożliwia użytkownikom wybieranie trybu uruchamiania urządzenia w aplikacji Ustawienia. Tryby obejmują aplikacje Microsoft Store, aplikacje zewnętrzne i tryb deweloperski.

Aplikacje ze Sklepu Microsoft są najbezpieczniejsze, ponieważ zezwalają tylko na instalowanie aplikacji ze Sklepu Microsoft. Aplikacje w Microsoft Store przechodzą przez proces certyfikacji, aby upewnić się, że aplikacje są bezpieczne do użycia.

Aplikacje ładowane bezpośrednio i tryb dewelopera są bardziej permisywne dla aplikacji podpisanych przez inne certyfikaty, o ile te certyfikaty są zaufane i łączą je z jednym z zaufanych katalogów głównych na urządzeniu. Wybierz tryb dewelopera tylko wtedy, gdy jesteś deweloperem i kompilujesz lub debugujesz aplikacje Windows 10. Więcej informacji na temat trybu dewelopera i dostępnych w nim informacji można znaleźć tutaj.

Uwaga / Notatka

Od Windows 10 wersji 2004, opcja Sideloading jest domyślnie włączona. W związku z tym tryb dewelopera jest teraz przełącznikiem. Przedsiębiorstwa nadal mogą wyłączyć ładowanie bezpośrednie poprzez politykę.

  • Last updated on