NuGet Trusted Signers: Fixing NU3034 After a Certificate Rotation

What does NU3034 actually mean?

NU3034 is NuGet telling you that a signature exists and does not appear on the list of signatures you said you would accept. It is not a broken package, a corrupted download or an expired certificate — those have their own codes. It fires only where somebody deliberately configured an allow list, which is why most .NET projects have never seen it.

Microsoft groups four messages under the single code, and it helps to know which one you got before you change anything:

Only the second one is fixed by editing a fingerprint. The other three are worth reading carefully before anybody starts pasting hashes into a config file.

What changed on 23 September 2026

Microsoft moved to a new author-signing certificate for the NuGet packages it publishes. From that date the new certificate signs new packages; everything published earlier keeps the signature it already has. Nothing was revoked and nothing expired early. If you never configured a client policy, restore behaves exactly as it did the week before, because NuGet accepts all authors and repositories unless told otherwise.

Two groups notice. The first pinned Microsoft in a trustedSigners section, usually alongside signatureValidationMode set to require. The second calls dotnet nuget verify with explicit --certificate-fingerprint arguments in a pipeline step. Both compare against a fixed list, and both hit a fingerprint that has never been on it.

This is the second time Microsoft has announced a rotation of this certificate in recent years — the previous notice covered a change in August 2023 — and the pattern is visible in Microsoft's own documentation, where the example microsoft author entry already carried three fingerprints before this one. That accumulation is the correct end state, not clutter.

Add the new fingerprint, keep the old ones

The repair is one line of configuration, and the important part is what you do not touch. Append the incoming fingerprint to the existing microsoft author entry and leave the previous three in place. A NuGet package carries the signature it was given at publish time forever, so dropping an old fingerprint means every package signed under it stops validating.

Either edit the config directly:

<trustedSigners>
  <author name="microsoft">
    <!-- keep every fingerprint you already had -->
    <certificate fingerprint="3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE"
                 hashAlgorithm="SHA256" allowUntrustedRoot="false" />
    <certificate fingerprint="AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27"
                 hashAlgorithm="SHA256" allowUntrustedRoot="false" />
    <certificate fingerprint="566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353"
                 hashAlgorithm="SHA256" allowUntrustedRoot="false" />
    <!-- and add the one in use from 23 September 2026 -->
    <certificate fingerprint="9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630"
                 hashAlgorithm="SHA256" allowUntrustedRoot="false" />
  </author>
</trustedSigners>

Or let the CLI append it for you. The subcommand you want is certificate, not author: when a trusted signer with that name already exists, the certificate item is added to it rather than replacing anything.

dotnet nuget trust certificate microsoft \
  9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 \
  --algorithm SHA256

# on Windows with nuget.exe
nuget trusted-signers Add -Name microsoft \
  -CertificateFingerprint 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 \
  -FingerprintAlgorithm SHA256

# confirm the entry now holds four fingerprints
dotnet nuget trust list

One gotcha that costs people ten minutes: dotnet nuget trust author does not take a fingerprint. Its second argument is a local path to a signed .nupkg, and it reads the certificate out of that file. dotnet nuget trust certificate is the one that takes a hash. They both end up writing an <author> element, which is where the confusion comes from.

Do the same for any pipeline step that passes --certificate-fingerprint to dotnet nuget verify. That option can be supplied more than once, so pass all four rather than swapping one for another.

Why deleting trustedSigners makes the error vanish

Because it switches the check off. NuGet's signatureValidationMode defaults to accept, and in that mode the documentation is blunt: packages signed with untrusted certificates are treated as unsigned and install without any warning or error. An allow list only blocks anything when the mode is require, which is also the mode that refuses to run with an empty list. Remove the section, and a red build turns green while the guarantee you were buying disappears with it.

This is worth checking even if you did not touch anything. Plenty of repositories carry a trustedSigners section that somebody added years ago without ever setting signatureValidationMode. Those projects have been sitting in the top-left cell the whole time — the list is there, it looks like policy in a code review, and nothing has ever been enforced. A rotation is a good moment to find out which cell you are actually in:

# who do I currently trust, and with which fingerprints?
dotnet nuget trust list

# is the check actually switched on? an absent key means the default, accept
grep -r "signatureValidationMode" nuget.config NuGet.config 2>/dev/null

If the honest answer is that nobody meant to enforce anything, say so and remove the section deliberately. That is a defensible position. Leaving a list in place that no tool consults is the one outcome with no upside.

Author trust has no sync. Repository trust does.

NuGet lets you trust two different things, and only one of them can repair itself. A trusted repository is identified by a service index URL, and a repository publishes its current signing certificates there; dotnet nuget trust sync fetches that list and replaces what you stored. A trusted author is identified by nothing but fingerprints. There is no endpoint behind a publisher to ask, so there is nothing to sync.

Microsoft is trusted as an author, which is why its rotation reaches consumers as a failed restore rather than as a background refresh. It also explains why the advice is always "add the fingerprint" and never "run sync". Note the destructive edge on sync too: the documentation describes it as deleting the current list and replacing it with the repository's. That is fine for a feed that publishes its full history, and it is not something to reach for casually.

If your private feed repository-signs everything it serves, trusting the repository rather than each author is the lower maintenance choice — one entry, refreshable on demand, and it keeps working when a supplier rotates. You can narrow it further with an <owners> list so that only packages submitted by named accounts pass.

Why CI failed and your laptop did not

Signature verification during restore is not on everywhere. Windows always performs it and uses the system root store. On Linux it was off by default until the .NET 8 SDK, where it became on by default, with the DOTNET_NUGET_SIGNATURE_VERIFICATION environment variable flipping it either way. On macOS it is off by default during restore, and Microsoft's own guidance is to leave it that way.

So a team on macOS laptops building into Linux containers on the .NET 8 SDK or later gets a clean local restore and a failing pipeline from an identical checkout. Nobody changed anything; the check simply runs in one place and not the other. Before you start bisecting commits, confirm where verification is actually enabled.

The same asymmetry cuts the other way, and it is the more serious half. If your only enforcement is on a platform where verification is off, your allow list has never blocked a single package. Treat the build agent as the place the policy lives and the laptop as the place it is merely declared.

Read the fingerprint off a package

A fingerprint copied from a web page is only as trustworthy as the page — including this one. The point of pinning is to remove that dependency, so derive the value from a package you already have and use any published hash as a cross-check rather than as the source. It costs one command.

# read the signature details, including the certificate SHA-256
dotnet nuget verify ./Microsoft.Extensions.Logging.9.0.0.nupkg --verbosity detailed

# or let the CLI write the entry straight from the package
dotnet nuget trust author microsoft ./Microsoft.Extensions.Logging.9.0.0.nupkg

Use a package you fetched before the change for an old fingerprint and one published after it for the new one. If the value you read matches what the announcement published, you have two independent sources agreeing and you can commit the config with a clear conscience. If it does not, you have learned something considerably more important than a build fix.

Keep allowUntrustedRoot at false while you are in there. Setting it to true tells NuGet to accept a certificate that does not chain to a trusted root, which throws away the part of the check that the fingerprint does not cover. The documentation flags it as not recommended, and it tends to appear in configs as a leftover from somebody testing with a self-signed certificate.

If you sign packages, you are next

Everything above describes being on the receiving end. If you publish signed packages and anyone downstream pins you, you will hand them the same breakage — and under the current rules you will do it far more often than Microsoft just did. Certificates issued on or after 1 March 2026 are capped at 460 days under CA/Browser Forum ballot CSC-31, down from the old 39-month maximum.

Three practical consequences. Publish the incoming fingerprint before you start signing with it, so consumers can add it ahead of the first package that needs it. Say plainly that old fingerprints stay valid, because the instinct is to swap rather than append. And keep a dated list somewhere durable — release notes, a documentation page, anywhere that is not a blog post that scrolls away.

Renewal itself is the other half of the planning. A 460-day certificate means a renewal cycle that now lands inside most annual budget and audit rhythms rather than outside them, and the hardware key requirement in force since June 2023 means the new key is generated fresh in a token, HSM or cloud signing service rather than copied from the old one. Our guide to OV and EV code signing certificates and how they are delivered covers which delivery model survives an unattended CI pipeline, which matters a great deal more once you are doing this every fifteen months.

For the mechanics of producing a signed package in the first place — the .nupkg, the timestamp server, the token or cloud key — see how to sign a NuGet package. This article is the view from the consumer's side of that same signature.