Certificats de signature de code auto-signés pour MSIX : Un guide pratique

2026-06-02

Tags: Windows · Microsoft Store · MSIX · Pièges du Store

---

Dans l'article précédent, nous avons parcouru le flux de test MSIX complet avant soumission. Une étape revenait régulièrement : la gestion des certificats auto-signés — les installer dans le magasin Personnes de confiance (Trusted People), empaqueter avec le bon certificat, etc. Mais cet article a survolé une question importante : comment en créer un, concrètement ?

Ce guide couvre tout ce que vous devez savoir sur les certificats de signature de code auto-signés pour l'empaquetage MSIX : les créer, les exporter, les utiliser dans Visual Studio et les gérer au sein de votre équipe.

Pourquoi MSIX a besoin d'une signature

Les packages MSIX doivent être signés numériquement avant de pouvoir être installés. Ce n'est pas optionnel — même pour le chargement indépendant et les tests locaux, le système d'exploitation exige une signature valide sur chaque fichier .msix.

Pour la distribution via le Store, Microsoft signe votre package avec son propre certificat après la certification. Mais pour les tests locaux et le chargement indépendant, vous avez besoin d'un certificat qui vous est propre. C'est là que les certificats auto-signés entrent en jeu : ils vous permettent de signer des packages pour le développement et les tests sans acheter de certificat de signature de code commercial.

Le processus de signature répond à deux objectifs :

• Intégrité : garantit que le package n'a pas été modifié après la signature
• Identité : identifie l'éditeur (vous) — le CN (Common Name) du certificat doit correspondre à la valeur <Publisher> de votre Package.appxmanifest

Utilisation de New-SelfSignedCertificate

Windows inclut l'applet de commande PowerShell New-SelfSignedCertificate, qui peut générer des certificats à des fins de test. Ouvrez PowerShell en tant qu'Administrateur et essayez ceci :

New-SelfSignedCertificate -Type Custom -Subject "CN=YourCompany" -KeyUsage DigitalSignature -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}") -CertStoreLocation "Cert:\CurrentUser\My"

Détaillons chaque paramètre :

Paramètre	Rôle
-Type Custom	Crée un certificat personnalisé plutôt qu'un certificat de base
-Subject "CN=YourCompany"	Définit le Common Name — doit correspondre au Publisher de votre application dans Package.appxmanifest
-KeyUsage DigitalSignature	Marque le certificat pour une utilisation en signature numérique
-TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")	Enhanced Key Usage défini sur Code Signing (1.3.6.1.5.5.7.3.3), plus Basic Constraints défini sur End Entity (2.5.29.19) — requis par le moteur de déploiement Windows pour les packages d'application
-CertStoreLocation "Cert:\CurrentUser\My"	Stocke le certificat dans le magasin Personnel de l'utilisateur actuel

Sans les deux valeurs TextExtension, le certificat peut ne pas être entièrement reconnu — l'OID Basic Constraints le marque comme une Entité Finale (pas une CA), ce que le moteur de déploiement Windows vérifie lors du traitement des packages MSIX. Son absence peut provoquer des erreurs de déploiement ou des avertissements WACK sur certaines versions de Windows.

Note : Dans mes propres projets, j'ai utilisé des certificats auto-signés sans l'extension Basic Constraints et ils ont fonctionné sans problème. Cette contrainte est une bonne pratique recommandée par Microsoft, mais pas strictement requise pour le développement et le sideloading.

Création du certificat avec l'EKU Code Signing

Si vous avez déjà créé un certificat sans l'EKU Code Signing, vous pouvez toujours vérifier s'il possède les bonnes propriétés. Ouvrez le certificat (via certlm.msc) et vérifiez Détails → Enhanced Key Usage — vous devriez voir Code Signing listé.

Voici un script pratique qui crée un certificat et le prépare pour une utilisation avec MSIX :

# Crée un certificat de signature de code auto-signé (EKU Code Signing + Basic Constraints)
$cert = New-SelfSignedCertificate -Type Custom -Subject "CN=YourCompany" -KeyUsage DigitalSignature -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}") -CertStoreLocation "Cert:\CurrentUser\My"

# Affiche les détails du certificat
$cert | Format-List Subject, Thumbprint, NotAfter

# Affiche l'empreinte pour référence facile
Write-Host "Empreinte du certificat : $($cert.Thumbprint)"

Remplacez "CN=YourCompany" par le nom réel de votre éditeur. Vous trouverez le nom de votre éditeur dans Package.appxmanifest sous l'élément Identity :

<Identity Name="YourApp" Publisher="CN=YourCompany" Version="1.0.0.0" />

Exportation PFX vs CER

Après avoir créé le certificat, vous aurez généralement besoin de deux types de fichiers :

PFX (Personal Information Exchange)

Contient la clé privée + le certificat. C'est ce que Visual Studio utilise pour signer les packages. Traitez-le comme un mot de passe — toute personne ayant accès au PFX peut signer des packages en votre nom.

$password = ConvertTo-SecureString -String "YourPassword" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "codesign.pfx" -Password $password

CER (Certificate file)

Contient uniquement le certificat public (pas de clé privée). C'est ce que vous distribuez aux machines de test pour qu'elles puissent approuver vos packages signés.

Export-Certificate -Cert $cert -FilePath "codesign.cer"

Référence rapide

Format	Contient la clé privée ?	Utilisation
.pfx	Oui	Signature des packages (Visual Studio, signtool)
.cer	Non	Installation sur les machines de test pour établir la confiance

Importation du certificat et vérification de l'empreinte

Pour installer des packages MSIX signés avec votre certificat auto-signé sur une machine de test, le certificat doit être approuvé par le système.

Installer le certificat

1. Double-cliquez sur le fichier .cer → Install Certificate
2. Sélectionnez Local Machine → Browse → sélectionnez Personnes de confiance (Trusted People)
3. Terminez l'assistant

Alternative, via PowerShell :

Import-Certificate -FilePath "codesign.cer" -CertStoreLocation "Cert:\LocalMachine\TrustedPeople"

Trouver l'empreinte

Vous aurez besoin de l'empreinte (thumbprint) lorsque vous utiliserez des outils de signature en ligne de commande :

# Liste tous les certificats de signature de code dans le magasin Personnel
Get-ChildItem -Path "Cert:\CurrentUser\My" -CodeSigningCert | Format-Table Subject, Thumbprint, NotAfter

L'empreinte est une chaîne hexadécimale de 40 caractères. Copiez-la exactement — vous en aurez besoin pour les commandes de signature.

Utilisation du certificat dans Visual Studio

Une fois que vous avez un fichier PFX, vous pouvez l'utiliser dans l'assistant d'empaquetage de Visual Studio :

1. Clic droit sur votre projet → Package and Publish → créez un nouveau profil d'empaquetage
2. À l'étape Select Signing Certificate, cliquez sur Select from File...
3. Naviguez jusqu'à votre fichier .pfx et entrez le mot de passe
4. Terminez l'assistant d'empaquetage

Le certificat est sauvegardé dans le profil d'empaquetage, vous n'avez donc pas besoin de le re-sélectionner à chaque fois. Cependant, si le certificat expire ou si vous changez de certificat, vous devrez mettre à jour le profil.

Utilisation du certificat depuis le magasin de certificats

Si vous avez importé le PFX dans votre magasin de certificats personnel, vous pouvez aussi le sélectionner directement :

1. À l'étape de signature, développez la liste déroulante au lieu de cliquer sur "Select from File..."
2. Recherchez votre certificat dans la liste (identifié par le CN que vous avez spécifié)
3. Sélectionnez-le et poursuivez

Cette approche est pratique mais attention — Visual Studio peut mettre en cache une empreinte spécifique, et si le certificat est renouvelé (nouvelle paire de clés), la référence stockée peut devenir invalide.

Expiration, renouvellement et re-signature du certificat

Les certificats auto-signés créés avec New-SelfSignedCertificate ont une validité par défaut d'1 an (certaines versions par défaut donnent 3 ans — vérifiez la propriété NotAfter).

Liste de contrôle

• [ ] Notez la date d'expiration de votre certificat
• [ ] Avant l'expiration, créez un nouveau certificat et re-signez tous les packages
• [ ] Distribuez le nouveau .cer aux machines de test
• [ ] Mettez à jour le profil d'empaquetage dans Visual Studio
• [ ] Pour les soumissions au Store, générez un nouveau package Test avec le nouveau certificat

Pour vérifier l'expiration :

Get-ChildItem -Path "Cert:\CurrentUser\My" -CodeSigningCert | Format-Table Subject, NotAfter

Lors du renouvellement, créez un nouveau certificat avec le même CN, exportez le nouveau PFX/CER, et re-signez vos packages. L'empreinte changera, alors assurez-vous que toutes les références sont mises à jour.

Conseils pour le développement en équipe

Lorsque plusieurs développeurs doivent signer des packages avec le même certificat :

• Stockez le PFX dans un emplacement partagé sécurisé — une archive protégée par mot de passe dans le stockage d'équipe ou un gestionnaire de mots de passe prenant en charge les pièces jointes
• Ne commettez jamais le PFX dans le contrôle de source — ajoutez *.pfx à votre .gitignore
• Documentez le mot de passe dans le gestionnaire de mots de passe de votre équipe, pas dans le code ou la documentation
• Chaque développeur importe le PFX dans son magasin de certificats personnel, puis le sélectionne depuis Visual Studio
• Utilisez le même CN pour tous les certificats si vous avez besoin de créer des certificats par développeur (pour les builds non destinés à la publication)

Pour les pipelines CI/CD, la plupart des agents de build prennent en charge l'importation d'un PFX via des variables d'environnement sécurisées ou des secrets — consultez la documentation de votre plateforme CI pour connaître l'approche recommandée.

---

Cet article est une lecture complémentaire de la série Pièges du Store.