Windows code signing: move from the USB token to a cloud signing service

[jozef2svrcek]

The Windows installer is currently unsigned — tauri.conf.json has no bundle.windows signing config and the release workflow has no signtool step (macOS, by contrast, is signed and notarized). Users see "unknown publisher" on install.

We own a USB code-signing token (used previously for Open Nettest / Windows Store), but it may have expired — worth checking before planning anything else.

Check the existing token first

Plug it in on Windows and run:

Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert |
  Format-List Subject, Issuer, NotBefore, NotAfter, Thumbprint

Code-signing certificates are capped at 39 months, so a token last used for Open Nettest is quite likely past NotAfter. Note that binaries signed while it was valid stay valid if they were timestamped — expiry only blocks new signatures.

Why the token can't sign in CI

GitHub-hosted runners are ephemeral VMs with no USB passthrough, so a physical token requires either:

• a self-hosted Windows runner with the token attached (machine always on; the real friction is PIN entry — depends on the vendor client's single-logon/cached-PIN mode), or
• manual signing after the CI build (download the draft's setup.exe, signtool sign /fd sha256 /tr <ts-url> /td sha256, re-upload). Zero infrastructure, but manual every release, and only the installer gets signed — the app binaries inside it would stay unsigned, since those must be signed before packaging.

Cloud signing (preferred)

A cloud-HSM signing service lets the existing GitHub-hosted runner sign unattended, and Tauri's bundle.windows.signCommand hook then covers both the app binaries and the NSIS installer in one build.

Option	Notes
Azure Trusted Signing	Cheapest (~$10/month). Requires organisation identity validation (a verifiable business-history minimum applied at launch — confirm current terms). Short-lived certs; azure/trusted-signing-action for CI.
SSL.com eSigner	Mid-price, EV available, cloud signing with automation support. Good fallback if Azure eligibility or region is a problem.
DigiCert KeyLocker	Enterprise pricing, solid CI story.
GlobalSign DSS / Certum	Alternatives worth quoting.

Also worth asking our current CA whether the existing certificate can be migrated to their cloud offering instead of buying new — several support this.

Expectation to set

Signing removes "unknown publisher" and shows the company name in the UAC prompt, but does not guarantee SmartScreen silence: reputation accrues per publisher identity, so an OV certificate may still trigger "Windows protected your PC" on early downloads until installs accumulate. EV certificates get immediate SmartScreen trust — relevant if the first-run experience matters more than the price difference.

Unrelated to this: Tauri's TAURI_SIGNING_PRIVATE_KEY signs update manifests, not the installer. Don't conflate the two.

Acceptance

• Existing token's validity established (expired or not)
• Signing route chosen (cloud service vs. self-hosted runner vs. manual)
• bundle.windows signing wired into tauri.conf.json + release workflow
• A published installer verifies clean: signtool verify /pa /v LPDO_x.y.z_x64-setup.exe

[jozef2svrcek]

Update after checking the options against our situation.

Open Nettest was published in 2022, so the token's certificate is almost certainly expired (39-month cap) — to be confirmed at the desk with the Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert command above. If so, we're buying/renewing regardless, which removes any reason to build infrastructure around the dongle.

We have an Azure tenant already, which makes Trusted Signing the natural first candidate. Two corrections to note, though:

• Trusted Signing does not issue EV certificates. It is OV-class public trust (Microsoft acts as the CA, short-lived certificates). If EV is a hard requirement, it has to be a traditional CA with a cloud HSM — SSL.com eSigner (cheapest EV), DigiCert KeyLocker, or Sectigo. Those are still USB-free and CI-friendly, just several hundred EUR/year instead of ~$10/month.
• Trusted Signing's compensating advantage: reputation attaches to the validated identity rather than the individual certificate, so the automatic certificate rotation does not reset accumulated SmartScreen reputation — which is the usual downside of short-lived certs.

Practical notes for the Trusted Signing route:

• Setup is a Trusted Signing account → identity validation (business documents, takes days, not minutes) → certificate profile → azure/trusted-signing-action in the release workflow.
• Authenticate the workflow with OIDC federated credentials rather than a client secret, so no long-lived credential lands in repository secrets.
• Confirm current region availability and the organisation-history requirement in the portal; both have shifted since launch.

Open decision: OV via Trusted Signing (cheap, integrated, reputation builds over time) vs. EV via a cloud CA (immediate SmartScreen trust, higher cost). Note that EV's "instant trust" is reportedly less absolute than it once was — worth verifying before paying the premium for that reason alone.