Comment signer un package d’application à l’aide de SignTool
Notes
Pour signer un package d’application Windows, consultez Signer un package d’application à l’aide de SignTool.
Découvrez comment utiliser SignTool pour signer vos packages d’application Windows afin qu’ils puissent être déployés. SignTool fait partie du Kit de développement logiciel (SDK) Windows.
Tous les packages d’application Windows doivent être signés numériquement avant de pouvoir être déployés. Bien que Microsoft Visual Studio 2012 et versions ultérieures puissent signer un package d’application lors de sa création, les packages que vous créez à l’aide de l’outil de packageur d’application (MakeAppx.exe) du Kit de développement logiciel (SDK) Windows ne sont pas signés.
Notes
Vous pouvez uniquement utiliser SignTool pour signer vos packages d’application Windows sur Windows 8 et versions ultérieures ou Windows Server 2012 et versions ultérieures. Vous ne pouvez pas utiliser SignTool pour signer des packages d’application sur des systèmes d’exploitation de bas niveau tels que Windows 7 ou Windows Server 2008 R2.
Bon à savoir
Technologies
- Présentation de la signature de code
- Packages d’applications et déploiement
- Outils pour signer des fichiers et vérifier les signatures
Prérequis
SignTool, qui fait partie du Kit de développement logiciel (SDK) Windows
Un certificat de signature de code valide, par exemple un fichier d’échange d’informations personnelles (.pfx) créé avec les outilsMakeCert.exe et Pvk2Pfx.exe
Pour plus d’informations sur la création d’un certificat de signature de code valide, consultez Comment créer un certificat de signature de package d’application.
Une application Windows empaquetée, par exemple, un fichier .appx créé à l’aide de l’outil de packager d’application (MakeAppx.exe)
Considérations supplémentaires
Le certificat que vous utilisez pour signer le package d’application doit répondre aux critères suivants :
Le nom de l’objet du certificat doit correspondre à l’attribut Publisher contenu dans l’élément Identity du fichier AppxManifest.xml stocké dans le package. Le nom de l’éditeur fait partie de l’identité d’une application Windows empaquetée. Vous devez donc faire correspondre le nom de l’objet du certificat au nom de l’éditeur de l’application. Cela permet de vérifier l’identité des packages signés par rapport à la signature numérique. Pour plus d’informations sur les erreurs de signature qui peuvent survenir lors de la signature d’un package d’application à l’aide de SignTool, consultez la section Remarques de la rubrique Création d’un certificat de signature de package d’application.
Le certificat doit être valide pour la signature de code. Cela signifie que ces deux éléments doivent être vrais :
- Le champ Utilisation de clé étendue (EKU) du certificat doit être non défini ou contenir la valeur EKU pour la signature de code (1.3.6.1.5.5.7.3.3).
- Le champ Utilisation de la clé (KU) du certificat doit être non défini ou contenir le bit d’utilisation de la signature numérique (0x80).
Le certificat contient une clé privée.
Le certificat est valide. Il est actif, n’a pas expiré et n’a pas été révoqué.
Instructions
Étape 1 : Déterminer l’algorithme de hachage à utiliser
Lorsque vous signez le package d’application, vous devez utiliser le même algorithme de hachage que celui utilisé lors de la création du package d’application. Si vous avez utilisé les paramètres par défaut pour créer le package d’application, l’algorithme de hachage utilisé est SHA256.
Si vous avez utilisé le packageur d’application avec un algorithme de hachage spécifique pour créer le package d’application, utilisez le même algorithme pour signer le package. Pour déterminer l’algorithme de hachage à utiliser pour signer un package, vous pouvez extraire le contenu du package et inspecter le fichier AppxBlockMap.xml. L’attribut HashMethod de l’élément BlockMap indique l’algorithme de hachage utilisé lors de la création du package d’application. Par exemple :
<BlockMap xmlns="http://schemas.microsoft.com/appx/2010/blockmap"
HashMethod="https://www.w3.org/2001/04/xmlenc#sha256">
L’élément BlockMap précédent indique que l’algorithme SHA256 a été utilisé. Ce tableau répertorie le mappage des algorithmes actuellement disponibles :
| Valeur HashMethod | hashAlgorithm à utiliser |
|---|---|
| https://www.w3.org/2001/04/xmlenc#sha256 | SHA256 (.appx par défaut) |
| https://www.w3.org/2001/04/xmldsig-more#sha384 | SHA384 |
| https://www.w3.org/2001/04/xmlenc#sha512 | SHA512 |
Étape 2 : Exécuter SignTool.exe pour signer le package
Pour signer le package avec un certificat de signature à partir d’un fichier .pfx
-
SignTool sign /fd hashAlgorithm /a /f signingCert.pfx /p password filepath.appx
SignTool définit par défaut le paramètre /fd hashAlgorithm sur SHA1 s’il n’est pas spécifié, et SHA1 n’est pas valide pour la signature de packages d’application. Vous devez donc spécifier ce paramètre lorsque vous signez un package d’application. Pour signer un package d’application créé avec le hachage SHA256 par défaut, vous spécifiez le paramètre /fd hashAlgorithm comme SHA256 :
SignTool sign /fd SHA256 /a /f signingCert.pfx /p password filepath.appx
Vous pouvez omettre le paramètre de mot de passe /p si vous utilisez un fichier .pfx qui n’est pas protégé par mot de passe. Vous pouvez également utiliser d’autres options de sélection de certificat prises en charge par SignTool pour signer des packages d’application. Pour plus d’informations sur ces options, consultez SignTool.
Notes
Vous ne pouvez pas utiliser l’opération d’horodatage SignTool sur un package d’application signé ; l’opération n’est pas prise en charge.
Si vous souhaitez horodater le package d’application, vous devez le faire pendant l’opération de signature. Par exemple :
SignTool sign /fd hashAlgorithm /a /f signingCert.pfx /p password /tr timestampServerUrl
filepath.appx
Faites en sorte que le paramètre /tr timestampServerUrl soit égal à l’URL d’un serveur d’horodatage RFC 3161.
Remarques
Cette section décrit la résolution des erreurs de signature pour les packages d’application.
Résolution des erreurs de signature de package d’application
En plus des erreurs de signature que SignTool peut retourner, SignTool peut également retourner des erreurs spécifiques à la signature des packages d’application. Ces erreurs apparaissent généralement sous la forme d’erreurs internes :
SignTool Error: An unexpected internal error has occurred.
Error information: "Error: SignerSign() failed." (-2147024885 / 0x8007000B)
Si le code d’erreur commence par 0x8008, comme 0x80080206 APPX_E_CORRUPT_CONTENT), cela indique que le package en cours de signature n’est pas valide. Dans ce cas, avant de pouvoir signer le package, vous devez reconstruire le package. Pour obtenir la liste complète des erreurs 0x8008*, consultez Codes d’erreur COM (sécurité et configuration).
Plus souvent, l’erreur est 0x8007000b (ERROR_BAD_FORMAT). Dans ce cas, vous trouverez des informations d’erreur plus spécifiques dans le journal des événements :
Pour effectuer une recherche dans le journal des événements
- Exécutez Eventvwr.msc.
- Ouvrez le journal des événements : observateur d'événements journaux > des applications et des services Microsoft >> Windows > AppxPackagingOM > Microsoft-Windows-AppxPackaging/Opérationnel
- Recherchez l’événement d’erreur le plus récent.
L’erreur interne correspond généralement à l’un des éléments suivants :
| ID de l’événement | Exemple de chaîne d’événement | Suggestion |
|---|---|---|
| 150 | erreur 0x8007000B : le nom de l’éditeur du manifeste de l’application (CN=Contoso) doit correspondre au nom de l’objet du certificat de signature (CN=Contoso, C=US). | Le nom de l’éditeur du manifeste d’application doit correspondre exactement au nom de l’objet de la signature. Note: Ces noms sont spécifiés entre guillemets et respectent la casse et les espaces blancs. Vous pouvez mettre à jour la chaîne d’attribut Publisher définie pour l’élément Identity dans le fichier AppxManifest.xml afin qu’elle corresponde au nom d’objet du certificat de signature prévu. Vous pouvez également sélectionner un autre certificat de signature avec un nom d’objet qui correspond au nom de l’éditeur de manifeste de l’application. Le nom de l’éditeur de manifeste et le nom de l’objet du certificat sont tous deux répertoriés dans le message d’événement. |
| 151 | erreur 0x8007000B : la méthode de hachage de signature spécifiée (SHA512) doit correspondre à la méthode de hachage utilisée dans la carte de bloc du package d’application (SHA256). | Le hashAlgorithm spécifié dans le paramètre /fd est incorrect (voir Étape 1 : Déterminer l’algorithme de hachage à utiliser). Réexécutez SignTool avec le hashAlgorithm qui correspond à la carte de bloc du package d’application. |
| 152 | erreur 0x8007000B : le contenu du package d’application doit être validé par rapport à son mappage de blocs. | Le package d’application est endommagé et doit être reconstruit pour générer une nouvelle carte de blocs. Pour plus d’informations sur la création d’un package d’application, consultez Création d’un package d’application avec le packageur d’application ou Création d’un package d’application avec Visual Studio 2012. |
Considérations relatives à la sécurité
Une fois le package signé, le certificat que vous avez utilisé pour signer le package doit toujours être approuvé par l’ordinateur sur lequel le package doit être déployé. En ajoutant un certificat aux magasins de certificats d’ordinateur local, vous affectez l’approbation de certificat de tous les utilisateurs sur l’ordinateur. Nous vous recommandons d’installer les certificats de signature de code souhaités pour tester les packages d’application dans le magasin de certificats de Personnes approuvé et de supprimer rapidement ces certificats lorsque cela n’est plus nécessaire. Si vous créez vos propres certificats de test pour la signature de packages d’application, nous vous recommandons également de restreindre les privilèges associés au certificat de test. Pour plus d’informations sur la création de certificats de test pour la signature de packages d’application, consultez Comment créer un certificat de signature de package d’application.
Rubriques connexes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour