Routinely Signing a Home windows EXE with Azure Trusted Signing, dotnet signal, and GitHub Actions

Mac Tahoe (in Beta as of the time of this writing) has this new characteristic known as Edge Gentle that principally places a vivid image of an Edge Gentle round your display and principally makes use of the facility of OLED to present you a digital ring mild. So I used to be like, why cannot we even have good issues? I wrote (vibed, with GitHub Copilot and Claude Sonnet 4.5) a Home windows Edge Gentle App (supply code at https://github.com/shanselman/WindowsEdgeLight and you may get the most recent launch right here https://github.com/shanselman/WindowsEdgeLight/releases or the app will examine for brand new releases and autoupdate with Updatum).

Nonetheless, as is with all suss unfastened executables on the web, once you run random stuff you may typically get the Window Defender ‘new cellphone, who dis’ warning which is horrifying. After a number of downloads and no viruses or complaints, my executable will ultimately achieve fame with the Home windows Defender Sensible Display service, however having a Code Signing Certificates is alleged to assist with that. Nonetheless, code signing certs are costly and a trouble to handle and renew.

Somebody instructed me that Azure Trusted Signing was considerably much less of a trouble – it is much less, but it surely’s nonetheless non-trivial. I learn this publish from Rick (his weblog is gold and has been for years) earlier within the 12 months and a few of it was tremendous helpful and different stuff has been made easier over time.

I wrote 80% of this weblog publish, however since I simply spent an hour getting code signing to work and GitHub Copilot was going by and logging every thing I did, I did use Claude 4.5 to assist set up a few of this. I’ve reviewed all of it and re-written elements I did not like, so any errors are mine.

Azure Trusted Signing is Microsoft’s cloud-based code signing service that:

• No {hardware} tokens – Every little thing occurs within the cloud
• Computerized certificates administration – Certificates are issued and renewed robotically
• GitHub Actions integration – Signal throughout your CI/CD pipeline. I used GH Actions.
• Kinda Affortable – About $10/month for small initiatives. I would really like it if this have been $10 a 12 months. That is cheaper than a yearly cert, but it surely’ll add up after some time so I am all the time in search of cheaper/simpler choices.
• Trusted by Home windows – Makes use of the identical certificates authority as Microsoft’s personal apps, so you need to get your EXE trusted quicker

Stipulations

Earlier than beginning, you may want:

1. Azure subscription
2. Azure CLI – Set up from right here
3. Identification validation paperwork – Driver’s license or passport for particular person builders. Be aware that I am within the US, so your mileage might differ however I principally arrange the account, scanned a QR code, took an image of my license, then did a selfie, then waited.
4. Home windows PC – For native signing (optionally available) however I ended up utilizing the dotnet signal device. There are
5. GitHub repository – For automated signing (optionally available)

Half 1: Setting Up Azure Trusted Signing

Step 1: Register the Useful resource Supplier

First, I must allow the Azure Trusted Signing service in my subscription. This may be completed within the Portal, or on the CLI.

# Login to Azure
az login

# Register the Microsoft.CodeSigning useful resource supplier
az supplier register --namespace Microsoft.CodeSigning

# Anticipate registration to finish (takes 2-3 minutes)
az supplier present --namespace Microsoft.CodeSigning --query "registrationState"

Wait till the output exhibits "Registered".

Step 2: Create a Trusted Signing Account

Now create the precise signing account. You are able to do this by way of Azure Portal or CLI.

Possibility A: Azure Portal (Simpler for first-timers)

1. Go to Azure Portal
2. Seek for “Trusted Signing Accounts”
3. Click on Create
4. Fill in:
   • Subscription: Your subscription
   • Useful resource Group: Create new or use present (e.g., “MyAppSigning”)
   • Account Identify: A singular title (e.g., “myapp-signing”)
   • Area: Select closest to you (e.g., “West US 2”)
   • SKU: Primary (adequate for many apps)
5. Click on Assessment + Create, then Create

Possibility B: Azure CLI (Quicker if you’re a CLI individual or prefer to drive stick shift)

# Create a useful resource group
az group create --name MyAppSigning --location westus2

# Create the Trusted Signing account
az trustedsigning create 
  --resource-group MyAppSigning 
  --account-name myapp-signing 
  --location westus2 
  --sku-name Primary

Vital: Be aware your area endpoint. Frequent ones are:

• East US: https://eus.codesigning.azure.internet/
• West US 2: https://wus2.codesigning.azure.internet/
• Your particular area: Examine in Azure Portal underneath your account’s Overview web page

I completely flaked on this and messed round for 10 min earlier than I spotted that this URL issues and is restricted to your account. Bear in mind this endpoint.

Step 3: Full Identification Validation

That is crucial step. Microsoft must confirm you are an actual individual/group.

1. In Azure Portal, go to your Trusted Signing Account
2. Click on Identification validation within the left menu
3. Click on Add identification validation
4. Select validation kind:
   • Particular person: For solo builders (makes use of driver’s license/passport)
   • Group: For corporations (makes use of enterprise registration paperwork)
5. For Particular person validation:
   • Add a transparent photograph of your government-issued ID
   • Present your full authorized title (should match ID precisely)
   • Present your e-mail handle
6. Submit and await approval

Approval Time:

• Particular person: Often 1-3 enterprise days
• Group: 3-5 enterprise days
• Me: This took about 4 hours, so once more, YMMV. I used my private account and my private Azure (do not belief MSFT of us with limitless Azure credit, I pay for my very own) so that they did not understand it was me. I went by the common line, not the Pre-check line LOL.

You will obtain an e-mail when accepted. You can not signal any code till that is accepted.

Step 4: Create a Certificates Profile

As soon as your identification is validated, create a certificates profile. That is what truly points the signing certificates.

1. In your Trusted Signing Account, click on Certificates profiles
2. Click on Add certificates profile
3. Fill in:
   • Profile title: Descriptive title (e.g., “MyAppProfile”)
   • Profile kind: Select Public Belief (required to stop SmartScreen)
   • Identification validation: Choose your accepted identification
   • Certificates kind: Code Signing
4. Click on Add

Vital: Solely “Public Belief” profiles forestall SmartScreen warnings. “Personal Belief” is for inner apps solely. This took me a second to comprehend additionally as it is not an intuitive title.

Step 5: Confirm Your Setup

# Record your Trusted Signing accounts
az trustedsigning present 
  --resource-group MyAppSigning 
  --account-name myapp-signing

# Ought to present standing: "Succeeded"

Write down these values – you may want them later:

• Account Identify: myapp-signing
• Certificates Profile Identify: MyAppProfile
• Endpoint URL: https://wus2.codesigning.azure.internet/ (or your area)
• Subscription ID: Present in Azure Portal
• Useful resource Group: MyAppSigning

Half 2: Native Code Signing

Now let’s signal an executable in your my machine. You do not NEED to do that, however I needed to attempt it regionally to keep away from a bunch of CI/CD runs, and I needed to right-click the EXE and see the cert in Properties earlier than I took all of it to the cloud. The good half about this was that I did not must mess with any certificates.

Step 1: Assign Your self the Signing Position

You want permission to really use the signing service.

Possibility A: Azure Portal

1. Go to your Trusted Signing Account
2. Click on Entry management (IAM)
3. Click on Add → Add position task
4. Seek for and choose Trusted Signing Certificates Profile Signer. That is essential. I looked for “code” and located nothing. Seek for “Trusted”
5. Click on Subsequent
6. Click on Choose members and discover your person account
7. Click on Choose, then Assessment + assign

Possibility B: Azure CLI

# Get your person object ID
$userId = az advert signed-in-user present --query id -o tsv

# Assign the position
az position task create 
  --role "Trusted Signing Certificates Profile Signer" 
  --assignee-object-id $userId 
  --scope /subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/MyAppSigning/suppliers/Microsoft.CodeSigning/codeSigningAccounts/myapp-signing

Substitute YOUR_SUBSCRIPTION_ID along with your precise subscription ID.

Step 2: Login with the Appropriate Scope

That is essential – that you must login with the particular codesigning scope.

# Logout first to clear outdated tokens
az logout

# Login with codesigning scope
az login --use-device-code --scope "https://codesigning.azure.internet/.default"

This provides you with a code to enter at https://microsoft.com/devicelogin. Observe the prompts.

Why gadget code circulate? As a result of Azure CLI’s default authentication can battle with Visible Studio credentials in my expertise. Machine code circulate is extra dependable for code signing.

Step 3: Obtain the Signal Device

Possibility A: Set up Globally (Beneficial for normal use)

# Set up as a world device (accessible all over the place)
dotnet device set up --global --prerelease signal

# Confirm set up
signal --version

Possibility B: Set up Regionally (Mission-specific)

# Set up to present listing
dotnet device set up --tool-path . --prerelease signal

# Use with .signal.exe

Which ought to I take advantage of?

• International: When you’ll signal a number of initiatives or signal continuously
• Native: If you wish to hold the device with a particular undertaking or don’t need it in your PATH

Step 4: Signal Your Executable

Be aware once more that code signing URL is restricted to you. The tscp is your Trusted Signing Certificates Profile title and the tsa is your Trusted Signing Account title. I set *.exe to signal all of the EXEs within the folder and observe that the -b base listing is an absolute path, not a relative one. For me it was d:githubWindowsEdgeLightpublish, and your mileage will differ.

# Navigate to your undertaking folder
cd C:MyProject

# Signal the executable
.signal.exe code trusted-signing `
  -b "C:MyProjectpublish" `
  -tse "https://wus2.codesigning.azure.internet" `
  -tscp "MyAppProfile" `
  -tsa "myapp-signing" `
  *.exe `
  -v Data

Parameters defined:

• -b: Base listing containing information to signal
• -tse: Trusted Signing endpoint (your area)
• -tscp: Certificates profile title
• -tsa: Trusted Signing account title
• *.exe: Sample to match information to signal
• -v: Verbosity degree (Hint, Data, Warning, Error)

Anticipated output:

information: Signing WindowsEdgeLight.exe succeeded.
Accomplished in 2743 ms.

Step 5: Confirm the Signature

You are able to do this in PowerShell:

# Examine the signature
Get-AuthenticodeSignature ".publishMyApp.exe" | Format-Record

# Search for:
# Standing: Legitimate
# SignerCertificate: CN=Your Identify, O=Your Identify, ...
# TimeStamperCertificate: Needs to be current

Proper-click the EXE → Properties → Digital Signatures tab:

• You must see your signature
• “This digital signature is OK”

Frequent Native Signing Points

I hit all of those lol

Subject: “Please run ‘az login’ to arrange account”

• Trigger: Not logged in with the suitable scope
• Repair: Run az logout then az login --use-device-code --scope "https://codesigning.azure.internet/.default"

Subject: “403 Forbidden”

• Trigger: Incorrect endpoint, account title, or lacking permissions
• Repair:
  • Confirm endpoint matches your area (wus2, eus, and so on.)
  • Confirm account title is actual (case-sensitive)
  • Confirm you might have “Trusted Signing Certificates Profile Signer” position

Subject: “Consumer account doesn’t exist in tenant”

• Trigger: Azure CLI making an attempt to make use of Visible Studio credentials
• Repair: Use gadget code circulate (see Step 2)

Half 3: Automated Signing with GitHub Actions

That is the place the magic occurs. I wish to robotically signal each launch. I am utilizing GitVersion so I simply must tag a commit and GitHub Actions will kick off a run. You possibly can go take a look at an actual run intimately at https://github.com/shanselman/WindowsEdgeLight/actions/runs/19775054123

Step 1: Create a Service Principal

GitHub Actions wants its personal identification to signal code. We’ll create a service principal (like a robotic account). That is VERY completely different than your native signing setup.

Vital: You want Proprietor or Consumer Entry Administrator position in your subscription to do that. If you do not have it, ask your Azure admin or a good friend.

# Create service principal with signing permissions
az advert sp create-for-rbac 
  --name "MyAppGitHubActions" 
  --role "Trusted Signing Certificates Profile Signer" 
  --scopes /subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/MyAppSigning/suppliers/Microsoft.CodeSigning/codeSigningAccounts/myapp-signing 
  --json-auth

This outputs JSON like this:

{
  "clientId": "12345678-1234-1234-1234-123456789abc",
  "clientSecret": "super-secret-value-abc123",
  "tenantId": "87654321-4321-4321-4321-cba987654321",
  "subscriptionId": "abcdef12-3456-7890-abcd-ef1234567890"
}

SAVE THESE VALUES IMMEDIATELY! You possibly can’t retrieve the clientSecret once more. That is tremendous essential.

Various: Azure Portal Technique

If CLI does not work:

1. Azure Portal → App registrations → New registration
2. Identify: “MyAppGitHubActions”
3. Click on Register
4. Copy the Utility (consumer) ID – that is AZURE_CLIENT_ID
5. Copy the Listing (tenant) ID – that is AZURE_TENANT_ID
6. Go to Certificates & secrets and techniques → New consumer secret
7. Description: “GitHub Actions”
8. Expiration: 24 months (max)
9. Click on Add and instantly copy the Worth – that is AZURE_CLIENT_SECRET
10. Go to your Trusted Signing Account → Entry management (IAM)
11. Add position task → Trusted Signing Certificates Profile Signer
12. Choose members → Seek for “MyAppGitHubActions”
13. Assessment + assign

Step 2: Add GitHub Secrets and techniques

Go to your GitHub repository:

1. Settings → Secrets and techniques and variables → Actions
2. Click on New repository secret for every:

• AZURE_CLIENT_ID – From service principal output or App registration
• AZURE_CLIENT_SECRET - From service principal output or Certificates & secrets and techniques
• AZURE_TENANT_ID – From service principal output or App registration
• AZURE_SUBSCRIPTION_ID – Azure Portal → Subscriptions

Safety Be aware: These secrets and techniques are encrypted and by no means seen in logs. Solely your workflow can entry them. You will by no means see them once more.

Step 3: Replace Your GitHub Workflow

It is a little complicated because it’s YAML, which is Devil’s markup, but it surely’s what we’ve sunk to as a society.

Be aware the dotnet-version beneath. Yours is likely to be 8 or 9, and so on. Additionally, I’m constructing each x64 and ARM variations and I’m utilizing GitVersion so in order for you a extra full construct.yml, you possibly can go right here https://github.com/shanselman/WindowsEdgeLight/blob/grasp/.github/workflows/construct.yml I’m additionally zipping mine up and prepping my releases so my unfastened EXE lives in a ZIP file.

Add signing steps to your .github/workflows/construct.yml:

title: Construct and Signal

on:
  push:
    tags:
      - 'v*'
  workflow_dispatch:

permissions:
  contents: write

jobs:
  construct:
    runs-on: windows-latest
    
    steps:
    - title: Checkout code
      makes use of: actions/checkout@v4
      with:
        fetch-depth: 0
      
    - title: Setup .NET
      makes use of: actions/setup-dotnet@v4
      with:
        dotnet-version: '10.0.x'
        
    - title: Restore dependencies
      run: dotnet restore MyApp/MyApp.csproj

    - title: Construct
      run: |
        dotnet publish MyApp/MyApp.csproj `
          -c Launch `
          -r win-x64 `
          --self-contained

    # === SIGNING STEPS START HERE ===
    
    - title: Azure Login
      makes use of: azure/login@v2
      with:
        creds: '{"clientId":"${{ secrets and techniques.AZURE_CLIENT_ID }}","clientSecret":"${{ secrets and techniques.AZURE_CLIENT_SECRET }}","subscriptionId":"${{ secrets and techniques.AZURE_SUBSCRIPTION_ID }}","tenantId":"${{ secrets and techniques.AZURE_TENANT_ID }}"}'

    - title: Signal executables with Trusted Signing
      makes use of: azure/trusted-signing-action@v0
      with:
        azure-tenant-id: ${{ secrets and techniques.AZURE_TENANT_ID }}
        azure-client-id: ${{ secrets and techniques.AZURE_CLIENT_ID }}
        azure-client-secret: ${{ secrets and techniques.AZURE_CLIENT_SECRET }}
        endpoint: https://wus2.codesigning.azure.internet/
        trusted-signing-account-name: myapp-signing
        certificate-profile-name: MyAppProfile
        files-folder: ${{ github.workspace }}MyAppbinReleasenet10.0-windowswin-x64publish
        files-folder-filter: exe
        files-folder-recurse: true
        file-digest: SHA256
        timestamp-rfc3161: http://timestamp.acs.microsoft.com
        timestamp-digest: SHA256
    
    # === SIGNING STEPS END HERE ===
        
    - title: Create Launch
      if: startsWith(github.ref, 'refs/tags/')
      makes use of: softprops/action-gh-release@v2
      with:
        information: MyApp/bin/Launch/net10.0-windows/win-x64/publish/MyApp.exe
      env:
        GITHUB_TOKEN: ${{ secrets and techniques.GITHUB_TOKEN }}

Key factors:

• endpoint: Use YOUR area’s endpoint (wus2, eus, and so on.)
• trusted-signing-account-name: Your account title (actual, case-sensitive)
• certificate-profile-name: Your certificates profile title (actual, case-sensitive)
• files-folder: Path to your compiled executables
• files-folder-filter: File varieties to signal (exe, dll, and so on.)
• files-folder-recurse: Signal information in subfolders

Step 4: Take a look at the Workflow

Now set off the workflow. You will have two choices:

Possibility A: Handbook Set off (Most secure for testing)

For the reason that workflow consists of workflow_dispatch:, you possibly can set off it manually with out making a tag:

# Set off manually by way of GitHub CLI
gh workflow run construct.yml

# Or go to GitHub internet UI:
# Actions tab → "Construct and Signal" workflow → "Run workflow" button

That is ideally suited for testing as a result of:

• No tag required
• Will not create a launch
• Can take a look at a number of occasions
• Straightforward to debug points

Possibility B: Create a Tag (For precise releases)

# Ensure you're in your principal department with no uncommitted modifications
git standing

# Create and push a tag
git tag v1.0.0
git push origin v1.0.0

Use this once you’re able to create an precise launch with signed binaries. That is what I’m doing on my facet.

Step 5: Monitor the Construct

Watch the progress with GitHub CLI:

# See newest runs
gh run checklist --limit 5

# Watch a particular run
gh run watch

# View detailed standing
gh run view --log

Or go to: https://github.com/YOUR_USERNAME/YOUR_REPO/actions

Search for:

• Azure Login – Ought to full in ~5 seconds
• Signal executables with Trusted Signing – Ought to full in ~10-30 seconds
• Create Launch – Your signed executable is now accessible in /releases in your GitHib undertaking

Frequent GitHub Actions Points

I hit a couple of of those, natch.

Subject: “403 Forbidden” throughout signing

• Trigger: Service principal does not have permissions
• Repair:
  1. Go to Azure Portal → Trusted Signing Account → Entry management (IAM)
  2. Confirm “MyAppGitHubActions” has “Trusted Signing Certificates Profile Signer” position
  3. If not, add it manually

Subject: “No information matched the sample”

• Trigger: Incorrect files-folder path or construct artifacts in incorrect location
• Repair:
  1. Add a debug step earlier than signing: - run: Get-ChildItem -Recurse
  2. Discover the place your EXE is definitely situated
  3. Replace files-folder to match

Subject: Secrets and techniques not working

• Trigger: Typo in secret title or worth not saved
• Repair:
  1. Confirm secret names EXACTLY match (case-sensitive)
  2. Re-create secrets and techniques if uncertain
  3. Be sure no further areas in values

Subject: “DefaultAzureCredential authentication failed”

• Trigger: Often incorrect tenant ID or consumer ID
• Repair: Confirm all 4 secrets and techniques are right from service principal output

Half 4: Understanding the Certificates

Certificates Lifecycle

Azure Trusted Signing makes use of short-lived certificates (sometimes 3 days). This freaked me out however they are saying that is truly a safety characteristic:

• If a certificates is compromised, it expires shortly
• You by no means handle certificates information or passwords
• Computerized renewal – you do not have to do something

However will not my signature break after 3 days?

No, evidently’s what timestamping is for. Whenever you signal a file:

1. Azure points a 3-day certificates
2. The file is signed with that certificates
3. A timestamp server data “this file was signed on DATE”
4. Even after the certificates expires, the signature stays legitimate as a result of the timestamp proves it was signed when the certificates was legitimate

That is why each native and GitHub Actions signing embrace:

timestamp-rfc3161: http://timestamp.acs.microsoft.com

What the Certificates Accommodates

Your signed executable has a certificates with:

• Topic: Your title (e.g., “CN=John Doe, O=John Doe, L=Seattle, S=Washington, C=US”)
• Issuer: Microsoft ID Verified CS EOC CA 01
• Legitimate Dates: 3-day window
• Key Dimension: 3072-bit RSA (very safe)
• Enhanced Key Utilization: Code Signing

Confirm Certificates on Any Machine

# Utilizing PowerShell
Get-AuthenticodeSignature "MyApp.exe" | Choose-Object -ExpandProperty SignerCertificate | Format-Record

# Utilizing Home windows UI
# Proper-click EXE → Properties → Digital Signatures tab → Particulars → View Certificates

This entire factor took me about an hour to 75 minutes. It was detailed, however not deeply troublesome. Misspellings, case-sensitivity, and some account points with Position-Based mostly Entry Management did gradual me down. Hope this helps!

Used Assets

Written in November 2025 primarily based on real-world implementation for WindowsEdgeLight. Your setup may differ barely relying on Azure area and account kind. Issues change, be stoic.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, advisor, father, diabetic, and Microsoft worker. He’s a failed stand-up comedian, a cornrower, and a e book writer.

About   E-newsletter

Internet hosting By