Freigeben über

Signieren eines MSIX-Pakets

App-Paketsignierung ist ein erforderlicher Schritt beim Erstellen eines MSIX-Pakets, das bereitgestellt werden kann. Windows erfordert, dass MSIX-Pakete mit einem gültigen Codesignaturzertifikat signiert werden.

Um eine Windows Anwendung erfolgreich zu installieren, muss das Paket nicht nur signiert, sondern auch auf dem Gerät vertrauenswürdig sein. Das bedeutet, dass das Zertifikat sich auf eines der vertrauenswürdigen Stammzertifikate auf dem Gerät ableiten lassen muss. Standardmäßig vertraut Windows Zertifikaten von den meisten Zertifizierungsstellen, die Codesignaturzertifikate bereitstellen.

Wenn Sie ein MSIX-Bundle erstellen, ist es außerdem nicht erforderlich, alle Pakete im Bundle einzeln zu signieren. Nur das Bündel muss signiert werden; die Signatur deckt die Pakete innerhalb des Bündels ab.

Signaturoptionen

Wählen Sie einen Signaturansatz basierend auf Ihrem Szenario aus:

Szenario Auswahl Cost
Entwicklung und lokale Tests Selbstsigniertes Zertifikat Kostenlos
Produktionsverteilung (empfohlen) Azure Artifact Signing (früher vertrauenswürdige Signatur) Einfach: ~$10/Monat
Produktionsverteilung (Alternative) OV-Codesignaturzertifikat von einer Zertifizierungsstelle $ 300–500/Jahr
Microsoft Store Vertrieb Vom Store bei der Übermittlung signiert Kostenlos

Hinweis

Azure Artifact Signing (früher als vertrauenswürdige Signatur bezeichnet) ist der verwaltete Codesignaturdienst Microsoft und ist die empfohlene Option für die MSIX-Produktionssignierung. Wichtige Merkmale:

  • Identitätsbasierte Reputation: Der Ruf ist an Ihre überprüfte Herausgeberidentität und nicht an ein bestimmtes Zertifikat gebunden, sodass sie sich über Builds hinweg ansammelt. Wie alle anderen Nicht-Store-Verteilungen werden neue Apps jedoch weiterhin SmartScreen-Warnungen anzeigen, bis genügend Downloadverlauf aufgebaut ist. Dies dauert in der Regel mehrere Wochen. Siehe SmartScreen-Reputation für Windows App-Entwickler.
  • Kurzlebige Zertifikate: Täglich wird ein neues Zertifikat ausgestellt, und jedes Zertifikat bleibt etwa 3 Tage lang gültig und ermöglicht bei Bedarf einen zeitgenauen Widerruf.
  • CI/CD ready: Unterstützt GitHub Actions (azure/trusted-signing-action) und Azure DevOps sofort einsatzbereit.

Berechtigung für Public Trust-Zertifikate: Für Organisationen in den USA, Kanada, der Europäischen Union und im Vereinigten Königreich sowie für einzelne Entwickler in den USA und Kanada verfügbar. Organisationen müssen über einen nachweisbaren Steuerverlauf von drei oder mehr Jahren verfügen. Informationen zur Identitätsüberprüfung finden Sie unter "Wichtige Informationen".

Signing mit SignTool erfordert zusätzliches Setup: SignTool funktioniert nur mit der Artefaktsignierung, wenn Sie die Artifact Signing Client Tools verwenden, die das erforderliche dlib-Plug-in und die .NET 8 Laufzeitumgebung enthalten. Sie müssen auch eine metadata.json Datei mit Ihrem Kontoendpunkt und Zertifikatprofil bereitstellen. Ein standardmäßiger Windows SDK SignTool-Aufruf selbst funktioniert nicht mit Artefaktsignierung. Die einfachste Installation ist:

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

Siehe Einrichten von SignTool mit Artefaktsignierung für das vollständige Setup.

AzureSignTool ist ein separates Communitytool zum Signieren mit Zertifikaten, die in Azure Key Vault gespeichert sind. Die Artefaktsignierung wird nicht unterstützt – die beiden sind unterschiedliche Dienste. Informationen zur Azure Key Vault-basierten Anmeldung in Visual Studio finden Sie unter Sign-Pakete mit Azure Key Vault.

WinApp CLI

Die WinApp CLI bietet praktische Befehle für die Entwicklungssignierung:

  • winapp cert generate — Erstellen eines selbstsignierten Zertifikats für die Entwicklung
  • winapp sign — Signieren eines MSIX-Pakets oder einer ausführbaren Datei mit einem Zertifikat
  • winapp tool signtool – greifen Sie direkt über das Windows SDK auf SignTool zu.

Signieren von Themen

Thema BESCHREIBUNG
Voraussetzungen für das Signieren Erforderliche Voraussetzungen zum Signieren eines App-Pakets.
SignTool verwenden Verwenden von SignTool aus dem Windows SDK zum Signieren eines App-Pakets.
Pakete mit Azure Key Vault signieren So signieren Sie Pakete mithilfe eines Zertifikats, das in Azure Key Vault von Visual Studio gespeichert ist.
Signieren eines MSIX-Pakets mit Device Guard-Signatur So signieren Sie Ihre App mit device Guard-Signatur.
Erstellen von unsignierten Paketen für Tests Erstellen eines nicht signierten MSIX-Pakets zum Testen.
Azure Artifact Signing Von Microsoft verwalteter Signaturdienst (ehemals Vertrauenswürdige Signatur) für MSIX-Produktionspakete.

Zeitstempelung

Es wird dringend empfohlen, beim Signieren Ihrer App mit einem Zertifikat Zeitstempel zu verwenden. Beim Zeitstempeln wird die Signatur beibehalten, sodass das App-Paket auch nach Ablauf des Zertifikats von der App-Bereitstellungsplattform weiterhin akzeptiert werden kann. Zum Zeitpunkt der Paketinspektion ermöglicht der Zeitstempel die Validierung der Paketsignatur in Bezug auf den Zeitpunkt, zu dem sie signiert wurde. Auf diese Weise können Pakete auch dann akzeptiert werden, wenn das Zertifikat nicht mehr gültig ist. Pakete, die nicht zeitstempelt sind, werden für die aktuelle Uhrzeit ausgewertet, und wenn das Zertifikat nicht mehr gültig ist, akzeptiert Windows das Paket nicht.

Im Folgenden sind die verschiedenen Szenarien für das Signieren von Apps mit/ohne Zeitstempel aufgeführt:

Szenario App wird ohne Zeitstempel signiert Die App ist mit Zeitstempel signiert
Zertifikat ist gültig Die App wird installiert Die App wird installiert
Zertifikat ist ungültig (abgelaufen) Die App kann nicht installiert werden Die App wird installiert, da die Authentizität des Zertifikats beim Signieren durch die Zeitstempelstelle überprüft wurde.

Hinweis

Wenn die App erfolgreich auf einem Gerät installiert wurde, wird sie auch nach Ablauf des Zertifikats weiterhin ausgeführt, unabhängig davon, ob es einen Zeitstempel hat oder nicht.

Durchsetzung der Paketintegrität

Zusätzlich zur Sicherstellung, dass nur vertrauenswürdige Anwendungen auf einem Gerät installiert werden, bietet das Signieren eines MSIX-Pakets zusätzliche Vorteile, dass es Windows ermöglicht, die Integrität Ihres Pakets und dessen Inhalte nach der Bereitstellung auf einem Gerät zu erzwingen. Durch die Verknüpfung mit der AppxBlockMap.xml und AppxSignature.p7x in einem signierten Paket kann Windows Überprüfungen der Integrität eines Pakets und seiner Inhalte zur Laufzeit, sowie während der Scans von Windows Defender durchführen. Wenn ein Paket als manipuliert eingestuft wird, blockiert Windows den Start der Anwendung und startet einen Wartungsworkflow, um das Paket zu reparieren oder neu zu installieren. Für Pakete, die nicht über die Microsoft Store verteilt werden, wird die Paketintegrität erzwungen, wenn das Paket das uap10:PackageIntegrity-Element deklariert und auf Windows 2004 und höheren Builds bereitgestellt wird. Nachfolgend finden Sie ein Beispiel für eine Deklaration der Durchsetzung der Paketintegrität in der 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>

Geräte-Modus

mit Windows 10 können Benutzer den Modus auswählen, in dem ihr Gerät in der Einstellungs-App ausgeführt werden soll. Die Modi sind Microsoft Store Apps, Querladen von Apps und Entwicklermodus.

Microsoft Store Apps ist die sicherste, da sie nur die Installation von Apps aus dem Microsoft Store zulässt. Apps im Microsoft Store durchlaufen den Zertifizierungsprozess, um sicherzustellen, dass die Apps sicher zur Verwendung sind.

Sideload-Apps und der Entwicklermodus sind für Apps, die durch andere Zertifikate signiert wurden, zulässiger, solange diese Zertifikate vertrauenswürdig sind und zu einem der vertrauenswürdigen Stammzertifikate auf dem Gerät ketten. Wählen Sie nur den Entwicklermodus aus, wenn Sie Entwickler sind und Windows 10 Apps erstellen oder debuggen. Weitere Informationen zum Entwicklermodus und seinen Möglichkeiten finden Sie hier.

Hinweis

Ab Windows 10 Version 2004 ist die Option "Querladen" standardmäßig aktiviert. Daher ist der Entwicklermodus jetzt ein Umschalter. Unternehmen können das Querladen weiterhin über die Richtlinie deaktivieren.

  • Last updated on