Signera ett MSIX-paket

Signering av apppaket är ett obligatoriskt steg i processen att skapa ett MSIX-paket som kan distribueras. Windows kräver att MSIX-paket signeras med ett giltigt kodsigneringscertifikat.

För att framgångsrikt installera en Windows-applikation måste paketet inte bara signeras utan också litas på på enheten. Det innebär att certifikatet måste länkas till en av de betrodda rötterna på enheten. Som standard litar Windows på certifikat från de flesta certifikatutfärdare som tillhandahåller kodsigneringscertifikat.

Om du skapar ett MSIX-paket behöver du dessutom inte signera alla paket i paketet individuellt. Endast paketet behöver signeras. signaturen täcker paketen i paketet.

Signeringsalternativ

Välj en signeringsmetod baserat på ditt scenario:

Scenarium Option Kostnad
Utveckling och lokal testning Självsignerat certifikat Kostnadsfri
Produktionsdistribution (rekommenderas) Azure Artefaktsignering (tidigare Betrodd Signering) Basic: ca $10/månad
Produktionsdistribution (alternativ) OV-kodsigneringscertifikat från en certifikatutfärdare $300–500/år
Microsoft Store distribution Signerad av butiken vid inskickning Kostnadsfri

Anmärkning

Azure Artifact Signing (kallades tidigare betrodd signering) är Microsoft hanterade kodsigneringstjänst och är det rekommenderade alternativet för MSIX-signering i produktion. Viktiga egenskaper:

  • Identitetsbaserat rykte: Ryktet är kopplat till din verifierade utgivaridentitet i stället för ett specifikt certifikat, så det ackumuleras över versioner. Men precis som alla icke-Store-distributioner visar nya appar fortfarande SmartScreen-varningar tills tillräcklig nedladdningshistorik har byggts – det tar vanligtvis flera veckor. Se SmartScreen-rykte för Windows apputvecklare.
  • Kortlivade certifikat: Ett nytt certifikat utfärdas dagligen och varje certifikat förblir giltigt i cirka 3 dagar, vilket möjliggör tidsbegränsat återkallande om det behövs.
  • CI/CD klar: Stöder GitHub Actions (azure/trusted-signing-action) och Azure DevOps direkt.

Berättigande till Public Trust-certifikat: Tillgängligt för organisationer i USA, Kanada, Europeiska unionen och Storbritannien samt för enskilda utvecklare i USA och Kanada. Organisationer måste ha en verifierbar skattehistorik på tre eller fler år. Se Viktig information för identitetsverifiering.

Signing with SignTool kräver extra installation: SignTool fungerar endast med artefaktsignering när du använder klientverktygen för artefaktsignering, som innehåller det nödvändiga dlib-plugin-programmet och .NET 8-körning. Du måste också ange en metadata.json fil med kontoslutpunkten och certifikatprofilen. En standard-Windows SDK SignTool-anrop i sig fungerar inte med artefaktsignering. Den enklaste installationen är:

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

Se Konfigurera SignTool med artefaktsignering för den fullständiga konfigurationen.

AzureSignTool är ett separat communityverktyg för signering med certifikat som lagras i Azure Key Vault. Det stöder inte artefaktsignering – de två är distinkta tjänster. Information om Azure Key Vault-baserad inloggning i Visual Studio finns i Signera paket med Azure Key Vault.

WinApp CLI

WinApp CLI tillhandahåller praktiska kommandon för utvecklingssignering:

  • winapp cert generate — skapa ett självsignerat certifikat för utveckling
  • winapp sign — signera ett MSIX-paket eller körbar fil med ett certifikat
  • winapp tool signtool – åtkomst till SignTool direkt från Windows SDK

Ämnen för signering

Ämne Beskrivning
Förutsättningar för signering Krav som krävs för att signera ett apppaket.
Att använda SignTool Så här använder du SignTool från Windows SDK för att signera ett apppaket.
Signera paket med Azure Key Vault Så här signerar du paket med ett certifikat som lagras i Azure Key Vault från Visual Studio.
Signera ett MSIX-paket med Device Guard-signering Så här signerar du din app med Device Guard-signering.
Skapa osignerade paket för testning Så här skapar du ett osignerat MSIX-paket för testning.
Azure Artifaktsignering Microsofts hanterade signeringstjänst (tidigare betrodd signering) för MSIX-paket för produktion.

Tidsstämpling

Vi rekommenderar starkt att tidsstämpling används när du signerar din app med ett certifikat. Tidsstämpling bevarar signaturen så att apppaketet kan godkännas av appdistributionsplattformen även efter att certifikatet har upphört att gälla. Vid paketgranskningstiden tillåter tidsstämpeln att paketsignaturen verifieras med avseende på den tid då den undertecknades. Detta gör att paket kan accepteras även efter att certifikatet inte längre är giltigt. Paket som inte tidsstämplas utvärderas mot den aktuella tiden och om certifikatet inte längre är giltigt accepterar Windows inte paketet.

Följande är de olika scenarierna kring appsignering med/utan tidsstämpling.

Scenarium Appen signeras utan tidsstämpling Appen är signerad med tidsstämpling
Certifikatet är giltigt Appen kommer att installeras Appen kommer att installeras
Certifikatet är ogiltigt(har upphört att gälla) Det går inte att installera appen Appen kommer att installeras eftersom certifikatets äkthet verifierades vid signering av tidsstämpelsmyndigheten.

Anmärkning

Om appen har installerats på en enhet fortsätter den att köras även efter att certifikatet har upphört att gälla oavsett om det är tidsstämplat eller inte.

Tvingande av paketintegritet

Förutom att säkerställa att endast betrodda program installeras på en enhet är en ytterligare fördel med att signera ett MSIX-paket att det gör det möjligt för Windows att framtvinga integriteten för ditt paket och dess innehåll när det har distribuerats på en enhet. Genom att länka till AppxBlockMap.xml och AppxSignature.p7x i ett signerat paket kan Windows utföra valideringskontroller av ett pakets integritet och dess innehåll vid körning och under Windows Defender genomsökningar. Om ett paket anses vara manipulerat blockerar Windows programstarten och startar ett reparationsarbetsflöde för att få paketet reparerat eller ominstallerat. För paket som inte distribueras via Microsoft Store tillämpas paketintegriteten om paketet deklarerar elementet uap10:PackageIntegrity och distribueras på Windows 2004 och senare versioner. Nedan visas en exempeldeklaration av efterlevnad av paketintegritet i 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>

Enhetsläge

Windows 10 tillåter användare att välja det läge där enheten ska köras i appen Inställningar. Lägena är Microsoft Store-appar, Sidladdade appar och Utvecklarläge.

Microsoft Store appar är den säkraste eftersom den endast tillåter installation av appar från Microsoft Store. Appar i Microsoft Store gå igenom certifieringsprocessen för att säkerställa att apparna är säkra att använda.

Sidladda appar och utvecklarläge är mer flexibla för appar som är signerade av andra certifikat, så länge dessa certifikat är betrodda och kopplade till en av de betrodda säkerhetscertifikaten på enheten. Välj endast Utvecklarläge om du är utvecklare och skapar eller felsöker Windows 10 appar. Mer information om utvecklarläge och vad det ger finns här.

Anmärkning

Från och med Windows 10 version 2004 är alternativet Sidoöverföring aktiverat som standard. Därför är utvecklarläget nu en växlingsknapp. Företag kan fortfarande inaktivera sidladdning genom en policy.

  • Last updated on