Microsoft's New NuGet Signing Certificate: Avoid NU3034 Failures

Microsoft announced that a new certificate becomes the default for author-signing its NuGet packages "as soon as September 23, 2026." After the switch, the current certificate signs no new packages. Existing packages keep their signatures.

Most .NET teams don't need to do anything. But teams that enforce a trusted signers allow list, or verify Microsoft's signature by fingerprint in CI, must add the new fingerprint. If they don't, restoring a package signed with the new certificate fails with error NU3034.

What's affected

Only two setups, according to Microsoft's post:

1. Client trust policy. A nuget.config with signatureValidationMode set to require and a trustedSigners section that includes Microsoft as an author.
2. Fingerprint verification. Scripts or pipelines that run dotnet nuget verify with explicit --certificate-fingerprint values for Microsoft.

The fingerprints (SHA-256):

The post is explicit: add the new fingerprint without removing the older ones. Packages already signed with older certificates still need them to validate.

How to check if you're exposed

Find every NuGet config that enforces signers. Remember that configs stack: repository, user and machine level.

# Repository level
grep -rlnE "signatureValidationMode|trustedSigners" --include=nuget.config --include=NuGet.Config .

# User level
grep -nE "signatureValidationMode|trustedSigners" ~/.nuget/NuGet/NuGet.Config 2>/dev/null

# User level on Windows
Select-String -Path "$env:APPDATA\NuGet\NuGet.Config" -Pattern "signatureValidationMode|trustedSigners"

If you find signatureValidationMode set to require, open the trustedSigners block and look for the Microsoft author entry. If 9A1B131B... isn't listed, you're exposed.

Then search pipelines and scripts for fingerprint checks:

grep -rnE "nuget verify.*certificate-fingerprint" .github/ .azure-pipelines/ build/ scripts/ 2>/dev/null

To see which certificate a package was actually signed with, run verify without fingerprints and read the output:

dotnet nuget verify --all path/to/package.nupkg

What to do now

1. Add the new fingerprint to your client policy. Microsoft's command (requires .NET 6 SDK or later):

   dotnet nuget trust author Microsoft 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 --algorithm SHA256
   

   Add --configfile path/to/nuget.config to target a specific file. Or add the entry by hand to the existing Microsoft author block:

   <certificate fingerprint="9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630" hashAlgorithm="SHA256" allowUntrustedRoot="false" />
   

2. Update fingerprint checks in CI. Keep all older fingerprints and add the new one:

   dotnet nuget verify path/to/package.nupkg \
     --certificate-fingerprint 3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE \
     --certificate-fingerprint AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27 \
     --certificate-fingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353 \
     --certificate-fingerprint 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630
   

3. Update golden images and build agents that carry a machine-level NuGet.Config. A fixed repository config won't help if a machine-level file still enforces the old list.
4. Copy the fingerprint from Microsoft's post, not from a forum or a teammate's message. A trust anchor should come from the publisher.
5. Don't fix NU3034 by switching to accept mode. That turns off the check you set up deliberately.

Why it matters

Pinning signer fingerprints is one of the stronger controls a .NET team can apply. It means a package that claims to be from Microsoft but isn't signed by Microsoft's certificate doesn't restore. The cost is that every rotation on the publisher's side becomes a change on yours, and teams that set the policy years ago often forget it exists until builds fail.

That failure mode is worth planning for. When a restore breaks with a signature error, the fastest "fix" is to relax validation. A short runbook that says "check the publisher's announced fingerprints, add the new one, keep the old ones" keeps the control in place. Rotation notices from the vendors you pin are worth subscribing to.

Try it yourself

Pick one Microsoft package your solution restores, such as a recent Microsoft.Extensions.* version, and run dotnet nuget verify --all on the .nupkg in your global packages folder. Note the author certificate fingerprint it reports, then check which of the four fingerprints above it matches. Repeat after a package update to see when the new certificate shows up.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Microsoft is updating its author-signing certificate starting September 23, 2026 (.NET Blog)
• NuGet docs: Manage package trust boundaries
• NuGet docs: dotnet nuget verify