Signer un package MSIX

La signature de package d’application est une étape requise dans le processus de création d’un package MSIX qui peut être déployé. Windows nécessite que les packages MSIX soient signés avec un certificat de signature de code valide.

Pour installer correctement une application Windows, le package ne doit pas seulement être signé, mais également approuvé sur l'appareil. Cela signifie que le certificat doit être chaîné à l’une des racines de confiance sur l’appareil. Par défaut, Windows approuve les certificats de la plupart des autorités de certification qui fournissent des certificats de signature de code.

En outre, si vous créez un bundle MSIX, il n’est pas nécessaire de signer tous les packages dans le bundle individuellement. Seule l’offre groupée doit être signée ; la signature couvre les paquets à l’intérieur de l’offre groupée.

Options de signature

Choisissez une approche de signature basée sur votre scénario :

Scénario Choix Coûts
Développement et tests locaux Certificat auto-signé Gratuit
Distribution de production (recommandée) Azure Artifact Signing (anciennement Signature de confiance) De base : ~$10/mois
Distribution de production (alternative) Certificat de signature de code OV provenant d’une autorité de certification 300 à 500 $ par an
distribution sur le Microsoft Store Signé par le Windows Store lors de la soumission Gratuit

Remarque

Azure Signature d'artefact (anciennement signature approuvée) est le service de signature de code managé de Microsoft et est l'option recommandée pour la signature MSIX de production. Principales caractéristiques :

  • Réputation basée sur l’identité : la réputation est liée à votre identité d’éditeur vérifiée plutôt qu’à un certificat spécifique, de sorte qu’elle s’accumule au fil des builds. Toutefois, comme toutes les distributions non-Store, les nouvelles applications affichent toujours des avertissements SmartScreen jusqu’à ce qu’un historique de téléchargement suffisant soit constitué, ce qui prend généralement plusieurs semaines. Consultez la réputation SmartScreen pour les développeurs d’applications Windows.
  • Certificats de courte durée : un nouveau certificat est émis quotidiennement et chaque certificat reste valide pendant environ 3 jours, ce qui permet une révocation précise dans le temps si nécessaire.
  • CI/CD prêt : prend en charge GitHub Actions (azure/trusted-signing-action) et Azure DevOps prête à l’emploi.

Éligibilité aux certificats de confiance publique : disponible pour les organisations aux États-Unis, au Canada, à l’Union européenne et au Royaume-Uni, ainsi qu’aux développeurs individuels aux États-Unis et au Canada. Les organisations doivent avoir une histoire fiscale vérifiable de trois ans ou plus. Consultez les informations importantes pour la validation d’identité.

Signing with SignTool nécessite une configuration supplémentaire : SignTool fonctionne avec la signature d’artefact uniquement lorsque vous utilisez les outils client de signature d’artefact, qui incluent le plug-in dlib requis et .NET 8 runtime. Vous devez également fournir un metadata.json fichier avec votre point de terminaison de compte et votre profil de certificat. Un appel standard de Windows SDK SignTool en soi ne fonctionne pas avec la signature d'artefacts. L’installation la plus simple est la suivante :

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

Consultez Configurer SignTool avec la signature d’artefact pour la configuration complète.

AzureSignTool est un outil de communauté distinct pour la signature avec des certificats stockés dans Azure Key Vault. Il ne prend pas en charge la signature d’artefact : les deux sont des services distincts. Pour la signature basée sur Azure Key Vault dans Visual Studio, consultez Signer des packages avec Azure Key Vault.

WinApp CLI

L’interface CLI WinApp fournit des commandes pratiques pour la signature de développement :

  • winapp cert generate — créer un certificat auto-signé pour le développement
  • winapp sign — signer un package MSIX ou un exécutable avec un certificat
  • winapp tool signtool : accédez directement à SignTool à partir du Kit de développement logiciel (SDK) Windows

Rubriques de signature

Sujet Descriptif
Conditions préalables à la signature Conditions préalables requises pour signer un package d’application.
Utilisation de SignTool Comment utiliser SignTool à partir du Kit de développement logiciel (SDK) Windows pour signer un package d’application.
Signer des packages avec Azure Key Vault Comment signer des packages à l’aide d’un certificat stocké dans Azure Key Vault à partir de Visual Studio.
Signer un package MSIX avec la signature Device Guard Comment signer votre application avec la signature Device Guard.
Création de packages non signés à des fins de test Comment créer un package MSIX non signé à des fins de test.
Signature d'artéfact Azure Microsoft service de signature managée (anciennement signature approuvée) pour les packages MSIX de production.

Horodatage

Il est vivement recommandé d’utiliser l’horodatage lors de la signature de votre application avec un certificat. L’horodatage conserve la signature permettant au package d’application d’être accepté par la plateforme de déploiement d’application, même après l’expiration du certificat. Au moment de l’inspection du package, l’horodatage permet la validation de la signature du package par rapport au moment où elle a été signée. Cela permet aux packages d’être acceptés même après que le certificat n’est plus valide. Les packages qui ne sont pas horodatés sont évalués par rapport à l’heure actuelle et si le certificat n’est plus valide, Windows n’accepte pas le package.

Voici les différents scénarios liés à la signature d'application avec/sans horodatage :

Scénario L’application est signée sans horodatage L’application est signée avec horodatage
Le certificat est valide L’application installe L’application installe
Le certificat n’est pas valide(expiré) L’application échoue à l’installation L'application s'installera puisque l'authenticité du certificat a été vérifiée lors de la signature par l'autorité de l'horodatage.

Remarque

Si l’application est correctement installée sur un appareil, elle continue à s’exécuter même après l’expiration du certificat, qu’elle soit horodatée ou non.

Application de l’intégrité du package

En plus de s’assurer que seules les applications approuvées sont installées sur un appareil, un avantage supplémentaire de signer un package MSIX est qu’il permet Windows d’appliquer l’intégrité de votre package et son contenu après son déploiement sur un appareil. En chaînant les AppxBlockMap.xml et AppxSignature.p7x dans un package signé, Windows est en mesure d’effectuer des vérifications de validation sur l’intégrité d’un package et son contenu lors de l’exécution, et pendant les analyses Windows Defender. Si un package est considéré comme falsifié Windows bloque le lancement de l’application et lance un workflow de correction pour obtenir le package réparé ou réinstallé. Pour les packages non distribués via l’Microsoft Store, l’intégrité du package est appliquée si le package déclare l’élément uap10 :PackageIntegrity et est déployé sur Windows 2004 et versions ultérieures. Voici un exemple de déclaration du contrôle de l'intégrité des paquets dans le 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>

Mode de l'appareil

Windows 10 permet aux utilisateurs de sélectionner le mode dans lequel exécuter leur appareil dans l’application Paramètres. Les modes sont applications du Microsoft Store, applications en chargement direct et mode développeur.

Microsoft Store applications est la plus sécurisée, car elle autorise uniquement l’installation des applications à partir du Microsoft Store. Les applications du Microsoft Store passent par le processus de certification pour s’assurer que les applications sont sécurisées pour être utilisées.

Charger une version test des applications et Mode développeur sont plus permissifs quant aux applications signées par d’autres certificats, tant que ces certificats sont approuvés et chaînés à l’une des racines de confiance sur l’appareil. Sélectionnez uniquement le mode Développeur si vous êtes développeur et que vous créez ou déboguez des applications Windows 10. Vous trouverez plus d’informations sur le mode développeur et ce qu’il fournit ici.

Remarque

À compter de Windows 10 version 2004, l’option Chargement indépendant est activée par défaut. Par conséquent, le mode développeur est désormais un bouton bascule. Les entreprises peuvent toujours désactiver le chargement latéral via une politique.

  • Last updated on