Trusted Signing profile "makologics" pinned to AOC CA 03 — SmartScreen warnings on every signed build

Russell Sailors 0 Reputation points
2026-04-18T15:30:16.24+00:00

Our Azure Trusted Signing certificate profile is being pinned to intermediate CA Microsoft ID Verified CS AOC CA 03 on every signing request. Because AOC CA 03 has no SmartScreen reputation yet, every binary we sign triggers "Windows protected your PC — unrecognized app" on first run, even though the signature validates cleanly against the Microsoft root. This is blocking our commercial Windows product from installing without a scary warning despite us paying for Trusted Signing specifically to avoid this.

This matches the public acknowledgment in the Microsoft community article "Azure Trusted Signing: new intermediate CAs causing SmartScreen warnings" (March 26, 2026 rollout of AOC CA 03 and EOC CA 04) and GitHub issue Azure/artifact-signing-action#128.

Environment

Item Value
Tenant Mako Logics LLC
-------- --------
Tenant Mako Logics LLC
Trusted Signing account makologics
Certificate profile makologics
Endpoint eus.codesigning.azure.net
Identity Validation status Completed (Public Trust)
Product Signed Windows installer (MakoBot, publisher "Mako Logics LLC")

Proof this is a CA-assignment issue, not a cert/profile issue

Same account, same profile, same signing pipeline — only the assigned intermediate CA differs between builds, and that's the only thing that correlates with SmartScreen behavior:

Build Signed on Intermediate CA assigned SmartScreen result
Build 79 2026-04-12 Microsoft ID Verified CS EOC CA 04 Clean, no warning
-------- -------- -------- --------
Build 79 2026-04-12 Microsoft ID Verified CS EOC CA 04 Clean, no warning
Build 80 2026-04-17 Microsoft ID Verified CS AOC CA 03 "Unrecognized app" warning

Both builds:

  • Signed via the same signtool.exe invocation with Azure.CodeSigning.Dlib
  • Pass signtool verify /pa /v end-to-end against the Microsoft root
  • Display Mako Logics LLC correctly as the publisher in the SmartScreen "More info" dialog
  • Countersigned by timestamp.acs.microsoft.com

What I already tried

  • Re-signed Build 80 four consecutive times hoping Trusted Signing would roll a different intermediate CA. All four attempts returned AOC CA 03. The profile-to-CA mapping appears server-pinned once migrated.
  • Reviewed signing-tools/metadata.json — the metadata schema exposes Endpoint, CodeSigningAccountName, and CertificateProfileName but has no CA selection field, so this isn't something the client can steer.
  • Filed a Microsoft Defender SmartScreen false-positive review via wdsi/filesubmission for Build 80's specific file hash. The SmartScreen team replied with standard "reputation will build over time" boilerplate — which is exactly what Trusted Signing is supposed to prevent. And every future build needs its own individual submission until the underlying CA mapping is fixed, which isn't sustainable.

Ask

Please move the makologics certificate profile off Microsoft ID Verified CS AOC CA 03 and onto Microsoft ID Verified CS EOC CA 04 (the CA that worked in Build 79 and has established SmartScreen reputation). Same account, same profile, same identity — just the CA assignment needs to change server-side.

If moving the profile isn't possible, please advise on:

  1. Any client-side setting that would let us steer which intermediate CA is used per signing request, or
  2. An ETA on when AOC CA 03 will have enough SmartScreen reputation for signed binaries to stop triggering warnings, or
  3. An alternate remediation path

This is blocking a shipping product from installing cleanly for end users. Happy to provide the Build 80 file hash, signed installer sample, or any additional account identifiers privately if needed.

Thanks.Our Azure Trusted Signing certificate profile is being pinned to intermediate CA Microsoft ID Verified CS AOC CA 03 on every signing request. Because AOC CA 03 has no SmartScreen reputation yet, every binary we sign triggers "Windows protected your PC — unrecognized app" on first run, even though the signature validates cleanly against the Microsoft root. This is blocking our commercial Windows product from installing without a scary warning despite us paying for Trusted Signing specifically to avoid this.

This matches the public acknowledgment in the Microsoft community article "Azure Trusted Signing: new intermediate CAs causing SmartScreen warnings" (March 26, 2026 rollout of AOC CA 03 and EOC CA 04) and GitHub issue Azure/artifact-signing-action#128.

Environment

Item Value
Tenant Mako Logics LLC
Trusted Signing account makologics
Certificate profile makologics
Endpoint eus.codesigning.azure.net
Identity Validation status Completed (Public Trust)
Product Signed Windows installer (MakoBot, publisher "Mako Logics LLC")

Proof this is a CA-assignment issue, not a cert/profile issue

Same account, same profile, same signing pipeline — only the assigned intermediate CA differs between builds, and that's the only thing that correlates with SmartScreen behavior:

Build Signed on Intermediate CA assigned SmartScreen result
Build 79 2026-04-12 Microsoft ID Verified CS EOC CA 04 Clean, no warning
Build 80 2026-04-17 Microsoft ID Verified CS AOC CA 03 "Unrecognized app" warning

Both builds:

  • Signed via the same signtool.exe invocation with Azure.CodeSigning.Dlib
  • Pass signtool verify /pa /v end-to-end against the Microsoft root
  • Display Mako Logics LLC correctly as the publisher in the SmartScreen "More info" dialog
  • Countersigned by timestamp.acs.microsoft.com

What I already tried

  • Re-signed Build 80 four consecutive times hoping Trusted Signing would roll a different intermediate CA. All four attempts returned AOC CA 03. The profile-to-CA mapping appears server-pinned once migrated.
  • Reviewed signing-tools/metadata.json — the metadata schema exposes Endpoint, CodeSigningAccountName, and CertificateProfileName but has no CA selection field, so this isn't something the client can steer.
  • Filed a Microsoft Defender SmartScreen false-positive review via wdsi/filesubmission for Build 80's specific file hash. The SmartScreen team replied with standard "reputation will build over time" boilerplate — which is exactly what Trusted Signing is supposed to prevent. And every future build needs its own individual submission until the underlying CA mapping is fixed, which isn't sustainable.

Ask

Please move the makologics certificate profile off Microsoft ID Verified CS AOC CA 03 and onto Microsoft ID Verified CS EOC CA 04 (the CA that worked in Build 79 and has established SmartScreen reputation). Same account, same profile, same identity — just the CA assignment needs to change server-side.

If moving the profile isn't possible, please advise on:

  1. Any client-side setting that would let us steer which intermediate CA is used per signing request, or
  2. An ETA on when AOC CA 03 will have enough SmartScreen reputation for signed binaries to stop triggering warnings, or
  3. An alternate remediation path

This is blocking a shipping product from installing cleanly for end users. Happy to provide the Build 80 file hash, signed installer sample, or any additional account identifiers privately if needed.

Thanks.

Artifact Signing
Artifact Signing

A fully managed end-to-end service for digitally signing code, documents, and applications. (formerly Trusted Signing)

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-04-18T15:30:44.8733333+00:00

    SmartScreen reputation is currently based on the file hash and accumulated download/usage history, not on a guarantee of instant trust from any specific certificate, CA, or from Azure Artifact Signing/Trusted Signing.

    From the current SmartScreen behavior:

    • All non‑Store distribution methods (including Azure Artifact Signing / Trusted Signing, OV, and EV certificates) start with warnings for new files until reputation builds.
    • EV certificates no longer bypass SmartScreen; they behave the same as OV and Trusted Signing for new binaries.
    • Reputation is per file hash; each new build starts with no SmartScreen reputation, even if signed with the same publisher identity and CA.
    • There is no supported mechanism for developers to force or steer SmartScreen reputation, and no documented way to choose or switch the intermediate CA used by Azure Artifact Signing.

    Specifically, current documented behavior is:

    • Azure Artifact Signing (Trusted Signing) is recommended for non‑Store distribution and has SmartScreen behavior equivalent to OV certificates: reputation accumulates over time based on download volume, and first‑download warnings are expected for new files.
    • There is no published API, metadata field, or client‑side option to select a particular intermediate CA or to move a profile between CAs.
    • There is no documented way to manually submit files for SmartScreen reputation review that affects consumer SmartScreen behavior; reputation builds organically through usage. Enterprise admins can submit files via the Microsoft Security Intelligence portal, but that only affects managed/enterprise environments.

    Given the available information, the following are the supported options:

    1. Accept initial SmartScreen warnings while reputation builds
      • Continue signing all releases with the same Trusted Signing profile so that publisher identity remains consistent.
      • As downloads accumulate (typically over several weeks and hundreds of clean installs), SmartScreen warnings for that specific file hash should stop.
    2. Use Microsoft Store distribution where feasible
      • Apps distributed via Microsoft Store are re‑signed by Microsoft and carry full SmartScreen reputation; users do not see SmartScreen warnings for Store‑installed apps.
    3. Enterprise environments only
      • For managed devices, IT admins can:
        • Submit files for review via the Microsoft Security Intelligence portal to accelerate trust for internal deployments.
        • Configure Microsoft Defender for Endpoint or Windows Defender Application Control (Application Control for Business/WDAC) policies to allowlist specific publisher certificates or file hashes, bypassing SmartScreen checks on managed endpoints.

    The context does not document any supported way to:

    • Reassign a specific Trusted Signing certificate profile from one Microsoft intermediate CA to another (for example, from Microsoft ID Verified CS AOC CA 03 to Microsoft ID Verified CS EOC CA 04).
    • Control intermediate CA selection from the client side.
    • Obtain an ETA for when a particular intermediate CA will have sufficient SmartScreen reputation.

    For a blocking commercial scenario, the documented remediation paths are therefore limited to:

    • Continue using Trusted Signing and allow SmartScreen reputation to build organically per file hash.
    • Prefer Microsoft Store distribution to avoid SmartScreen warnings entirely.
    • For enterprise customers, use security portal submissions and/or WDAC/Application Control for Business policies to trust the signed binaries in managed environments.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.