Conseils de sécurité

La CLI winapp simplifie le développement Windows local : elle peut générer un certificat de signature, l’ajouter comme certificat approuvé sur votre ordinateur et activer le mode développeur pour vous. Chacune de ces étapes modifie l’état de la machine ou crée un fichier qui contient une clé privée, il est donc utile de savoir exactement ce qu’elles font.

Cette page explique la conséquence de chaque instruction, comment l’annuler et ce qu’il faut faire différemment lorsque vous expédiez. Les certificats de développement et le mode développeur constituent la voie normale et prise en charge pour les tests locaux — l’objectif ici est que vous compreniez ce à quoi vous choisissez d’adhérer, et non pas que vous les évitiez.

Certificats de développement

Les packages MSIX doivent être signés avant que Windows les installe. Pour les tests locaux, winapp cert generate crée un certificat auto-signé pour vous permettre de signer et d’installer votre propre package sans acheter quoi que ce soit.

Ce qui winapp cert generate crée

Le certificat généré est un certificat auto-signé de signature de code terminal :

Propriété Valeur
Clé RSA 2048 bits, marqué comme exportable
Algorithme de signature SHA-256 avec RSA (PKCS#1 v1.5)
Usage de la clé Signature numérique
Utilisation améliorée de la clé Signature du code (1.3.6.1.5.5.7.3.3)
Contraintes de base Pas une autorité de certification
Validité 365 jours par défaut (--valid-days)
Subject Doit correspondre au Publisher dans votre manifeste

La commande écrit deux éléments :

  • devcert.pfx dans le répertoire actif (ou le chemin que vous passez à --output). Ce fichier contient à la fois le certificat et sa clé privée.
  • Copie du certificat dans votre magasin de certificats personnel (Cert:\CurrentUser\My).

Avec --export-cer, il écrit également un fichier .cer en regard du .pfx. Ce fichier contient uniquement le certificat public, aucune clé privée, ce qui en fait l’élément approprié à transmettre à un collègue ou à une machine de test qui doit faire confiance à vos builds.

Note

Un certificat auto-signé n’est considéré comme fiable par personne jusqu’à ce qu’une personne le considère explicitement comme fiable. Il est correct pour votre propre machine et vos propres machines de test ; ce n’est pas un substitut à une véritable identité de signature de code lorsque vous distribuez votre application.

Mot de passe par défaut

winapp cert generate utilise password comme mot de passe PFX, à moins de fournir --password. La même valeur par défaut s’applique lorsque vous fournissez ultérieurement ce certificat à winapp sign, dont l’option de mot de passe est également --password, et à winapp pack, qui prend --cert-password.

Un mot de passe bien connu signifie que la clé privée dans devcert.pfx est effectivement non protégée — toute personne qui obtient le fichier peut signer du code avec celui-ci. Il s’agit d’un compromis acceptable pour un certificat jetable qui signe uniquement des builds de test locaux sur votre propre ordinateur, et c’est pourquoi la valeur par défaut existe.

Important

Traitez le mot de passe par défaut comme un signal indiquant que le certificat est jetable. Si un certificat est utilisé un jour pour signer quelque chose qu’une autre personne installera, il ne doit pas s’agir d’un certificat winapp cert generate avec le mot de passe par défaut — voir Signature pour la production.

Les scripts et les agents n’ont pas à comparer eux-mêmes le mot de passe : winapp cert generate --json signale "defaultPasswordIsPublic": true et répète la divulgation dans un tableau warnings lorsqu’il génère un certificat avec le mot de passe par défaut. Une exécution qui conserve un fichier existant avec --if-exists skip ne l’ouvre pas, donc il n’en signale aucun des deux. Consultez cert generate JSON output.

Où se trouve le fichier de certificat

devcert.pfx est une clé privée sur le disque. Deux règles lui évitent des ennuis :

Ne le committez pas.winapp cert generate ajoute automatiquement le nom de fichier du certificat à côté de .gitignore, de sorte que le flux par défaut est déjà couvert. Si vous déplacez le fichier, renommez-le ou générez-le dans un répertoire géré par un autre .gitignore, vérifiez que l’entrée a été déplacée avec lui :

git check-ignore -v devcert.pfx

Si cela n’imprime rien, le fichier n’est pas ignoré , ajoutez-le avant de valider.

Ne l’empaquetez pas.winapp pack empaquette tout dans le répertoire d’entrée, donc un devcert.pfx se trouvant dans le dossier de sortie de votre application se retrouve dans le MSIX livré. Générez le certificat en dehors du dossier que vous empaquetez, comme le guide sur l’empaquetage d’un EXE/CLI le montre, et vérifiez qu’il est absent avant de distribuer :

# Unpack the package and check that no certificate is inside
winapp tool makeappx unpack /p .\MyApp.msix /d .\inspect /o
Get-ChildItem .\inspect -Recurse -Include *.pfx, *.cer

Tip

Si une .pfx clé privée réelle est commitée ou publiée, effectuez-en la rotation : générez un nouveau certificat, signez de nouveau et arrêtez de faire confiance à l’ancien en suivant les étapes de suppression d’un certificat approuvé. La suppression du fichier d’une validation ultérieure ne le supprime pas de l’historique.

Ce que winapp cert install accorde

winapp cert install ajoute le certificat au magasin de certificats LocalMachine\TrustedPeople. Cela nécessite des privilèges d’administrateur, car cela modifie le niveau de confiance pour tous les utilisateurs de l’ordinateur.

Une fois qu’un certificat est en placeTrustedPeople, Windows acceptera tout package MSIX signé par ce certificat comme suffisamment approuvé pour l’installation, et non pas seulement le package que vous testiez. Pour un certificat dont vous détenez la clé privée et la conservez localement, c’est exactement l’effet prévu. C’est aussi la raison pour laquelle il faut être délibéré à ce sujet :

  • Approuvez les certificats que vous avez générés vous-même, ou qui proviennent de quelqu’un que vous laisseriez installer des logiciels sur l’ordinateur.
  • N’installez pas de certificat de développement sur des machines partagées, de production ou de build sur lesquelles d’autres personnes s’appuient.
  • Préférez distribuer la .cer (clé publique uniquement) plutôt que le .pfx lorsqu’un collègue doit installer votre package de test. Ils obtiennent la possibilité de faire confiance à vos builds sans pouvoir signer en votre nom.

Pour faire confiance à une autre machine de test .cer, exécutez directement winapp cert install sur celle-ci : la commande accepte soit un .pfx, soit un .cer public uniquement :

# Run as Administrator
winapp cert install .\devcert.cer

L’équivalent utilisant uniquement les outils intégrés Windows est le suivant :

# Run as Administrator
Import-Certificate -FilePath .\devcert.cer -CertStoreLocation Cert:\LocalMachine\TrustedPeople

Suppression d’un certificat approuvé

Les certificats de développement expirent après un an par défaut, mais l’expiration ne signifie pas la suppression. Lorsque vous avez terminé d’utiliser un certificat ( le projet s’est terminé, la machine est réaffectée, ou la clé a peut-être été divulguée), supprimez-la explicitement.

Tout d’abord, recherchez son empreinte :

Get-ChildItem Cert:\LocalMachine\TrustedPeople |
    Where-Object { $_.Subject -like '*CN=Contoso*' } |
    Format-List Subject, Thumbprint, NotAfter

Ensuite, supprimez-le du magasin de certificats approuvés de l’ordinateur. Cette étape doit être exécutée avec des privilèges élevés :

# Run as Administrator. Replace with the thumbprint from the previous command.
$thumbprint = 'ABCD...'
Remove-Item -Path "Cert:\LocalMachine\TrustedPeople\$thumbprint"

cert generate a également placé le certificat, ainsi que sa clé privée, dans votre magasin de certificats personnel. Supprimez cela d’une invite normale sans élévation de privilèges, connecté avec le compte qui a exécuté cert generate:

$thumbprint = 'ABCD...'
Remove-Item -Path "Cert:\CurrentUser\My\$thumbprint"

Important

Exécutez les deux commandes ci-dessus dans les contextes indiqués. Si vous avez effectué l’élévation avec un autre compte d’administrateur, Cert:\CurrentUser dans cette session avec élévation de privilèges correspond au magasin de cet administrateur — et non au vôtre —, de sorte que la clé privée serait laissée dans le magasin de l’utilisateur qui l’a générée.

Enfin, supprimez le .pfx et toutes les copies .cer que vous avez distribuées, et désinscrivez les applications que vous avez chargées avec celui-ci :

winapp unregister

Note

La suppression du certificat ne désinstalle pas les packages déjà installés avec celui-ci. Désinstallez-les séparément via Paramètres > Applications > Applications installées, ou avec winapp unregister pour les packages inscrits en mode développement.

Mode développeur

Windows nécessite le mode développeur pour enregistrer un package d’application directement à partir d’un dossier sur le disque, c’est-à-dire un loose layout, au lieu d’installer un MSIX créé et signé. Les commandes telles que winapp run et create-debug-identity en dépendent et échouent sans cela, et winapp init propose de l’activer pour vous.

Ce que son activation modifie

L’interface CLI active le mode développeur en écrivant deux DWORD valeurs sous HKEY_LOCAL_MACHINE:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock
    AllowDevelopmentWithoutDevLicense = 1
    AllowAllTrustedApps               = 1

Comme il s’agit de paramètres à l’échelle de l’ordinateur, l’interface CLI lance un processus d’assistance avec élévation de privilèges et Windows affiche une invite de contrôle de compte d’utilisateur. Rien n’est modifié si vous refusez l’invite.

En pratique, cela signifie que la machine va :

  • Enregistrez des packages d’application directement à partir d’un dossier sur le disque, sans qu’ils soient intégrés à un MSIX ou même signés (AllowDevelopmentWithoutDevLicense).
  • Installez des packages d’application à partir de l’extérieur du Microsoft Store tant qu’ils sont signés par un certificat auquel l’ordinateur fait confiance, y compris tout certificat de développement dans TrustedPeople (AllowAllTrustedApps).

Important

Le mode développeur plus un certificat de développement approuvé est un relâchement délibéré des restrictions d’installation par défaut. Cette combinaison est destinée aux machines de développement et de test. Laissez-le désactivé sur les machines de production, les kiosques et l’infrastructure partagée.

Contrôler quand il est activé

winapp init demande avant de changer quoi que ce soit, et --use-defaults ignore entièrement la question, laissant le mode développeur intouché. Cela rend les exécutions scriptées et de CI sûres par défaut :

winapp init --use-defaults

Si vous préférez gérer le paramètre vous-même, activez-le une fois via Paramètres > Système > Pour les développeurs > Mode développeur et la CLI le détectera et poursuivra.

Désactiver

Utilisez Paramètres > Système > Pour les développeurs et désactivez le mode développeur. Il s’agit du chemin d’accès recommandé, car Paramètres nettoie également l’état du système d’exploitation associé. Pour confirmer la valeur du Registre ensuite :

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock' `
    -Name AllowDevelopmentWithoutDevLicense, AllowAllTrustedApps

La désactivation du mode développeur ne supprime pas les certificats approuvés ou les packages déjà installés. Voir Suppression d’un certificat approuvé.

Signature de production

Un certificat de développement fonctionne uniquement pour les personnes qui lui font explicitement confiance. Pour distribuer votre application, signez-la avec une identité que Windows approuve déjà.

Choisir une identité de signature

  • Signatures de confiance Azure : un service de signature géré par le cloud. La clé privée n’existe jamais sur votre machine de build. Il n’y a donc aucune .pfx à protéger, divulguer ou faire tourner manuellement. Utilisez winapp az-sign, qui s’authentifie avec la chaîne d’informations d’identification standard Azure et fonctionne avec GitHub Actions OIDC ou une identité managée.

    winapp az-sign .\MyApp.msix

  • Certificat de signature de code d’une autorité de certification approuvée : passez-le en winapp sign tant que deuxième argument positionnel, avec son mot de passe dans --password. Vous êtes alors responsable du stockage des éléments de clé en toute sécurité ; conservez-les dans un jeton matériel, un coffre de clés ou le magasin de secrets de votre fournisseur CI, et jamais dans le référentiel.

  • Le Microsoft Store — si vous distribuez exclusivement via le Microsoft Store, il signe le package pour vous et vous n’avez pas besoin de signer avant la soumission.

Dans tous les cas, l’objet du certificat doit correspondre à la Publisher valeur de votre manifeste, y compris pour les packages épars.

N'incluez pas les secrets de signature dans le dépôt

Les mots de passe de certificat appartiennent à votre magasin de secrets CI, et non dans un fichier de configuration. Lisez-les à partir de l’environnement au lieu de les coder en dur :

winapp sign .\MyApp.msix $env:SIGNING_CERT_PATH --password $env:SIGNING_CERT_PASSWORD

La même chose s’applique à la configuration de build enregistrée dans le gestionnaire de versions, telle qu’une configuration Electron Forge. Consultez l’empaquetage Electron. winapp az-sign évite entièrement le problème, car il n’y a pas de mot de passe à transmettre.

Avant de publier

Une liste de contrôle courte pour la transition du test local à la distribution :

  • Le package est signé avec un certificat émis par une autorité de certification, via Signatures de confiance Azure, ou soumis au Store — et non avec devcert.pfx.
  • Aucun fichier .pfx ou .cer ne se trouve à l’intérieur de la sortie empaquetée.
  • Aucun mot de passe de certificat n’apparaît dans les fichiers validés, les scripts de génération ou les journaux CI.
  • Le sujet du certificat correspond au manifeste Publisher.
  • Les certificats de développement et le mode développeur ne sont pas activés sur les machines qui doivent uniquement exécuter l’application.

Signaler un problème de sécurité

Pour signaler une vulnérabilité de sécurité dans la CLI winapp elle-même, suivez le processus dans SECURITY.md. Veuillez ne pas ouvrir une issue publique sur GitHub pour les rapports de sécurité.

  • Dernière mise à jour :