I’m not sure how much I can put here. I used ChatGPT to walk me through creating an account with Azure and creating a certificate for code signing. Then I had it summarize. Here are the results, hope it helps someone. If you’re going to use this, I would skim through it first.
The three biggest gotchas
If I were handing this to another SetupBuilder developer, I’d emphasize three things above everything else.
First: create an individual business-domain email before starting. Use firstname@companydomain.com, not support@, sales@, admin@, Gmail, etc. The primary mailbox is involved in multiple verification stages.
Second: make your government business record, Azure application and website agree. Organization name, address and domain discrepancies are exactly the sort of thing that turns a straightforward automated validation into an additional-document request.
Third: Azure CLI authentication is part of the signing setup. Having the JSON, SignTool and an Active certificate profile isn’t sufficient by itself. The build machine still needs an authenticated Azure identity with the Artifact Signing Certificate Profile Signer role. Microsoft documents the SignTool integration and authentication requirements here: Microsoft Artifact Signing integration documentation. (Microsoft Learn)
Microsoft’s full current setup documentation is here: Artifact Signing setup quickstart. Since Microsoft has already renamed Trusted Signing → Artifact Signing and continues updating the onboarding process, I’d treat Microsoft’s documentation as authoritative if the Azure screens differ from this walkthrough. (Microsoft Learn) Absolutely.
Below is a generic write-up aimed specifically at SetupBuilder 2025 developers moving to Microsoft Azure Artifact Signing. I’ve removed your company/product/account-specific information and incorporated the lessons from the problems we encountered. I also checked the current Microsoft documentation because this process has changed substantially. Microsoft now calls the service Artifact Signing; older SetupBuilder material may call it Trusted Signing. (Microsoft Learn)
Setting Up Microsoft Azure Artifact Signing with SetupBuilder 2025
Overview
Microsoft Azure Artifact Signing is Microsoft’s cloud-based code-signing service. It replaces the traditional arrangement where a developer obtains a code-signing certificate from a CA such as Sectigo and keeps the certificate in a PFX file or hardware token.
With Artifact Signing, Microsoft manages the signing certificate and private key. SetupBuilder uses Microsoft’s SignTool and Artifact Signing client to request signatures from Azure. Microsoft describes the service as digest-based signing, so the file itself does not need to be uploaded to Microsoft. (Microsoft Learn)
The overall process is:
Azure subscription → Artifact Signing account → Organization identity validation → Public Trust certificate profile → SetupBuilder 2025 → Azure CLI authentication → signed EXEs/DLLs/installers
There are several places where the setup is not obvious. In particular, prepare the correct individual business email address before starting identity validation.
1. Prepare Your Business Information First
Before creating the identity-validation request, make sure the public information about your business is accurate.
Microsoft recommends that public business records be current before beginning organization validation. The information entered in Azure needs to be supportable with business documentation. (Microsoft Learn)
Have the following ready:
-
Exact organization/business name you want on the code-signing certificate.
-
Current business address.
-
Business website.
-
Business identifier, such as Tax ID/EIN, registered business number, or D-U-N-S number, as appropriate.
-
Government business-registration documentation.
-
Access to the business website so you can update it if necessary.
-
An individual person’s email address on the business domain.
The email address is important
Create an individual business email before beginning, for example:
john@mysoftwarecompany.com
or:
john.smith@mysoftwarecompany.com
Do not plan on using a role address such as:
support@mysoftwarecompany.com
sales@mysoftwarecompany.com
admin@mysoftwarecompany.com
info@mysoftwarecompany.com
A role/distribution address can cause email validation trouble. Likewise, don’t use a personal consumer address such as Gmail or Hotmail for business validation.
The individual address should be on the organization’s domain, belong to the person performing the verification, and be able to receive external email containing links.
Microsoft’s current documentation says the Primary Email is used for Verified Credential and email-verification links, while the Secondary Email may be a distribution list, provided its domain matches the primary email domain. (Microsoft Learn)
So a good arrangement is:
Primary: john@mysoftwarecompany.com
Secondary: support@mysoftwarecompany.com
Test the primary mailbox from an outside email account before proceeding.
2. Create an Azure Subscription
You need a Microsoft Azure subscription and a Microsoft Entra tenant.
The Microsoft account you use to administer Azure does not necessarily have to have the same name as the company being verified. The Azure login identifies the person administering the Azure resources; the Artifact Signing identity validation establishes the organization whose name appears on the signing certificate.
Once the subscription exists, make sure you’re working in the correct Azure directory/tenant and subscription.
3. Register the Artifact Signing Resource Provider
Artifact Signing uses the Azure resource provider:
Microsoft.CodeSigning
In Azure Portal:
Subscriptions → your subscription → Resource providers
Find:
Microsoft.CodeSigning
and make sure its status is Registered.
Microsoft also supports doing this from Azure CLI. (Microsoft Learn)
4. Create the Artifact Signing Account
In Azure Portal, search for:
Artifact Signing Accounts
Create a new account.
You’ll select:
-
Subscription
-
Resource group
-
Artifact Signing account name
-
Region
-
Pricing/SKU
The account name needs to be unique.
Make a note of both the Artifact Signing account name and region. You will need them later when creating the JSON configuration file for SetupBuilder.
Artifact Signing is available only in supported Azure regions. Each region has a corresponding signing endpoint. (Microsoft Learn)
For example, an account created in West US 2 uses an endpoint in the form:
https://wus2.codesigning.azure.net/
Don’t copy that example unless your account is actually in West US 2. The endpoint must match your account’s Azure region.
5. Assign the Necessary Azure Roles
Go into the Artifact Signing account and open:
Access control (IAM) → Add role assignment
The Azure user who is doing the setup should have:
Artifact Signing Identity Verifier
This permits the user to perform/manage identity validation.
Also assign:
Artifact Signing Certificate Profile Signer
This is the role the identity needs later when actually signing files.
Being Owner of the Azure resource isn’t a substitute for these Artifact Signing-specific permissions. Microsoft’s signing integration specifically requires the signer role for the individual or group performing signing. (Microsoft Learn)
If the Azure user appears as a Guest in the tenant, that isn’t automatically a problem. What matters is that the correct Azure identity receives the required role assignments.
6. Create the Organization Identity Validation
Inside the Artifact Signing account go to:
Identity validations → + New identity
For software distributed publicly to customers, choose:
Public
rather than Private.
Public identity validation is what feeds a Public Trust certificate profile. (Microsoft Learn)
For an organization, enter the requested information, including:
Organization Name
Website URL
Primary Email
Secondary Email
Business Identifier
Business Address
First/Last name of representative
Organization name
Use the organization name that you want validated and displayed as the software publisher.
Microsoft supports organization/DBA validation, but the name needs to be supported by your business documentation. (Microsoft Learn)
Primary email
Use the individual business-domain email prepared earlier:
john@mysoftwarecompany.com
Do not casually use support@, sales@, etc. as Primary Email.
Business identifier
Azure may offer choices such as:
D-U-N-S
Tax ID
Registered Business Number
Use whichever identifier legitimately identifies the underlying business entity and is supported by your documentation.
Address
Use the current business address that your documentation can substantiate.
If the business registry shows an old address, consider updating the government record before submitting the Azure identity-validation request.
Microsoft specifically recommends that public records be current and says additional documentation should match the information entered in the validation request. (Microsoft Learn)
7. Personal Identity Verification
After submitting the organization identity validation, its status normally begins as:
In Progress
It may then change to:
Action Required
Microsoft may require the individual representing the organization to complete personal identity verification.
This is not changing the certificate into a personal certificate. Microsoft is verifying that a real person is representing the organization.
The process may involve:
-
Microsoft Authenticator
-
Microsoft Verified ID
-
A trusted identity-verification provider such as AU10TIX
-
Government-issued identification
-
Phone verification
-
Identity/face verification
Microsoft’s current walkthrough describes obtaining a Verified ID through a trusted verifier, adding that Verified ID to Microsoft Authenticator, and then presenting it back to Artifact Signing. (Microsoft Learn)
If Authenticator says:
Required Verified ID not found
you probably need to follow Azure’s link to get verified through a trusted ID verifier first. After the credential has been created and appears in Authenticator, return to the Azure verification process and present it.
A successful browser result should eventually say something similar to:
Verification Successful
8. Be Prepared to Supply Business Documentation
Microsoft may subsequently change the validation to Action Required again and request organization documentation.
This is normal.
For example, Microsoft may request one document establishing the business and another establishing its relationship to the website/domain.
Useful evidence can include:
Government/business evidence:
-
Articles of incorporation
-
Partnership documentation
-
Government registration/certificate
-
Government business-registry record
-
Tax records
-
Lease or tenancy documents
-
Financial institution/utility documents
Website/domain evidence:
-
Domain ownership records
-
Domain purchase/renewal records
-
Website showing the organization name, address, contact information and domain
-
Other documentation connecting the organization with the domain
Microsoft’s current guidance says requested documents can be uploaded through the Azure Portal and that there are only three attempts for additional-document submissions, so check the evidence carefully before submitting it. (Microsoft Learn)
A practical combination
A particularly straightforward combination for a small software company is:
Government document:
Current state/provincial/federal business registration showing the organization’s name and address.
Website document:
A PDF printout of a Contact/About page showing:
Example Software Company
123 Business Street
Somewhere, ST 12345
1-800-555-1234
sales@examplecompany.com
Print the page to PDF with browser headers and footers enabled, so the PDF also visibly contains:
https://www.examplecompany.com/contact/
This creates a clear connection between:
Government registration → company name → address → company website/domain
If you temporarily add information to the website for verification purposes, leave it available until identity validation has completely finished.
Microsoft says identity validation can take 1–20 business days, and potentially longer when additional documentation is required. (Microsoft Learn)
9. Complete Email Verification
Watch the Primary Email carefully.
Microsoft sends email-verification links as part of the organization-validation process. The verification link is valid for seven days. (Microsoft Learn)
This is another reason the Primary Email should be:
-
Monitored.
-
Able to receive external messages.
-
Associated with an individual at the organization.
-
On the business domain.
If email verification fails, Microsoft’s current guidance says a new identity-validation request may be required. (Microsoft Learn)
Once everything has been accepted, the Identity Validation status should eventually become:
Completed
10. Check the Certificate Subject Preview
Once completed, inspect the certificate subject preview.
It should contain the organization name you expect, for example:
CN=Example Software Company
O=Example Software Company
It may also offer address information such as:
STREET=123 Business Street
L=Somewhere
S=State
C=US
PC=12345
This matters because the certificate subject is what becomes part of your code-signing certificate.
11. Create the Public Trust Certificate Profile
Go to:
Artifact Signing account → Certificate profiles → Create
Create a Public Trust certificate profile.
Give it a useful internal name, for example:
ProductionSigning
or:
SetupBuilderSigning
When prompted for Verified CN and O, select the completed organization identity.
If the screen presents Program Type and you are simply signing normal Windows applications/installers, don’t select a specialized security program such as Windows Endpoint Security Platform unless your product actually participates in that program.
Address privacy
Azure may offer checkboxes such as:
Include street address
Include postal code
Think carefully before enabling these.
Microsoft says these options cause the address/postal information to be included in the certificate subject. (Microsoft Learn)
For a home-based software business, leaving them unchecked prevents the home street address from unnecessarily becoming part of every publicly inspectable code-signing certificate.
The important publisher fields can remain:
CN=Example Software Company
O=Example Software Company
After creation, the certificate profile should show:
Active
12. Install SetupBuilder 2025 Artifact-Signing Requirements
SetupBuilder 2025 supports Microsoft’s cloud signing system, although SetupBuilder material may refer to it as Trusted Signing while Microsoft now calls it Artifact Signing.
On the Windows machine where SetupBuilder builds/signs the installation, you’ll need the supporting signing components.
.NET 8 Runtime
Install the regular:
.NET Runtime 8.x
The description on Microsoft’s download page says it contains the components needed to run a console app.
You do not need ASP.NET Core Runtime merely to satisfy this requirement.
Download .NET 8 from Microsoft
Use the appropriate Windows architecture—normally x64 on a modern 64-bit development machine.
SetupBuilder SignInstall
SetupBuilder 2025 provides a SignInstall package containing signing components compatible with its Artifact/Trusted Signing support.
Install the appropriate x86/x64 version as required by your SetupBuilder environment.
After installation, locate the SignTool installed by the Lindersoft package. SetupBuilder needs an Artifact Signing-compatible SignTool rather than blindly continuing to use an ancient signtool.exe left over from a previous PFX-based certificate installation.
Microsoft’s current Artifact Signing SignTool integration has specific SignTool and supporting-component prerequisites. (Microsoft Learn)
13. Create the Artifact Signing JSON File
Unlike traditional code signing, you do not select a .pfx certificate.
Create a small JSON configuration file containing the Azure Artifact Signing information.
For example:
{
"Endpoint": "https://YOUR-REGION.codesigning.azure.net/",
"CodeSigningAccountName": "YourArtifactSigningAccount",
"CertificateProfileName": "ProductionSigning"
}
Save it somewhere permanent, for example:
C:\CodeSigning\metadata.json
The endpoint must correspond to the Azure region where the Artifact Signing account was created. Microsoft explicitly requires the endpoint URI to match the account/profile region. (Microsoft Learn)
The file does not contain:
-
Private key
-
Certificate password
-
Azure password
Azure holds the signing key.
14. Configure SetupBuilder 2025 Code Signing
In SetupBuilder 2025 go to:
Configuration → Code-Signing
Configure the fields approximately as follows.
SignTool
Point this to the newer SignTool installed for SetupBuilder/Artifact Signing.
Software Publisher Certificate
Instead of selecting an old .pfx, choose the Trusted Signing .json configuration and point SetupBuilder to:
C:\CodeSigning\metadata.json
Trusted Signing DLIB
If SetupBuilder labels this optional, it can normally be left blank when the supporting signing package has already installed/configured the required components.
If signing later fails because the DLIB cannot be located, specify it explicitly.
PFX Password
Leave this blank.
Artifact Signing doesn’t use your old PFX file or PFX password.
SHA-1 timestamp server
Leave blank.
SHA-2 timestamp server
Use Microsoft’s Artifact Signing timestamp service:
http://timestamp.acs.microsoft.com
Microsoft’s SignTool integration uses SHA-256 for file digest and timestamp digest. (Microsoft Learn)
Certificate configuration choice
Select:
Use Software Publisher Certificate Configuration
Do not select SafeNet/eToken options unless you are actually using that hardware-token infrastructure.
eToken configuration
Ignore it for Azure Artifact Signing.
Signing algorithm
Choose:
SHA-2 only
There’s normally no reason to use SHA-1 for current Windows software.
15. Install Azure CLI
The next piece is easy to overlook.
SetupBuilder/SignTool needs an authenticated Azure identity in order to request the signature.
Install Microsoft’s Azure CLI on the same Windows development/build machine.
With Windows Package Manager:
winget install --exact --id Microsoft.AzureCLI
Here:
--id Microsoft.AzureCLI
identifies the package, while:
--exact
tells WinGet to require an exact package-ID match.
After installation, close and reopen Command Prompt/PowerShell so the new az command is available.
16. Authenticate Azure CLI
Run:
az login
Complete Microsoft’s browser authentication and MFA.
If your Azure account belongs to a particular Entra tenant and ordinary az login has trouble finding the subscription, Azure CLI may tell you to log into the tenant explicitly:
az login --tenant YOUR-TENANT-ID
For example:
az login --tenant xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
If interactive browser authentication is troublesome, Azure CLI also supports device-code authentication:
az login --tenant YOUR-TENANT-ID --use-device-code
Then verify the subscriptions visible to the authenticated account:
az account list --output table
If necessary, select the subscription containing the Artifact Signing account:
az account set --subscription "YOUR-SUBSCRIPTION-ID-OR-NAME"
Finally verify:
az account show --output table
The account needs access to the correct subscription/tenant and must have the Artifact Signing Certificate Profile Signer role.
Microsoft’s Artifact Signing SignTool integration uses Azure Identity/DefaultAzureCredential, which supports credentials such as the authenticated Azure CLI session. (Microsoft Learn)
17. Restart SetupBuilder and Perform a Test Signing
After Azure CLI authentication succeeds:
-
Close SetupBuilder.
-
Reopen SetupBuilder.
-
Enable code signing on one test EXE or DLL.
-
Run the build/sign operation.
Starting with one file makes authentication/configuration errors much easier to diagnose than turning signing on for an entire installation immediately.
If a failed signing attempt leaves a file locked, check Task Manager/Resource Monitor for a leftover:
signtool.exe
A failed authentication attempt can occasionally leave SignTool running and holding the EXE/DLL open. Close SetupBuilder first and then terminate the orphaned SignTool process if necessary.
18. Verify the Resulting Signature
Once signing succeeds, right-click the signed EXE or DLL:
Properties → Digital Signatures
You should see the verified organization/publisher name.
Select the signature and choose:
Details
The important result is:
This digital signature is OK.
Also confirm that the file was timestamped.
19. Don’t Be Alarmed by the Short Certificate Lifetime
One thing that looks strange to developers accustomed to Sectigo-style certificates is the very short lifetime of the actual Artifact Signing certificate.
That’s intentional.
Artifact Signing uses short-lived signing certificates rather than issuing you a traditional long-lived PFX certificate. The timestamp is therefore extremely important: properly timestamped signatures remain verifiable after the individual short-lived signing certificate expires.
In other words, don’t see a certificate valid for only a few days and assume something is wrong.
20. Enable Signing for the Rest of the Installation
Once one EXE/DLL signs successfully and verifies correctly, enable signing for the rest of the files that are distributed:
-
Main application EXEs
-
Helper applications
-
Services
-
Updaters
-
DLLs
-
Other executable components
-
Final SetupBuilder installer
The normal goal is:
Sign the individual executable components first → build the installation → sign the completed installer last.
Then spot-check:
-
Main EXE
-
One DLL
-
One secondary EXE
-
Final installer
Each should show the expected organization name and:
This digital signature is OK.
Quick SetupBuilder Checklist
For someone who has already completed the Azure verification and just needs to configure a build PC, the short version is:
AZURE
✓ Artifact Signing account created
✓ Public organization identity = Completed
✓ Public Trust certificate profile = Active
✓ Artifact Signing Certificate Profile Signer role assigned
BUILD MACHINE
✓ SetupBuilder 2025 installed
✓ .NET 8 Runtime installed
✓ SetupBuilder SignInstall installed
✓ Compatible SignTool selected
✓ Artifact Signing metadata JSON created
✓ Azure CLI installed
SETUPBUILDER CODE-SIGNING
✓ Software Publisher Certificate = Trusted Signing JSON
✓ Trusted Signing DLIB = blank unless explicitly needed
✓ PFX Password = blank
✓ SHA-1 timestamp = blank
✓ SHA-2 timestamp = http://timestamp.acs.microsoft.com
✓ Use Software Publisher Certificate Configuration
✓ SHA-2 only
AZURE AUTHENTICATION
✓ az login --tenant <tenant-id>
✓ MFA completed
✓ az account list --output table
✓ Correct subscription selected
✓ az account show --output table
TEST
✓ Test EXE/DLL signs
✓ Publisher name is correct
✓ "This digital signature is OK"
✓ Timestamp is present
✓ Final SetupBuilder installer is signed
