NuGet Signing Certificate Rotated Sept 23: Fix NU3034 Now

Microsoft rotated its NuGet author-signing certificate on September 23. If your team enforces signing policies — signatureValidationMode=require or an explicit trustedSigners block in nuget.config — new Microsoft packages will now fail to install with a NU3034 error. The fix is a one-liner. But you have to run it.

Are You Affected?

Most teams are not. Standard NuGet installs, Restore commands, and builds with default settings will see no change — the certificate rotation is transparent to them.

You are affected if:

• Your nuget.config has signatureValidationMode set to require
• You have a trustedSigners section that lists Microsoft by certificate fingerprint
• Your CI pipeline runs dotnet nuget verify --certificate-fingerprint against Microsoft packages

Run a quick check against your repository:

grep -r "trustedSigners\|signatureValidationMode" . --include="*.config"

If that returns results from your nuget.config, read on.

What Breaks and What the Error Looks Like

Any Microsoft package released after September 23 carries the new certificate fingerprint. The moment your pipeline pulls in a freshly published version of a package like Microsoft.AspNetCore.App, Microsoft.Extensions.*, or any other Microsoft-signed package, the build will fail with:

error NU3034: Package 'Microsoft.SomePackage 10.x.x' from source 
'https://api.nuget.org/v3/index.json': The package signature 
certificate fingerprint does not match any certificate fingerprint 
in the allow list.

This is NU3034. It means the package is signed, but not by a certificate your policy recognizes. The package itself is legitimate — the signing key just changed.

The Fix

Option 1: CLI (fastest)

dotnet nuget trust author Microsoft \
  9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 \
  --algorithm SHA256

Add --configfile path/to/nuget.config if you need to target a specific config file rather than the user-level default.

Option 2: Edit nuget.config directly

If you manage a shared nuget.config checked into your repository, add the new fingerprint to the existing Microsoft author entry. Keep all existing fingerprints — packages signed with old certificates must still validate:

<trustedSigners>
    <author name="Microsoft">
        <certificate fingerprint="3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE"
                     hashAlgorithm="SHA256" allowUntrustedRoot="false" />
        <certificate fingerprint="AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27"
                     hashAlgorithm="SHA256" allowUntrustedRoot="false" />
        <certificate fingerprint="566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353"
                     hashAlgorithm="SHA256" allowUntrustedRoot="false" />
        <certificate fingerprint="9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630"
                     hashAlgorithm="SHA256" allowUntrustedRoot="false" />
    </author>
</trustedSigners>

Option 3: Update dotnet nuget verify scripts

If you run explicit verification steps in CI, add the new fingerprint alongside the existing ones:

dotnet nuget verify MyPackage.nupkg \
  --certificate-fingerprint 3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE \
  --certificate-fingerprint AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27 \
  --certificate-fingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353 \
  --certificate-fingerprint 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

Why This Happened

Standard certificate lifecycle. The old signing certificate was approaching the end of its validity period, so Microsoft rotated to a new one. Packages already signed with the old certificate remain valid and verifiable — their signatures do not expire with the cert rotation. Only new packages published after September 23 carry the new fingerprint.

This is the third time Microsoft has updated NuGet-related signing certificates in recent years. The pattern is consistent: certificate rotates, teams with strict policies hit NU3034, fix is a fingerprint addition. The maintenance burden is real but manageable — you should not disable trust policies because of this. See the official Microsoft announcement for the complete list of affected fingerprints.

The Broader Point

Somewhat ironically, this certificate rotation landed on the same day as the GHAPPIER npm attack, in which attackers weaponized npm’s Trusted Publishing mechanism to deliver a backdoor through signed packages. The opposite failure mode: a legitimate cert rotation breaking teams who took supply chain security seriously. Both events highlight the same underlying truth — package signing infrastructure is worth understanding, not just enabling and forgetting.

If you have no signing policies at all, now is a good time to consider adding them. NuGet’s require mode with a maintained trustedSigners list is a genuine defense against tampered packages. The full setup guide is in the NuGet package trust documentation. The maintenance cost is exactly what you just read: adding a fingerprint every few years.