A learning journey

pollirrata.com

NuGet package restore broken on .NET 5+ with Removal of Trust of Verisign CA

Since I’m subscribed to the .NET announcements GitHub repo, last week I got an email with the following content (red emphasis mine)

NuGet package restore broken on .NET 5+ with Removal of Trust of Verisign CA

NuGet package signing verification relies on the VeriSign Universal Root Certification Authority as part of establishing a chain-of-trust for NuGet packages. VeriSign Universal Root Certification Authority was recently removed from NSS and ca-certificates packages. This removal effectively breaks NuGet package signing verification, which has the result of breaking the ability to restore NuGet packages.

This break in behavior is only observed with .NET 5 and .NET 6, which have NuGet package verification enabled (and it cannot be disabled).

The update email provides more details about who is affected, the impact, and the suggested solution. But, I was wondering, why is this happening? Let’s analyze the pieces.

What’s the VeriSign Universal Root Certification Authority?

According to Mozilla, a “Certification Authority (CA) is an organization that browser vendors […] trust to issue certificates to websites”. Each certificate we use is issued by a CA, and, for the certificate to be considered trustworthy, we need to trust the CA. That’s why, by default, browsers don’t trust self-signed certificates.

In March 2018, Mozilla issued a plan to distrust all Symantec TLS/SSL certificates in response to some Symantec Issues. The change affected “all Symantec brands including GeoTrust, RapidSSL, Thawte, and VeriSign.”

Last February, as a “continuation of the distrust of Symantec root certificates”, Mozilla removed two root certificates from NSS:

  • GeoTrust Primary Certification Authority – G2
  • VeriSign Universal Root Certification Authority

OK, this is cool for Mozilla and Firefox, but, how does this affect NuGet?

NuGet Package signing verification

For NuGet 4.6.0+ and VS2017 v15.6 or later, “packages can include a digital signature that provides protection against tampered content”, according to Microsoft Documentation. This is helpful because “signed packages provide the strongest end-to-end validation”. According to this blog post from 2015, this was intended to be included in ASP.NET 5.

According to the announcement details “NuGet has historically relied on two key certificates:

  • NuGet Microsoft Author Signing Certificate Update – Expired January 27th, 2021
  • NuGet.org Repository Signing Certificate Update – Expires April 14th, 2021

After those certificates expire, the NuGet client falls back to timestamp verification, which enables package verification to still function”.

Moreover, according to this blog post from Jon Douglas, Senior Program Manager for NuGet, “NuGet uses trusted timestamps to ensure long-term validity of signatures after the signing certificate expires”

The issue here is that “[t]he timestamp verification relies on VeriSign root certificate authority” and, as stated above and detailed in Jon’s post

There has been an industry-wide movement to distrust the VeriSign Universal Root Certificate Authority, which affects the Symantec Time Stamping service, a popular issuer of trusted timestamps. If VeriSign is distrusted, NuGet will reject timestamps issued by Symantec, resulting in package signature verification to fail during your NuGet restore.

As Jon mentions,

“This was due to an unfortunate confluence of events: the addition of package signature verification in .NET 5, the Microsoft Author Signing Certificate expiring, and the removal of trust of the VeriSign Universal Root Certificate Authority.”

NSS + NuGet

It’s probable you haven’t experienced this issue. This is because (at least for now) the problem is only for Linux distros relying on NSS.

Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards.

According to the update, “.NET 5+ users using dotnet restore will be affected on any operating system that has removed the VeriSign Universal Root Certification Authority.”. In an issue opened on March 31st, a list of distros that have failed includes (at the time of this writing)

  • Mint 21+
  • Ubuntu 21.04+
  • Archlinux 20210328+ and 20201128+ (not officially supported by .NET)

Solution (?)

As per the .NET team, they will issue a new build for .NET 5 and 6 disabling the package verification for macOS and Linux, so this is not causing a problem. We’ll see how soon they enable it again, but for now it’s good to understand where the problem came from.

Leave a Reply

Your email address will not be published. Required fields are marked *