Come firmare digitalmente il file EXE (firma digitale)

Quando si firma digitalmente il file EXE della cartella di lavoro autonoma, si garantisce agli utenti finali che il file è autentico e non è stato manomesso. Questo processo, noto anche come firma del codice, utilizza la tecnologia Microsoft Authenticode® per verificare che il codice provenga da un editore attendibile.

XLS Padlock semplifica il processo di firma del codice gestendo internamente i passaggi necessari.

Per firmare l’applicazione, è necessario un Code Signing Certificate valido rilasciato da un’autorità di certificazione (CA) attendibile come Sectigo o Digicert. Altri tipi di certificato, come SSL/TLS, non sono compatibili.

Dal 1° giugno 2023, tutte le nuove chiavi private dei certificati di firma del codice devono essere archiviate su hardware sicuro, come un token USB conforme allo standard FIPS 140-2 Livello 2 o un modulo di sicurezza hardware (HSM). Questo rafforza la sicurezza impedendo il furto delle chiavi. XLS Padlock funziona perfettamente con i certificati basati su token; assicurarsi semplicemente che il token sia collegato al computer quando si genera l’applicazione.

Nell’interfaccia di XLS Padlock, accedere alla scheda Security -> EXE Code Signing. Per abilitare la firma, scegliere il Code Signing Method preferito:

• PFX File: utilizza un certificato archiviato in un file .pfx (o .p12). È un metodo legacy per i certificati più vecchi. Inserire il percorso nel campo PFX File Path oppure fare clic sul pulsante di sfoglia accanto ad esso, quindi inserire la password del certificato in Associated Password (if any).
• Certificate Subject Name: individua il certificato nell’archivio certificati di Windows tramite il suo Subject Name (nome del soggetto). È un metodo comune per i certificati su token hardware.
• Certificate Thumbprint: individua il certificato nell’archivio certificati di Windows tramite il suo Thumbprint univoco (impronta, un hash SHA-1). È spesso il metodo più affidabile.
• SignTool Commands: un metodo avanzato che consente di fornire comandi personalizzati per l’utilità SignTool.exe di Microsoft, offrendo la massima flessibilità. Vedere i marcatori di comando di seguito.
• Azure Artifact Signing (formerly Trusted Signing): firma l’applicazione con il servizio basato su cloud di Microsoft. Consultare il nostro tutorial su Azure Artifact Signing per la configurazione iniziale, e l’opzione Exclude credentials di seguito se la firma non riesce dopo az login.
• JSign: firma l’applicazione con lo strumento open source JSign, che richiede un runtime Java (JRE o JDK) nel PATH. Impostare il percorso di jsign.jar nelle Global Preferences, quindi inserire un comando JSign per riga, utilizzando gli stessi marcatori di comando di SignTool Commands.

Con i metodi SignTool Commands e JSign, si digita un comando per riga. Prima di eseguire ciascun comando, XLS Padlock sostituisce due marcatori:

Racchiudere tra virgolette i percorsi che potrebbero contenere spazi. Per fare riferimento a un file accanto al file EXE, aggiungere manualmente il backslash, ad esempio "{$OUTPUTFOLDER$}\my-metadata.json". È richiesto XLS Padlock 2026.2 o versione successiva affinché {$OUTPUTFOLDER$} venga sostituito quando è seguito direttamente da un backslash o da una virgoletta. Il comando SignTool predefinito, definito nelle Global Preferences, è:

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

Quando XLS Padlock firma con il metodo integrato Azure Artifact Signing, lo strumento di firma di Azure prova diversi tipi di credenziali uno dopo l’altro, in un ordine fisso, finché uno di essi non riesce. Su alcuni computer, un tipo di credenziale provato prima della credenziale di Azure CLI fallisce e interrompe l’intera operazione di firma, anche se az login è andato a buon fine e il profilo del certificato è valido. Il log di compilazione mostra quindi un errore di autenticazione come MsalCachePersistenceException: Persistence check failed.

Il campo facoltativo Exclude credentials (one per line, optional), disponibile a partire da XLS Padlock 2026.2, elenca i tipi di credenziali da escludere. Fare clic su Exclude all except Azure CLI per compilare la configurazione consigliata per un computer di sviluppo autenticato con az login: tutti i tipi di credenziale tranne AzureCliCredential.

I nomi accettati sono i nove tipi di credenziali documentati da Microsoft: ManagedIdentityCredential, WorkloadIdentityCredential, SharedTokenCacheCredential, VisualStudioCredential, VisualStudioCodeCredential, AzureCliCredential, AzurePowerShellCredential, AzureDeveloperCliCredential e InteractiveBrowserCredential. I nomi vengono verificati all’avvio della firma (senza distinzione tra maiuscole e minuscole; righe vuote e duplicati vengono ignorati). Un nome sconosciuto interrompe la firma con un errore, perché altrimenti lo strumento di firma lo ignorerebbe silenziosamente. Lasciare il campo vuoto per mantenere il comportamento predefinito: i metadati di firma saranno quindi identici a quelli delle versioni precedenti. Il valore viene salvato con il progetto.

XLS Padlock scrive il file dei metadati di firma (sign-metadata.json) accanto al file EXE di output a ogni firma. Non modificare manualmente questo file: le modifiche verrebbero sovrascritte alla generazione successiva.

• Firma manuale: fare clic su Sign EXE File Now per firmare immediatamente l’ultimo file EXE generato.
• Firma automatica: selezionare Automatically sign my EXE file affinché XLS Padlock firmi l’EXE ogni volta che si genera l’applicazione.