#
Signing Protected Applications and Assemblies
Code signing identifies the publisher of an EXE or DLL and lets Windows check whether the signed file has changed. .NET Reactor can apply this Authenticode signature after protecting the file.
#
Code-signing certificates
Open Settings → 1. General Settings → Code Signing Certificate and choose one of the following certificate sources.
#
USB tokens and the Windows certificate store
Publicly trusted code-signing certificates use hardware-backed private keys, commonly on a USB token rather than in a PFX file. Install the token's software and connect the device. Its certificate then appears in the Windows certificate store, while the private key remains on the token.
Enter the certificate's friendly name in Code Signing Certificate → Certificate Store Friendly Name. You can also use the value shown in the certificate store's Issued To column. A thumbprint is supported as well.
Reactor searches the current user's and local computer's My and TrustedPublisher stores. The account running Reactor must be able to access the certificate and use its private key. The same setting also works for store certificates that do not use a USB token.
To supply the device PIN automatically, enter it under Code Signing Certificate → Hardware Token Settings → Token Pin.
Incorrect PINs can lock the token
A wrong PIN can quickly lock the device through repeated signing attempts. Only enter a PIN you know is correct, and stop retrying if authentication fails. Do not share project files containing the PIN.
#
Azure Artifact Signing
Under Code Signing Certificate → Azure Artifact Signing, enable the integration and fill in these six settings:
Your Artifact Signing account and certificate profile must already exist. To create the signing app and its credentials, open Cloud Shell from the button at the top of the Azure portal and select PowerShell.
Replace the resource group, account, and profile names below. The script uses your current Azure CLI subscription. To switch subscriptions first, run az account set --subscription "your-subscription-id".
$resourceGroup = "your-resource-group"
$accountName = "your-signing-account"
$profileName = "your-certificate-profile"
$appName = "mysigningapp-$(Get-Date -Format 'yyyyMMdd-HHmmss')"
$subId = az account show --query id -o tsv
if ($LASTEXITCODE -ne 0 -or -not $subId) {
throw "Cannot read the current Azure subscription."
}
$scope = "/subscriptions/$subId/resourceGroups/$resourceGroup/providers/Microsoft.CodeSigning/codeSigningAccounts/$accountName/certificateProfiles/$profileName"
az ad sp create-for-rbac --name $appName `
--role "Artifact Signing Certificate Profile Signer" `
--scopes $scope --years 3 --json-auth --only-show-errors
The command creates an app registration and service principal, then assigns the Artifact Signing Certificate Profile Signer role for that profile. Your Azure user needs permission to create the app and assign the role.
Copy clientId, clientSecret, and tenantId from the console output into Reactor. Keep the output private because it contains the client secret.
The example requests a three-year secret with --years 3. Adjust this to your organization's policy. See the Azure CLI command reference.
To delete the app or replace its secret later, search for App registrations in the Azure portal and open the app. Additional apps are usually only needed for separate signing access, such as different users or build agents.
For automated builds, you can leave Tenant ID, Client ID, and Client Secret empty in the Reactor project and supply them through AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET. This avoids saving the secret in the project file.
When enabled, Azure Artifact Signing takes precedence over the certificate-file and certificate-store settings. The integration is optional. You can also protect without signing in Reactor, then sign the protected output with SignTool or another signing tool.
#
PFX, P12, and other certificate files
For a file-based certificate, set PFX/P12/SPC File to your .pfx or .p12 file and enter its password under PFX/P12/PVK Password. The file must contain both the certificate and its private key.
Reactor also accepts .spc or .cer certificates with a separate .pvk private-key file. Keep private keys, passwords, and project files containing credentials out of source control.
#
Add a timestamp
Under Code Signing Certificate, enable SHA256 Time Stamp Server Signature and set its Time Stamp URL. A timestamp allows a signature made while the certificate was valid to remain verifiable after the certificate expires.
Keep SHA-1 disabled unless you need legacy compatibility. With a local certificate, enabling both SHA-256 and SHA-1 creates a dual signature. Azure Artifact Signing uses the configured SHA-256 timestamp service.
For fallback servers, separate multiple URLs with semicolons. Reactor tries them in order. If timestamping fails, check the server addresses and the build computer's network or proxy settings.
#
Strong-name signing
A strong name is part of a .NET assembly's identity. It does not establish publisher trust and is separate from the code-signing certificate above.
If the input assembly has a strong name, Reactor needs its private key to sign the protected assembly again. Configure Settings → 1. General Settings → Strong Name Key Pair File:
Use the original key to keep the public key token unchanged. A different key can break assembly references and InternalsVisibleTo declarations. Without a key, Reactor reports that the Strong Name KeyPair file is missing.
Enforce Signing also gives unsigned assemblies a strong name. This changes their identity and can affect assemblies that reference them.
#
Sign after protection
Protection changes the file and invalidates an existing signature. Reactor re-signs the protected output when signing is configured.
If another step changes the output, such as ReadyToRun compilation or bundling, apply Authenticode signing after that step. Sign installers separately from the files they contain.
For a .NET single-file application, verify the executable rebuilt by Reactor rather than the original publish output. For ReadyToRun build order, see ReadyToRun.
#
Command line
Configure signing in the GUI, then use Command-line → Generate Command-line to obtain the arguments and password encoding expected by Reactor.
Use -licensed in automated builds to stop if no full license is available. See Command-line parameters.
#
Verify the signed files
Check the final EXE or DLL with the Windows SDK's SignTool:
signtool verify /pa /all /v "dist\MyApp.exe"
This checks all Authenticode signatures and displays certificate and timestamp details.
For a strong-named .NET Framework assembly, check the public key token with sn -T and verify the signature with sn -vf:
sn -T "dist\MyLibrary.dll"
sn -vf "dist\MyLibrary.dll"
#
Related topics
Single-file publishing · ReadyToRun · Verify protected output · Antivirus false positives