Microsoft’s Author-Signing Certificate Update [August 14th, 2023]

This post covers updates that could impact your development workflow. An imminent change is set to occur within the Microsoft ecosystem, explicitly involving the Microsoft author-signing certificate for NuGet packages.

Scheduled for deployment as early as August 14th, 2023, this impending alteration warrants your attention to ensure the seamless continuation of your packaging and installation processes.

Suppose you validate packages through Microsoft’s author-signing using NuGet client policies or the NuGet.exe verify command. In that case, it is imperative to take proactive measures before the date mentioned earlier arrives.

By adhering to a few straightforward steps, you can mitigate potential disruptions that arise when installing new Microsoft packages. To ascertain whether these adjustments will impact your workflow, we have delineated comprehensive guidelines to assist you in gauging the relevance of these modifications to your current practices.

Microsoft’s X.509 certificate to Author-sign NuGet Packages

At the heart of this transformation lies Microsoft’s employment of an X.509 certificate to author-sign its NuGet packages. The current certificate is slated to expire on October 5th, 2023. However, as a harbinger of enhanced security measures, a new certificate is primed to supplant its predecessor.

Expected to come into effect in late August 2023, this fresh iteration of the Microsoft author-signing certificate for NuGet packages signifies a progressive stride toward safeguarding the integrity of your software ecosystem.

While pre-existing packages endowed with the former certificate’s signature will remain unaffected, it is essential to acknowledge that the prior certificate will soon cease to be employed for signing purposes.

The fingerprints of certificates play a pivotal role in establishing trust and authenticity.

Currently, the SHA-256 fingerprint of the existing certificate stands as follows:
AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27.

On the horizon, a new certificate emerges with a distinct SHA-256 fingerprint: 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353.

The impact of these changes extends primarily to specific segments of users within the ecosystem. Customers who employ a NuGet client policy to enforce a list of trusted signers that encompasses Microsoft’s signature will be directly affected.

How to Examine nuget.config?

To determine whether your configuration aligns with this scenario, thoroughly examine nuget.config file is required. It’s worth noting the presence of multiple nuget.config files across varying scopes could further complicate this assessment.

A snippet from the configuration file could resemble the following:

<config>
  <add key="signatureValidationMode" value="require" />
</config>
<trustedSigners>
  <author name="Microsoft">
    <certificate fingerprint="3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE" hashAlgorithm="SHA256" allowUntrustedRoot="false" />
    <certificate fingerprint="AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27" hashAlgorithm="SHA256" allowUntrustedRoot="false" />
  </author>
</trustedSigners>

Moreover, those who utilize the NuGet.exe verify command to validate the authorship of signed packages by Microsoft are also within the sphere of impact.

This verification process takes the form of:

NuGet.exe verify -Signatures <PackagePath> -CertificateFingerprint “3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE;AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27”

The impending alterations demand attention from these specific user groups to ensure a smooth transition while upholding the security and authenticity of their software operations.

If no possibilities apply, then the certificate update shouldn’t affect you. Packages for Microsoft NuGet certified with the new certificate should be set up similarly to those signed with earlier certifications.

Microsoft Certificate’s NuGet Client Policy

A particularly evident case of the new Microsoft certificate that is set to be introduced. If you currently employ a NuGet client policy to enforce a meticulously curated roster of trusted signers, a crucial step awaits your attention: including the new Microsoft certificate within your safelist.

With the new Microsoft certificate in your roster of trusted signers, you pave the way for uninterrupted installation experiences when dealing with Microsoft packages that bear the signature of this fresh certificate.

However, it’s vital to acknowledge the significance of maintaining the older Microsoft certificates in your repertoire.

This approach guarantees the successful installation of Microsoft packages still signed using the previous certificates.

The absence of this adjustment could lead to potential complications, as endeavors to install the latest Microsoft packages sans an updated list of trusted signers will result in an NU3034 error, culminating in the failure to install the package.

To effectuate this transition seamlessly, you can execute the following command:

NuGet.exe trusted-signers Add -Name Microsoft2023 -CertificateFingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353 -FingerprintAlgorithm SHA256

Embracing this measure for your installation procedures underscores your commitment to upholding the robust security of your software ecosystem.

As the digital landscape evolves, accommodating these pivotal changes becomes a hallmark of responsible and forward-thinking software management.

Ensuring the integrity and security of your software ecosystem demands a proactive approach to adapting to certificate changes. By incorporating the following elements into your nuget.config file, encompassing both old and new certificates, you can navigate this transition seamlessly:

<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" />
  </author>
</trustedSigners>

For those relying on NuGet.exe verify to ascertain the author-signed status of a package by Microsoft, a simple adjustment to the command is necessary:

NuGet.exe verify -Signatures <PackagePath> -CertificateFingerprint “3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE;AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27;566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353”

A noteworthy update pertains to the NuGet.org repository-signing certificate, which is set to expire close to the Microsoft author-signing certificate. Anticipate a similar update for this certificate and an accompanying instructional post for NuGet.org.

Should any complications arise during the implementation of the steps outlined above, you are encouraged to contact NuGet for assistance.

Search