Mac Tahoe (in Beta as of the time of this writing) has this new function known as Edge Gentle that mainly places a brilliant image of an Edge Gentle round your display and mainly makes use of the ability of OLED to present you a digital ring gentle. 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 will get the most recent launch right here https://github.com/shanselman/WindowsEdgeLight/releases or the app will test for brand new releases and autoupdate with Updatum).
Nonetheless, as is with all suss free executables on the web, whenever you run random stuff you may typically get the Window Defender ‘new telephone, who dis’ warning which is frightening. After a number of downloads and no viruses or complaints, my executable will finally acquire status with the Home windows Defender Good Display screen service, however having a Code Signing Certificates is claimed to assist with that. Nonetheless, code signing certs are costly and a trouble to handle and renew.
Somebody advised me that Azure Trusted Signing was considerably much less of a trouble – it is much less, nevertheless it’s nonetheless non-trivial. I learn this submit 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 submit, however since I simply spent an hour getting code signing to work and GitHub Copilot was going by means of and logging all the things 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 components I did not like, so any errors are mine.
Azure Trusted Signing is Microsoft’s cloud-based code signing service that:
- No {hardware} tokens – All the pieces 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 tasks. I would really like it if this have been $10 a 12 months. That is cheaper than a yearly cert, nevertheless it’ll add up after some time so I am all the time searching for cheaper/simpler choices.
- Trusted by Home windows – Makes use of the identical certificates authority as Microsoft’s personal apps, so it’s best to get your EXE trusted quicker
Stipulations
Earlier than beginning, you may want:
- Azure subscription
- Azure CLI – Set up from right here
- Id validation paperwork – Driver’s license or passport for particular person builders. Word that I am within the US, so your mileage could fluctuate however I mainly arrange the account, scanned a QR code, took an image of my license, then did a selfie, then waited.
- Home windows PC – For native signing (non-compulsory) however I ended up utilizing the dotnet signal instrument. There are
- GitHub repository – For automated signing (non-compulsory)
Half 1: Setting Up Azure Trusted Signing
Step 1: Register the Useful resource Supplier
First, I have to allow the Azure Trusted Signing service in my subscription. This may be performed 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
# Await registration to finish (takes 2-3 minutes)
az supplier present --namespace Microsoft.CodeSigning --query "registrationState"
Wait till the output reveals "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.
Choice A: Azure Portal (Simpler for first-timers)
- Go to Azure Portal
- Seek for “Trusted Signing Accounts”
- Click on Create
- Fill in:
- Subscription: Your subscription
- Useful resource Group: Create new or use current (e.g., “MyAppSigning”)
- Account Identify: A novel identify (e.g., “myapp-signing”)
- Area: Select closest to you (e.g., “West US 2”)
- SKU: Primary (ample for many apps)
- Click on Assessment + Create, then Create
Choice B: Azure CLI (Sooner in case you are a CLI particular person 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
Necessary: Word your area endpoint. Widespread ones are:
- East US:
https://eus.codesigning.azure.web/ - West US 2:
https://wus2.codesigning.azure.web/ - Your particular area: Test in Azure Portal underneath your account’s Overview web page
I completely flaked on this and messed round for 10 min earlier than I noticed that this URL issues and is particular to your account. Keep in mind this endpoint.
Step 3: Full Id Validation
That is an important step. Microsoft must confirm you are an actual particular person/group.
- In Azure Portal, go to your Trusted Signing Account
- Click on Id validation within the left menu
- Click on Add identification validation
- Select validation sort:
- Particular person: For solo builders (makes use of driver’s license/passport)
- Group: For firms (makes use of enterprise registration paperwork)
- For Particular person validation:
- Add a transparent picture of your government-issued ID
- Present your full authorized identify (should match ID precisely)
- Present your e-mail deal with
- Submit and look ahead to 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 people with limitless Azure credit, I pay for my very own) so that they did not comprehend it was me. I went by means of 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.
- In your Trusted Signing Account, click on Certificates profiles
- Click on Add certificates profile
- Fill in:
- Profile identify: Descriptive identify (e.g., “MyAppProfile”)
- Profile sort: Select Public Belief (required to stop SmartScreen)
- Id validation: Choose your accepted identification
- Certificates sort: Code Signing
- Click on Add
Necessary: Solely “Public Belief” profiles forestall SmartScreen warnings. “Personal Belief” is for inside apps solely. This took me a second to appreciate additionally as it is not an intuitive identify.
Step 5: Confirm Your Setup
# Checklist 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.web/(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 domestically 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 have to mess with any certificates.
Step 1: Assign Your self the Signing Position
You want permission to really use the signing service.
Choice A: Azure Portal
- Go to your Trusted Signing Account
- Click on Entry management (IAM)
- Click on Add → Add function project
- Seek for and choose Trusted Signing Certificates Profile Signer. That is necessary. I looked for “code” and located nothing. Seek for “Trusted”
- Click on Subsequent
- Click on Choose members and discover your person account
- Click on Choose, then Assessment + assign
Choice B: Azure CLI
# Get your person object ID
$userId = az advert signed-in-user present --query id -o tsv
# Assign the function
az function project create
--role "Trusted Signing Certificates Profile Signer"
--assignee-object-id $userId
--scope /subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/MyAppSigning/suppliers/Microsoft.CodeSigning/codeSigningAccounts/myapp-signing
Change YOUR_SUBSCRIPTION_ID along with your precise subscription ID.
Step 2: Login with the Right Scope
That is essential – it’s essential 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.web/.default"
This offers you a code to enter at https://microsoft.com/devicelogin. Comply with the prompts.
Why gadget code movement? As a result of Azure CLI’s default authentication can battle with Visible Studio credentials in my expertise. Machine code movement is extra dependable for code signing.
Step 3: Obtain the Signal Software
Choice A: Set up Globally (Really useful for normal use)
# Set up as a worldwide instrument (obtainable in every single place)
dotnet instrument set up --global --prerelease signal
# Confirm set up
signal --version
Choice B: Set up Regionally (Mission-specific)
# Set up to present listing
dotnet instrument set up --tool-path . --prerelease signal
# Use with .signal.exe
Which ought to I take advantage of?
- International: Should you’ll signal a number of tasks or signal continuously
- Native: If you wish to preserve the instrument with a selected mission or don’t need it in your PATH
Step 4: Signal Your Executable
Word once more that code signing URL is particular to you. The tscp is your Trusted Signing Certificates Profile identify and the tsa is your Trusted Signing Account identify. I set *.exe to signal all of the EXEs within the folder and word that the -b base listing is an absolute path, not a relative one. For me it was d:githubWindowsEdgeLightpublish, and your mileage will fluctuate.
# Navigate to your mission folder
cd C:MyProject
# Signal the executable
.signal.exe code trusted-signing `
-b "C:MyProjectpublish" `
-tse "https://wus2.codesigning.azure.web" `
-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 identify-tsa: Trusted Signing account identify*.exe: Sample to match information to signal-v: Verbosity stage (Hint, Data, Warning, Error)
Anticipated output:
data: Signing WindowsEdgeLight.exe succeeded.
Accomplished in 2743 ms.
Step 5: Confirm the Signature
You are able to do this in PowerShell:
# Test the signature
Get-AuthenticodeSignature ".publishMyApp.exe" | Format-Checklist
# 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”
Widespread Native Signing Points
I hit all of those lol
Subject: “Please run ‘az login’ to arrange account”
- Trigger: Not logged in with the fitting scope
- Repair: Run
az logoutthenaz login --use-device-code --scope "https://codesigning.azure.web/.default"
Subject: “403 Forbidden”
- Trigger: Fallacious endpoint, account identify, or lacking permissions
- Repair:
- Confirm endpoint matches your area (wus2, eus, and so forth.)
- Confirm account identify is actual (case-sensitive)
- Confirm you’ve “Trusted Signing Certificates Profile Signer” function
Subject: “Consumer account doesn’t exist in tenant”
- Trigger: Azure CLI attempting to make use of Visible Studio credentials
- Repair: Use gadget code movement (see Step 2)
Half 3: Automated Signing with GitHub Actions
That is the place the magic occurs. I need to robotically signal each launch. I am utilizing GitVersion so I simply have to 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.
Necessary: You want Proprietor or Consumer Entry Administrator function in your subscription to do that. If you do not have it, ask your Azure admin or a buddy.
# 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 necessary.
Different: Azure Portal Technique
If CLI would not work:
- Azure Portal → App registrations → New registration
- Identify: “MyAppGitHubActions”
- Click on Register
- Copy the Software (shopper) ID – that is
AZURE_CLIENT_ID - Copy the Listing (tenant) ID – that is
AZURE_TENANT_ID - Go to Certificates & secrets and techniques → New shopper secret
- Description: “GitHub Actions”
- Expiration: 24 months (max)
- Click on Add and instantly copy the Worth – that is
AZURE_CLIENT_SECRET - Go to your Trusted Signing Account → Entry management (IAM)
- Add function project → Trusted Signing Certificates Profile Signer
- Choose members → Seek for “MyAppGitHubActions”
- Assessment + assign
Step 2: Add GitHub Secrets and techniques
Go to your GitHub repository:
- Settings → Secrets and techniques and variables → Actions
- Click on New repository secret for every:
AZURE_CLIENT_ID– From service principal output or App registrationAZURE_CLIENT_SECRET -From service principal output or Certificates & secrets and techniquesAZURE_TENANT_ID– From service principal output or App registrationAZURE_SUBSCRIPTION_ID– Azure Portal → Subscriptions
Safety Word: 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
This can be a little complicated because it’s YAML, which is Devil’s markup, nevertheless it’s what we’ve sunk to as a society.
Word the dotnet-version under. Yours could be 8 or 9, and so forth. Additionally, I’m constructing each x64 and ARM variations and I’m utilizing GitVersion so if you’d like a extra full construct.yml, you may 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 free EXE lives in a ZIP file.
Add signing steps to your .github/workflows/construct.yml:
identify: Construct and Signal
on:
push:
tags:
- 'v*'
workflow_dispatch:
permissions:
contents: write
jobs:
construct:
runs-on: windows-latest
steps:
- identify: Checkout code
makes use of: actions/checkout@v4
with:
fetch-depth: 0
- identify: Setup .NET
makes use of: actions/setup-dotnet@v4
with:
dotnet-version: '10.0.x'
- identify: Restore dependencies
run: dotnet restore MyApp/MyApp.csproj
- identify: Construct
run: |
dotnet publish MyApp/MyApp.csproj `
-c Launch `
-r win-x64 `
--self-contained
# === SIGNING STEPS START HERE ===
- identify: 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 }}"}'
- identify: 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.web/
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 ===
- identify: 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 forth.)trusted-signing-account-name: Your account identify (actual, case-sensitive)certificate-profile-name: Your certificates profile identify (actual, case-sensitive)files-folder: Path to your compiled executablesfiles-folder-filter: File sorts to signal (exe, dll, and so forth.)files-folder-recurse: Signal information in subfolders
Step 4: Take a look at the Workflow
Now set off the workflow. You’ve got two choices:
Choice A: Guide Set off (Most secure for testing)
Because the workflow consists of workflow_dispatch:, you may 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 net 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
Choice B: Create a Tag (For precise releases)
# Be sure you're in your foremost department with no uncommitted adjustments
git standing
# Create and push a tag
git tag v1.0.0
git push origin v1.0.0
Use this whenever you’re able to create an precise launch with signed binaries. That is what I’m doing on my aspect.
Step 5: Monitor the Construct
Watch the progress with GitHub CLI:
# See newest runs
gh run listing --limit 5
# Watch a selected 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 obtainable in /releases in your GitHib mission
Widespread GitHub Actions Points
I hit a number of of those, natch.
Subject: “403 Forbidden” throughout signing
- Trigger: Service principal would not have permissions
- Repair:
- Go to Azure Portal → Trusted Signing Account → Entry management (IAM)
- Confirm “MyAppGitHubActions” has “Trusted Signing Certificates Profile Signer” function
- If not, add it manually
Subject: “No information matched the sample”
- Trigger: Fallacious
files-folderpath or construct artifacts in flawed location - Repair:
- Add a debug step earlier than signing:
- run: Get-ChildItem -Recurse - Discover the place your EXE is definitely situated
- Replace
files-folderto match
- Add a debug step earlier than signing:
Subject: Secrets and techniques not working
- Trigger: Typo in secret identify or worth not saved
- Repair:
- Confirm secret names EXACTLY match (case-sensitive)
- Re-create secrets and techniques if not sure
- Be certain that no further areas in values
Subject: “DefaultAzureCredential authentication failed”
- Trigger: Often flawed tenant ID or shopper 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 (usually 3 days). This freaked me out however they are saying that is truly a safety function:
- If a certificates is compromised, it expires rapidly
- 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:
- Azure points a 3-day certificates
- The file is signed with that certificates
- A timestamp server data “this file was signed on DATE”
- 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 Comprises
Your signed executable has a certificates with:
- Topic: Your identify (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-Checklist
# 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 tough. Misspellings, case-sensitivity, and some account points with Position-Primarily based Entry Management did gradual me down. Hope this helps!
Used Sources
Written in November 2025 primarily based on real-world implementation for WindowsEdgeLight. Your setup may fluctuate barely relying on Azure area and account sort. Issues change, be stoic.
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, guide, father, diabetic, and Microsoft worker. He’s a failed stand-up comedian, a cornrower, and a e book creator.

