How to Update NuGet Trusted Signers for Microsoft's New Certificate

NuGet package signing gives .NET teams an additional way to verify the identity and integrity of packages used by an application.

For organizations that use strict trusted signer policies, a certificate change by a package publisher can require a configuration update. If the trusted signer policy still contains the previous certificate fingerprint, package restore may fail even though the package is from the expected publisher.

This situation is especially important in CI/CD environments because a developer machine may have a different NuGet configuration from the build server.

The safest approach is to verify the new certificate first, update the trusted signer configuration in a controlled way, and then test package restore before applying the change broadly.

This article explains how to update a NuGet trusted signer policy for a certificate change and how to validate the configuration afterward.

How NuGet Trusted Signers Work

NuGet trusted signers allow package consumers to define which package signatures they trust.

A simplified trust flow looks like this:

NuGet package
     |
     v
Package signature
     |
     v
Signing certificate
     |
     v
Trusted signer policy
     |
     v
Accept or reject

A trusted signer policy can identify a publisher or certificate.

For certificate-based trust, the configuration can contain a certificate fingerprint.

A simplified example looks like:

<configuration>
  <config>
    <add key="signatureValidationMode" value="require" />
  </config>

  <trustedSigners>
    <author name="ExamplePublisher">
      <certificate
        fingerprint="ABCDEF123456..."
        hashAlgorithm="SHA256"
        allowUntrustedRoot="false" />
    </author>
  </trustedSigners>
</configuration>

The values in a real configuration must correspond to the actual signing certificate and trust requirements used by your environment.

Why a Certificate Update Is Required

Suppose the current policy trusts:

Old certificate
Fingerprint: OLD123...

The publisher begins signing packages with:

New certificate
Fingerprint: NEW456...

Your existing configuration may still contain:

<certificate
    fingerprint="OLD123..."
    hashAlgorithm="SHA256" />

When NuGet validates the new package, the certificate does not match the trusted fingerprint.

The result can be a restore failure.

The problem can therefore be summarized as:

Package is valid
        +
Publisher is expected
        +
New certificate
        +
Old trusted fingerprint
        =
Trust policy mismatch

Before Updating the Certificate

Do not immediately replace the fingerprint.

A trusted signer configuration is a security control. Changing it means changing which signing identity your build accepts.

Before making the change, collect:

Package name
Package version
Current trusted signer
Current certificate fingerprint
New certificate fingerprint
Certificate subject
Certificate issuer
Certificate validity information
Package source
NuGet configuration used by the failing environment

The exact certificate details should come from a trusted verification process.

Step 1 - Find Your NuGet Configuration

Start by locating the NuGet.config file that controls your package restore.

A repository may contain:

NuGet.config

or:

nuget.config

You may also have user-level and machine-level NuGet configuration.

This matters because changing the wrong file can appear to have no effect.

For a repository-controlled build, keeping the relevant trust configuration with the source code can make the policy easier to review and reproduce.

Step 2 - Check the Current Trusted Signers

Open the configuration and locate:

<trustedSigners>

For example:

<trustedSigners>
  <author name="ExamplePublisher">
    <certificate
      fingerprint="OLD123456..."
      hashAlgorithm="SHA256"
      allowUntrustedRoot="false" />
  </author>
</trustedSigners>

Record the current fingerprint before changing anything.

It is useful to keep the old value available during troubleshooting so that the change can be reviewed accurately.

Step 3 - Confirm Signature Validation Mode

Check whether the configuration requires signature validation.

For example:

<config>
  <add key="signatureValidationMode" value="require" />
</config>

The exact policy used by your organization may differ.

The important point is to understand whether package signatures are required and how the trusted signer rules interact with that requirement.

Do not change validation mode simply to make the restore succeed.

If the goal is to maintain package-signing controls, the trust policy should be corrected instead.

Step 4 - Obtain the New Certificate Information

The next step is to identify the new signing certificate.

You need to determine:

Certificate subject
Certificate issuer
Certificate fingerprint
Hash algorithm
Certificate chain

The certificate fingerprint is particularly important for a fingerprint-based trusted signer entry.

For example:

Subject:
Example Publisher

Fingerprint:
NEW456789...

Do not use a fingerprint from an untrusted message, forum post, or copied configuration unless your organization's verification process has established that it is the correct certificate.

Step 5 - Verify the New Certificate

Before changing the policy, verify that the new certificate belongs to the expected package publisher.

A useful verification process is:

Identify the affected package.
Inspect its signature.
Identify the signing certificate.
Check the certificate identity.
Verify the certificate chain.
Calculate or confirm the fingerprint.
Compare it with trusted publisher information.
Have the change reviewed according to your security process.

This step protects against a dangerous mistake - adding an unexpected certificate simply because it makes package restore succeed.

Step 6 - Update the Fingerprint

After the new certificate has been verified, update the trusted signer entry.

Before:

<author name="ExamplePublisher">
  <certificate
    fingerprint="OLD123456..."
    hashAlgorithm="SHA256"
    allowUntrustedRoot="false" />
</author>

After:

<author name="ExamplePublisher">
  <certificate
    fingerprint="NEW456789..."
    hashAlgorithm="SHA256"
    allowUntrustedRoot="false" />
</author>

Only the certificate information that actually changed should be modified.

Avoid making unrelated changes to the NuGet configuration during the same migration.

When Should Both Certificates Be Trusted?

Certificate rotation can create a transition period.

For example:

Before rotation
    |
    v
Certificate A
    |
    v
Existing packages

During transition
    |
    +---- Certificate A
    |
    +---- Certificate B

After migration
    |
    v
Certificate B

If both old and new packages need to remain valid during the transition, your trust policy may need to recognize both certificates temporarily.

The exact configuration should be based on how the publisher is rotating certificates and how your organization handles package trust.

The old certificate should not remain trusted forever without a reason.

Once packages and build environments have moved to the new signing identity, remove obsolete trust entries according to your security policy.

Example of a Transition Configuration

Conceptually, a policy may contain more than one certificate for a trusted publisher:

<trustedSigners>
  <author name="ExamplePublisher">
    <certificate
      fingerprint="OLD123456..."
      hashAlgorithm="SHA256"
      allowUntrustedRoot="false" />

    <certificate
      fingerprint="NEW456789..."
      hashAlgorithm="SHA256"
      allowUntrustedRoot="false" />
  </author>
</trustedSigners>

Whether this is appropriate depends on the certificate rotation process and your trust requirements.

Do not add both certificates simply because a restore failure occurs.

There should be a defined reason for each trusted certificate.

Step 7 - Validate the Configuration

After updating the policy, restore the project.

For an SDK-style .NET project:

dotnet restore

Then build:

dotnet build --no-restore

And run tests:

dotnet test --no-build

A successful restore confirms that the expected package can pass the configured validation process.

It does not, by itself, prove that the policy is correctly restrictive.

Step 8 - Test an Unexpected Signer

A good security test should verify both sides of the policy.

You want this behavior:

Expected certificate
        |
        v
Accepted

Unexpected certificate
        |
        v
Rejected

If a configuration change causes all signed packages to be accepted regardless of their signing identity, the policy may have been weakened.

The exact negative test should be designed according to your package and CI environment.

Step 9 - Test in CI/CD

A local restore is not enough.

Your CI environment may use:

Different NuGet.config
Different SDK
Different operating system
Different package cache
Different environment variables
Different working directory

Run the same restore operation in CI:

- name: Restore
  run: dotnet restore

- name: Build
  run: dotnet build --no-restore

- name: Test
  run: dotnet test --no-build

If the CI job uses a specific configuration file, make sure the updated policy is actually loaded by that job.

Example - Repository-Level NuGet Configuration

A repository may contain:

MyApplication/
├── src/
├── tests/
├── NuGet.config
└── MyApplication.sln

The configuration might contain:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="signatureValidationMode" value="require" />
  </config>

  <trustedSigners>
    <author name="ExamplePublisher">
      <certificate
        fingerprint="NEW456789..."
        hashAlgorithm="SHA256"
        allowUntrustedRoot="false" />
    </author>
  </trustedSigners>
</configuration>

The actual fingerprint should always be replaced with the verified certificate fingerprint for the publisher you trust.

Why Version-Controlled Configuration Helps

Keeping the relevant NuGet.config under source control provides several benefits.

A certificate update becomes a normal code review:

Pull request
     |
     v
NuGet.config change
     |
     +-- Reviewer checks certificate
     |
     +-- CI validates restore
     |
     +-- Tests run
     |
     v
Merge

This gives the organization an audit trail showing when the trust policy changed and why.

It also reduces the risk of one developer silently changing local configuration.

Common Mistakes

Replacing the Fingerprint Without Verification

This is the biggest mistake.

A trust policy should not be updated simply because a new fingerprint appears in a failed restore message.

Disabling Signature Validation

Changing:

<add key="signatureValidationMode" value="require" />

to a less restrictive setting may make the error disappear, but it also changes the security behavior.

Fix the trust relationship instead.

Updating Only the Local Machine

A CI pipeline can continue failing if its configuration is different.

Removing the Old Certificate Too Early

If older packages still need the old certificate, removing it immediately can break reproducible builds.

Keeping the Old Certificate Indefinitely

The opposite problem also matters. Once the old certificate is no longer required, keeping it trusted unnecessarily increases the trust surface.

Changing Multiple NuGet Settings Together

A focused certificate update is easier to review and troubleshoot.

Troubleshooting

Restore Still Fails After Updating the Fingerprint

Check:

[ ] Correct NuGet.config
[ ] Correct certificate fingerprint
[ ] Correct hash algorithm
[ ] Correct package source
[ ] Correct package version
[ ] Correct CI configuration

The most common problem is updating a configuration file that is not actually being used.

Local Restore Works but CI Fails

Compare the environments.

Check which configuration files are available in CI and how the restore command is executed.

Some Packages Work but Others Fail

The packages may be signed by different publishers or certificates.

Inspect the failing package independently rather than assuming all packages use the same signing identity.

Old Packages Fail After Removing the Old Certificate

The packages may still depend on the old signing identity.

Determine whether those packages need to remain supported during the transition.

The Certificate Fingerprint Looks Different

Make sure you are comparing fingerprints generated with the same hash algorithm.

A certificate can have different fingerprint representations depending on the algorithm used.

Best Practices

Treat Trusted Signers as Security Configuration

Review certificate changes with the same care as other security-sensitive configuration.

Keep the Policy in Source Control

This makes changes reviewable and reproducible.

Document Certificate Rotation

Record:

Publisher
Old certificate
New certificate
Reason for change
Effective date
Migration status
Removal date for old certificate

Test Both Acceptance and Rejection

A successful restore is only half of the test.

Verify that unexpected signing identities remain rejected.

Keep the Trust List Small

Trust only the publishers and certificates that are actually required.

Plan Certificate Rotation Before It Happens

Do not wait for production CI to fail before investigating a certificate migration.

Advantages of Updating the Policy Correctly

Package restore continues working without disabling signature validation.
Certificate trust remains explicit and auditable.
CI/CD environments remain consistent with developer environments.
Certificate rotation becomes manageable through a controlled process.
Unexpected package signatures can still be rejected.

Disadvantages and Trade-Offs

Certificate rotation requires maintenance.
Incorrect fingerprints can break package restore.
Multiple certificates may need temporary handling during migration.
CI and local environments can differ.
Strict policies require ongoing certificate lifecycle management.

Practical Migration Checklist

Use this checklist when updating a NuGet trusted signer policy:

[ ] Identify the package affected
[ ] Identify the current trusted certificate
[ ] Obtain the new certificate information
[ ] Verify the publisher identity
[ ] Verify the certificate chain
[ ] Confirm the new fingerprint
[ ] Confirm the hash algorithm
[ ] Locate the NuGet.config used by CI
[ ] Update only the required trust entry
[ ] Review the configuration change
[ ] Run dotnet restore
[ ] Run dotnet build
[ ] Run dotnet test
[ ] Test the CI pipeline
[ ] Verify unexpected signers are still rejected
[ ] Remove the old certificate when no longer required

Conclusion

Updating a NuGet trusted signer policy after a certificate change is more than replacing one fingerprint with another.

The certificate represents a trust decision, so the new signing identity should be verified before it is added to the policy.

A reliable migration starts by identifying the affected package and current configuration, verifying the new certificate, updating the appropriate NuGet.config, and testing both successful and rejected package validation.

For production .NET projects, keep trusted signer configuration under source control and make certificate changes part of the normal review and CI process.

The goal is simple: allow legitimate packages signed with the new certificate while continuing to reject packages that do not meet the organization's trust policy.