So signieren Sie Ihre EXE-Datei mit Code (digitale Signatur)

Wenn Sie Ihre eigenständige EXE-Datei der Arbeitsmappe digital signieren, versichern Sie den Endbenutzern, dass die Datei authentisch ist und nicht manipuliert wurde. Dieser Vorgang, auch als Code Signing bezeichnet, verwendet die Technologie Microsoft Authenticode®, um zu überprüfen, dass der Code von einem vertrauenswürdigen Herausgeber stammt.

XLS Padlock vereinfacht den Code-Signing-Vorgang, indem es die erforderlichen Schritte intern abwickelt.

Um Ihre Anwendung zu signieren, benötigen Sie ein gültiges Code Signing Certificate von einer vertrauenswürdigen Zertifizierungsstelle (CA) wie Sectigo oder Digicert. Andere Zertifikatstypen wie SSL/TLS sind nicht kompatibel.

Seit dem 1. Juni 2023 müssen alle privaten Schlüssel neuer Code-Signing-Zertifikate auf sicherer Hardware gespeichert werden, beispielsweise auf einem nach FIPS 140-2 Level 2 zertifizierten USB-Token oder einem Hardware Security Module (HSM). Dies erhöht die Sicherheit, indem ein Diebstahl der Schlüssel verhindert wird. XLS Padlock arbeitet nahtlos mit token-basierten Zertifikaten zusammen. Stellen Sie lediglich sicher, dass das Token an Ihren Computer angeschlossen ist, wenn Sie Ihre Anwendung erstellen.

Navigieren Sie in der Oberfläche von XLS Padlock zur Registerkarte Security -> EXE Code Signing (Sicherheit, EXE-Code-Signierung). Um die Signierung zu aktivieren, wählen Sie die gewünschte Code Signing Method (Code-Signing-Methode):

• PFX File: Verwendet ein in einer .pfx- oder .p12-Datei gespeichertes Zertifikat. Dies ist eine ältere Methode für ältere Zertifikate. Geben Sie den Pfad in das Feld PFX File Path ein oder klicken Sie auf die daneben liegende Durchsuchen-Schaltfläche, und geben Sie anschließend das Zertifikatkennwort in Associated Password (if any) ein.
• Certificate Subject Name: Sucht das Zertifikat im Windows-Zertifikatspeicher anhand seines Subject Name (Antragstellername). Dies ist eine gängige Methode für Zertifikate auf Hardware-Token.
• Certificate Thumbprint: Sucht das Zertifikat im Windows-Zertifikatspeicher anhand seines eindeutigen Thumbprint (Fingerabdruck, ein SHA-1-Hash). Dies ist oft die zuverlässigste Methode.
• SignTool Commands: Eine erweiterte Methode, mit der Sie benutzerdefinierte Befehle für das Microsoft-Dienstprogramm SignTool.exe bereitstellen können, was maximale Flexibilität bietet. Siehe die Befehlsmarker unten.
• Azure Artifact Signing (formerly Trusted Signing): Signiert Ihre Anwendung mit dem cloudbasierten Dienst von Microsoft. Die Einrichtung wird in unserem Azure Artifact Signing Tutorial beschrieben; nutzen Sie außerdem die Option Exclude credentials weiter unten, wenn die Signierung nach az login fehlschlägt.
• JSign: Signiert Ihre Anwendung mit dem Open-Source-Tool JSign, das eine Java-Laufzeitumgebung (JRE oder JDK) im PATH erfordert. Legen Sie den Pfad zu jsign.jar in den Global Preferences fest und geben Sie dann einen JSign-Befehl pro Zeile ein, wobei Sie dieselben Befehlsmarker wie bei SignTool Commands verwenden.

Bei den Methoden SignTool Commands und JSign geben Sie einen Befehl pro Zeile ein. Vor der Ausführung jedes Befehls ersetzt XLS Padlock zwei Marker:

Setzen Sie Pfade, die Leerzeichen enthalten können, in Anführungszeichen. Um auf eine Datei neben der EXE-Datei zu verweisen, fügen Sie den Backslash selbst hinzu, zum Beispiel "{$OUTPUTFOLDER$}\my-metadata.json". XLS Padlock 2026.2 oder höher ist erforderlich, damit {$OUTPUTFOLDER$} ersetzt wird, wenn direkt ein Backslash oder ein Anführungszeichen folgt. Der in den Global Preferences festgelegte Standard-SignTool-Befehl lautet:

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

Wenn XLS Padlock mit der integrierten Methode Azure Artifact Signing signiert, versucht das Azure-Signaturtool mehrere Anmeldeinformationstypen nacheinander in einer festen Reihenfolge, bis einer davon erfolgreich ist. Auf manchen Computern schlägt ein Anmeldeinformationstyp, der vor dem Azure-CLI-Anmeldeinformationstyp versucht wird, fehl und bricht den gesamten Signiervorgang ab, obwohl az login erfolgreich war und das Zertifikatprofil gültig ist. Das Kompilierungsprotokoll zeigt dann einen Authentifizierungsfehler wie MsalCachePersistenceException: Persistence check failed.

Das optionale Feld Exclude credentials (one per line, optional), verfügbar seit XLS Padlock 2026.2, listet die zu überspringenden Anmeldeinformationstypen auf. Klicken Sie auf Exclude all except Azure CLI, um die empfohlene Konfiguration für einen mit az login authentifizierten Entwicklungscomputer einzutragen: alle Anmeldeinformationstypen außer AzureCliCredential.

Die zulässigen Namen sind die neun von Microsoft dokumentierten Anmeldeinformationstypen: ManagedIdentityCredential, WorkloadIdentityCredential, SharedTokenCacheCredential, VisualStudioCredential, VisualStudioCodeCredential, AzureCliCredential, AzurePowerShellCredential, AzureDeveloperCliCredential und InteractiveBrowserCredential. Die Namen werden beim Start der Signierung geprüft (Groß- und Kleinschreibung wird nicht beachtet, leere Zeilen und Duplikate werden ignoriert). Ein unbekannter Name bricht die Signierung mit einer Fehlermeldung ab, da das Signaturtool ihn sonst stillschweigend ignorieren würde. Lassen Sie das Feld leer, um das Standardverhalten beizubehalten: Die Signaturmetadaten sind dann identisch mit denen früherer Versionen. Der Wert wird mit Ihrem Projekt gespeichert.

XLS Padlock schreibt die Signaturmetadatendatei (sign-metadata.json) bei jeder Signierung neben die ausgegebene EXE-Datei. Bearbeiten Sie diese Datei nicht manuell: Ihre Änderungen würden beim nächsten Build überschrieben.

• Manuelle Signierung: Klicken Sie auf Sign EXE File Now, um die zuletzt erstellte EXE-Datei sofort zu signieren.
• Automatische Signierung: Aktivieren Sie Automatically sign my EXE file, damit XLS Padlock die EXE-Datei bei jeder Erstellung Ihrer Anwendung signiert.