Selbstsignierte Code-Signaturzertifikate für MSIX: Ein praktischer Leitfaden

2026-06-02

Tags: Windows · Microsoft Store · MSIX · Store-Fallen

---

Im vorherigen Artikel haben wir den vollständigen Workflow für MSIX-Tests vor der Einreichung durchgearbeitet. Ein Schritt, der immer wieder auftauchte, war der Umgang mit selbstsignierten Zertifikaten — deren Installation im Vertrauenswürdige Personen (Trusted People)-Speicher, das Paketieren mit dem richtigen Zertifikat und so weiter. Aber dieser Artikel hat eine wichtige Frage übergangen: Wie erstellt man eigentlich eines?

Dieser Leitfaden behandelt alles, was Sie über selbstsignierte Code-Signaturzertifikate für MSIX-Pakete wissen müssen: Erstellen, Exportieren, Verwenden in Visual Studio und Verwalten im Team.

Warum MSIX eine Signatur benötigt

MSIX-Pakete müssen vor der Installation digital signiert werden. Das ist keine Option — selbst für Sideloading und lokale Tests verlangt das Betriebssystem eine gültige Signatur auf jeder .msix-Datei.

Für die Store-Verteilung signiert Microsoft Ihr Paket nach der Zertifizierung mit einem eigenen Zertifikat. Für lokale Tests und Sideloading benötigen Sie jedoch ein eigenes Zertifikat. Hier kommen selbstsignierte Zertifikate ins Spiel: Sie ermöglichen das Signieren von Paketen für Entwicklung und Tests, ohne ein kommerzielles Code-Signaturzertifikat kaufen zu müssen.

Der Signaturvorgang erfüllt zwei Zwecke:

• Integrität: Stellt sicher, dass das Paket nach der Signatur nicht manipuliert wurde
• Identität: Identifiziert den Herausgeber (Sie) — der CN (Common Name) im Zertifikat muss mit dem <Publisher>-Wert in Ihrer Package.appxmanifest übereinstimmen

Verwenden von New-SelfSignedCertificate

Windows enthält das PowerShell-Cmdlet New-SelfSignedCertificate, das Zertifikate zu Testzwecken generieren kann. Öffnen Sie PowerShell als Administrator und versuchen Sie Folgendes:

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"

Aufschlüsselung der einzelnen Parameter:

Parameter	Bedeutung
-Type Custom	Erstellt ein benutzerdefiniertes Zertifikat statt eines einfachen
-Subject "CN=YourCompany"	Legt den Common Name fest — dieser sollte mit dem Publisher Ihrer App in der Package.appxmanifest übereinstimmen
-KeyUsage DigitalSignature	Markiert das Zertifikat für die Verwendung mit digitalen Signaturen
-TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")	Erweiterte Schlüsselverwendung (EKU) auf Code Signing (1.3.6.1.5.5.7.3.3) gesetzt, plus Basiseinschränkungen auf End Entity (2.5.29.19) — erforderlich von der Windows-Bereitstellungs-Engine für App-Pakete
-CertStoreLocation "Cert:\CurrentUser\My"	Speichert das Zertifikat im persönlichen Speicher des aktuellen Benutzers

Ohne beide TextExtension-Werte wird das Zertifikat möglicherweise nicht vollständig erkannt — die OID für Basiseinschränkungen kennzeichnet es als End Entity (keine CA), was die Windows-Bereitstellungs-Engine bei der Überprüfung von MSIX-Paketen prüft. Fehlt sie, kann dies auf bestimmten Windows-Builds zu Bereitstellungsfehlern oder WACK-Warnungen führen.

Hinweis: In meinen eigenen Projekten habe ich selbstsignierte Zertifikate ohne die Basiseinschränkungen verwendet und sie haben einwandfrei funktioniert. Die Einschränkung ist eine empfohlene Best Practice von Microsoft, aber für Entwicklungs- und Sideloading-Szenarien nicht streng erforderlich.

Erstellen des Zertifikats mit Code Signing EKU

Wenn Sie bereits ein Zertifikat ohne die Code Signing EKU erstellt haben, können Sie trotzdem überprüfen, ob es die richtigen Eigenschaften hat. Öffnen Sie das Zertifikat (über certlm.msc) und prüfen Sie Details → Erweiterte Schlüsselverwendung — dort sollte Code Signing aufgeführt sein.

Hier ist ein praktisches Skript, das ein Zertifikat erstellt und für die MSIX-Verwendung vorbereitet:

# Ein selbstsigniertes Code-Signaturzertifikat erstellen (Code Signing EKU + Basiseinschränkungen)
$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"

# Zertifikatsdetails anzeigen
$cert | Format-List Subject, Thumbprint, NotAfter

# Fingerabdruck zur einfachen Referenz ausgeben
Write-Host "Certificate thumbprint: $($cert.Thumbprint)"

Ersetzen Sie "CN=YourCompany" durch Ihren tatsächlichen Herausgebernamen. Sie finden den Herausgebernamen in Ihrer Package.appxmanifest unter dem Element Identity:

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

Exportieren von PFX vs. CER

Nach der Erstellung des Zertifikats benötigen Sie in der Regel zwei Arten von Dateien:

PFX (Personal Information Exchange)

Enthält den privaten Schlüssel + das Zertifikat. Dies wird von Visual Studio zum Signieren von Paketen verwendet. Behandeln Sie es wie ein Passwort — jeder mit Zugriff auf die PFX-Datei kann Pakete in Ihrem Namen signieren.

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

CER (Zertifikatsdatei)

Enthält nur das öffentliche Zertifikat (keinen privaten Schlüssel). Dies wird an Testrechner verteilt, damit diese Ihre signierten Pakete als vertrauenswürdig einstufen können.

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

Kurzreferenz

Format	Enthält privaten Schlüssel?	Verwendung
.pfx	Ja	Signieren von Paketen (Visual Studio, signtool)
.cer	Nein	Installation auf Testrechnern zur Herstellung von Vertrauen

Importieren des Zertifikats und Prüfen des Fingerabdrucks

Um MSIX-Pakete, die mit Ihrem selbstsignierten Zertifikat signiert wurden, auf einem Testrechner zu installieren, muss das Zertifikat vom System als vertrauenswürdig eingestuft werden.

Zertifikat installieren

1. Doppelklicken Sie auf die .cer-Datei → Install Certificate
2. Wählen Sie Local Machine → Browse → wählen Sie Vertrauenswürdige Personen (Trusted People)
3. Schließen Sie den Assistenten ab

Alternativ über PowerShell:

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

Fingerabdruck finden

Sie benötigen den Fingerabdruck (Thumbprint) bei der Verwendung von Befehlszeilen-Signiertools:

# Alle Code-Signaturzertifikate im persönlichen Speicher auflisten
Get-ChildItem -Path "Cert:\CurrentUser\My" -CodeSigningCert | Format-Table Subject, Thumbprint, NotAfter

Der Thumbprint ist eine 40-stellige hexadezimale Zeichenfolge. Kopieren Sie ihn genau — Sie werden ihn für Signaturbefehle benötigen.

Verwenden des Zertifikats in Visual Studio

Sobald Sie eine PFX-Datei haben, können Sie sie im Paketierungs-Assistenten von Visual Studio verwenden:

1. Rechtsklick auf Ihr Projekt → Package and Publish → ein neues Paketierungsprofil erstellen
2. Im Schritt Select Signing Certificate auf Select from File... klicken
3. Zu Ihrer .pfx-Datei navigieren und das Passwort eingeben
4. Den Paketierungs-Assistenten abschließen

Das Zertifikat wird im Paketierungsprofil gespeichert, sodass Sie es nicht jedes Mal neu auswählen müssen. Wenn das Zertifikat jedoch abläuft oder Sie zu einem neuen wechseln, müssen Sie das Profil aktualisieren.

Zertifikat aus dem Zertifikatspeicher verwenden

Wenn Sie die PFX in Ihren persönlichen Zertifikatspeicher importiert haben, können Sie sie auch direkt auswählen:

1. Im Signierschritt das Dropdown-Menü erweitern (statt auf "Select from File..." zu klicken)
2. Ihr Zertifikat in der Liste suchen (erkennbar am angegebenen CN)
3. Auswählen und fortfahren

Diese Vorgehensweise ist praktisch, aber Vorsicht: Visual Studio kann einen bestimmten Thumbprint zwischenspeichern. Wenn das Zertifikat erneuert wird (neues Schlüsselpaar), kann die gespeicherte Referenz ungültig werden.

Zertifikatsablauf, Erneuerung und erneutes Signieren

Selbstsignierte Zertifikate, die mit New-SelfSignedCertificate erstellt wurden, haben standardmäßig eine Gültigkeit von 1 Jahr (einige Versionen standardmäßig 3 Jahre — prüfen Sie die NotAfter-Eigenschaft).

Checkliste

• [ ] Ablaufdatum Ihres Zertifikats notieren
• [ ] Vor Ablauf ein neues Zertifikat erstellen und alle Pakete neu signieren
• [ ] Das neue .cer an Testrechner verteilen
• [ ] Das Paketierungsprofil in Visual Studio aktualisieren
• [ ] Für Store-Einreichungen ein neues Testpaket mit dem neuen Zertifikat erstellen

So überprüfen Sie den Ablauf:

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

Wenn Sie erneuern, erstellen Sie ein neues Zertifikat mit demselben CN, exportieren Sie die neue PFX/CER und signieren Sie Ihre Pakete neu. Der Thumbprint ändert sich, stellen Sie daher sicher, dass alle Referenzen aktualisiert werden.

Tipps für die Teamentwicklung

Wenn mehrere Entwickler Pakete mit demselben Zertifikat signieren müssen:

• Die PFX an einem sicheren, gemeinsamen Ort aufbewahren — ein passwortgeschütztes Archiv im Team-Speicher oder ein Passwort-Manager, der Dateianhänge unterstützt
• Die PFX niemals in die Versionskontrolle einchecken — *.pfx zur .gitignore hinzufügen
• Das Passwort dokumentieren — im Passwort-Manager des Teams, nicht im Code oder in Dokumenten
• Jeder Entwickler importiert die PFX in seinen persönlichen Zertifikatspeicher und wählt sie dann in Visual Studio aus
• Denselben CN verwenden für alle Zertifikate, falls Sie pro Entwickler Zertifikate erstellen müssen (für Nicht-Auslieferungs-Builds)

Für CI/CD-Pipelines unterstützen die meisten Build-Agents den Import einer PFX über sichere Umgebungsvariablen oder Secrets — prüfen Sie die Dokumentation Ihrer CI-Plattform für die empfohlene Vorgehensweise.

---

Dieser Artikel ist ergänzende Lektüre zur Store-Fallen-Serie.