Comment signer numériquement votre fichier EXE (signature numérique)

Lorsque vous signez numériquement votre fichier EXE de classeur autonome, vous assurez aux utilisateurs finaux que le fichier est authentique et n’a pas été altéré. Ce processus, également appelé signature de code, utilise la technologie Microsoft Authenticode® pour vérifier que le code provient d’un éditeur de confiance.

XLS Padlock simplifie le processus de signature de code en prenant en charge les étapes nécessaires en interne.

Pour signer votre application, vous avez besoin d’un Code Signing Certificate valide délivré par une autorité de certification (CA) de confiance comme Sectigo ou Digicert. Les autres types de certificats, comme SSL/TLS, ne sont pas compatibles.

Depuis le 1er juin 2023, toutes les nouvelles clés privées de certificat de signature de code doivent être stockées sur du matériel sécurisé, comme un jeton USB conforme à la norme FIPS 140-2 niveau 2 ou un module de sécurité matériel (HSM). Cela renforce la sécurité en empêchant le vol de clés. XLS Padlock fonctionne parfaitement avec les certificats basés sur un jeton ; assurez-vous simplement que le jeton est branché sur votre ordinateur lorsque vous générez votre application.

Dans l’interface de XLS Padlock, accédez à l’onglet Security -> EXE Code Signing. Pour activer la signature, choisissez votre Code Signing Method préférée :

• PFX File : utilise un certificat stocké dans un fichier .pfx (ou .p12). Il s’agit d’une méthode héritée pour les anciens certificats. Saisissez le chemin dans le champ PFX File Path ou cliquez sur le bouton de parcours à côté, puis saisissez le mot de passe du certificat dans Associated Password (if any).
• Certificate Subject Name : localise le certificat dans le magasin de certificats Windows par son nom de sujet (Subject Name). C’est une méthode courante pour les certificats sur jetons matériels.
• Certificate Thumbprint : localise le certificat dans le magasin de certificats Windows par son empreinte unique (Thumbprint, un hachage SHA-1). C’est souvent la méthode la plus fiable.
• SignTool Commands : une méthode avancée qui vous permet de fournir des commandes personnalisées pour l’utilitaire SignTool.exe de Microsoft, offrant un maximum de flexibilité. Voir les marqueurs de commande ci-dessous.
• Azure Artifact Signing (formerly Trusted Signing) : signe votre application avec le service basé sur le cloud de Microsoft. Consultez notre tutoriel Azure Artifact Signing pour la configuration initiale, ainsi que l’option Exclude credentials ci-dessous si la signature échoue après az login.
• JSign : signe votre application avec l’outil open source JSign, qui nécessite un environnement d’exécution Java (JRE ou JDK) dans le PATH. Définissez le chemin vers jsign.jar dans les Global Preferences, puis saisissez une commande JSign par ligne, en utilisant les mêmes marqueurs de commande que SignTool Commands.

Avec les méthodes SignTool Commands et JSign, vous saisissez une commande par ligne. Avant d’exécuter chaque commande, XLS Padlock remplace deux marqueurs :

Mettez entre guillemets les chemins susceptibles de contenir des espaces. Pour référencer un fichier situé à côté du fichier EXE, ajoutez vous-même la barre oblique inverse, par exemple "{$OUTPUTFOLDER$}\my-metadata.json". XLS Padlock 2026.2 ou version ultérieure est requis pour que {$OUTPUTFOLDER$} soit remplacé lorsqu’il est directement suivi d’une barre oblique inverse ou d’un guillemet. La commande SignTool par défaut, définie dans les Global Preferences, est :

sign /tr http://timestamp.sectigo.com /td sha256 /fd sha256 /a /v "{$OUTPUTFILE$}"

Lorsque XLS Padlock signe avec la méthode intégrée Azure Artifact Signing, l’outil de signature Azure essaie plusieurs types d’informations d’identification les uns après les autres, dans un ordre fixe, jusqu’à ce que l’un d’eux réussisse. Sur certains ordinateurs, un type d’informations d’identification testé avant celui d’Azure CLI échoue et interrompt toute l’opération de signature, alors même que az login a réussi et que le profil de certificat est valide. Le journal de compilation affiche alors une erreur d’authentification telle que MsalCachePersistenceException: Persistence check failed.

Le champ facultatif Exclude credentials (one per line, optional), disponible depuis XLS Padlock 2026.2, répertorie les types d’informations d’identification à ignorer. Cliquez sur Exclude all except Azure CLI pour renseigner la configuration recommandée pour un ordinateur de développement authentifié avec az login : tous les types d’informations d’identification sauf AzureCliCredential.

Les noms acceptés sont les neuf types d’informations d’identification documentés par Microsoft : ManagedIdentityCredential, WorkloadIdentityCredential, SharedTokenCacheCredential, VisualStudioCredential, VisualStudioCodeCredential, AzureCliCredential, AzurePowerShellCredential, AzureDeveloperCliCredential et InteractiveBrowserCredential. Les noms sont vérifiés au démarrage de la signature (insensible à la casse, les lignes vides et les doublons sont ignorés). Un nom inconnu arrête la signature avec une erreur, car l’outil de signature l’ignorerait sinon silencieusement. Laissez le champ vide pour conserver le comportement par défaut : les métadonnées de signature sont alors identiques à celles des versions précédentes. La valeur est enregistrée avec votre projet.

XLS Padlock écrit le fichier de métadonnées de signature (sign-metadata.json) à côté du fichier EXE de sortie à chaque signature. Ne modifiez pas ce fichier manuellement : vos modifications seraient écrasées lors de la prochaine génération.

• Signature manuelle : cliquez sur Sign EXE File Now pour signer immédiatement le dernier fichier EXE généré.
• Signature automatique : cochez Automatically sign my EXE file pour que XLS Padlock signe l’EXE à chaque fois que vous générez votre application.