Article
Microsoft NuGet certificate rotation: update CI trust while keeping older certificates
Microsoft announced a NuGet author-signing certificate transition starting September 23, 2026. Environments enforcing signer allow lists or certificate fingerprint checks need to add the new certificate while retaining older ones.
Share
Koharu's reading tip
Find where your tooling specifies certificate fingerprints to decide whether action is needed. Follow CI configuration and verification scripts so both old and new packages remain accepted.

A package can come from the same publisher yet need a change in your acceptance policy when its signing certificate changes. Environments that restrict who may sign Microsoft NuGet packages may now need that update.
Microsoft announced a transition to a new author-signing certificate starting September 23, 2026. For a CI maintainer, the practical questions are whether any configuration needs changing and whether older packages will still restore afterward.
The deciding factor is where you specify the Microsoft certificate. Following that policy through configuration files and verification scripts shows how to add the new certificate while keeping verification requirements intact.
Pinning an author certificate makes rotation relevant to restore
A NuGet author signature supports verification of package origin and detects changes made after signing. A repository signature is applied by a repository; nuget.org automatically repository-signs uploaded packages. The NuGet signed-package reference describes these separate roles.
This transition concerns the Microsoft author-signing certificate. A policy that trusts Microsoft by enumerating certificate fingerprints will not automatically recognize a different certificate.
The affected scenarios are NuGet client policies enforcing a trusted-signer allow list that includes Microsoft, and dotnet nuget verify commands that specify Microsoft certificate fingerprints. The announcement says environments using neither scenario should be unaffected.
The first place to look is therefore the package acceptance policy in your tooling.
Trace the configuration and scripts used by CI
In nuget.config, look for signatureValidationMode set to require and Microsoft certificates under an author entry in trustedSigners. This mode requires packages signed by trusted certificates, as described in Manage package trust boundaries.
Do not stop at the configuration file in your repository root. NuGet combines settings at computer, user, and solution scopes. Follow the configuration precedence rules through the CI account and any explicitly selected configuration file.
Also search build and distribution scripts for dotnet nuget verify and --certificate-fingerprint. Determine whether they enumerate only the older Microsoft certificates. If both configuration files and scripts specify certificates, both need attention.
Add the new Microsoft certificate while retaining older entries
Existing packages keep their older signatures after the transition. Add the new certificate while retaining the previous certificates, so the policy continues to accept those older packages.
For a direct configuration edit, insert the following certificate element into the existing Microsoft author entry under trustedSigners. This is only the element to add, not a replacement for the entire nuget.config file.
<certificate
fingerprint="9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630"
hashAlgorithm="SHA256"
allowUntrustedRoot="false" />
The SHA-256 fingerprint comes from the announcement. An author can contain multiple certificate elements, allowing the existing values to remain. The nuget.config reference documents the structure and attributes.
In verification scripts, retain the current --certificate-fingerprint arguments and append the new one. This example accepts the four old and new fingerprints listed in the announcement. Replace ./package.nupkg with the file to verify.
dotnet nuget verify "./package.nupkg" --certificate-fingerprint 3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE --certificate-fingerprint AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27 --certificate-fingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353 --certificate-fingerprint 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630
The dotnet nuget verify reference explains that repeating this option checks whether the signer certificate matches any of the supplied SHA-256 fingerprints. Keeping the older values preserves compatibility with previously signed packages.
Validate CI acceptance with both old and new signatures
After editing, test restore and verification with the same configuration as CI, using both a package signed with the new certificate and an older package you already consume. The output of dotnet nuget verify identifies author and repository signatures and their SHA-256 values, so select test packages by their actual signatures rather than publication date alone.
If a signature mismatch remains, compare the full error message against the effective allow list. The NU3034 reference covers several conditions, including a fingerprint mismatch and a missing allow list; the code alone does not establish the cause.
The need for action depends on whether your acceptance policy pins Microsoft certificates. In those environments, the update is complete when both old and new packages pass under the configuration CI actually uses. That lets certificate rotation proceed while preserving your policy for trusted signers.
Source
- Title: Microsoft is updating its author-signing certificate starting September 23, 2026
- URL: https://devblogs.microsoft.com/dotnet/microsoft-author-signing-certificate-update-2026/
Share
Related Articles
These articles share nearby categories or tags, so you can keep reading along the same thread.




