14.0 Current: author's primary signature expired

[Slesa]

When calling build_runtime.sh, I get the nuget error

error NU3037: Package 'Microsoft.SourceLink.Common from source 'https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json': The author primary signature validity period has expired.

for different packages.

[sec]

Hm, please try pkg install ca_root_nss as root and let me know if this helps.

[Slesa]

Unfortunately not: The most recent versions of packages are already installed

[sec]

Unfortunately not: The most recent versions of packages are already installed

That's weird. I assume you did pkg update? Which FreeBSD version are you using? Are you building inside jail or some restricted env?

[Slesa]

Everything up to date. I am on FreeBSD 14 Current. No jail active.

[sec]

This looks like certificate issue of some kind - give me few mins I will setup 14 on VM and check :)

edit: At which point does it produce this error? start, middle, etc? Would you mind to share bigger part of the output?

[Slesa]

well, it is a certificate issue. It's nuget :/ It happens at start, when it tries to restore packages.

##vso[task.setvariable variable=NUGET_PLUGIN_HANDSHAKE_TIMEOUT_IN_SECONDS;isSecret=false;isOutput=true]20                                 ##vso[task.setvariable variable=NUGET_PLUGIN_REQUEST_TIMEOUT_IN_SECONDS;isSecret=false;isOutput=true]20                                 
dotnet-core-freebsd-source-build/runtime/.dotnet/sdk/6.0.100-rc.1.21458.32/MSBuild.dll ...
Determining projects to restore...
dotnet-core-freebsd-source-build/runtime/.packages/microsoft.dotnet.arcade.sdk/6.0.0-beta.21427.6/tools/Tool
s.proj : error NU3037: Package 'Microsoft.SourceLink.AzureRepos.Git 1
.1.0-beta-20206-02' from source 'https://pkgs.dev.azure.com/dnceng/pu
blic/_packaging/dotnet-eng/nuget/v3/index.json': The author primary s
ignature validity period has expired. 

This is the first failing package

[sec]

I can confirm that under 14-CURRENT, didn't hit that under 12 nor 13, so I have really no idea what changed in 14 that could trigger this. I will try to dig into this and fix it somehow - if you cn you can try to build under 12 or 13 - that should work :)

[Slesa]

This is true. I am compiling w/o problems on GhostBSD, which means 13.0 stable. So, could it be a change in ca_root_nss? Edit: sorry for the stupid question, but how can I install th SDK from the tgz?

[arrowd]

I bumped into the same problem when I was playing with dotnet/installer. Also FreeBSD 14, inside the jail.

[arrowd]

Interestingly, both fetch and curl can successfully fetch that index.json file, which means that the certificates are fine. There is something inside the file, which confuses .NET.

[sec]

This is true. I am compiling w/o problems on GhostBSD, which means 13.0 stable. So, could it be a change in ca_root_nss? Edit: sorry for the stupid question, but how can I install th SDK from the tgz?

Just extract :) there will be dotnet binary inside with all the SDK's

[Slesa]

I have no idea how to turnoff the signature validation :/ And I really do not understand how this can happen on 14-Currrent only - has the signature expired or not? There should be a command

nuget trusted-signers sync

may that could help?

[sec]

There's no such command in dotnet nuget, BUT... I have the same error on 13 when using ca_root_nss-3.69_1 package - so this must be something new :)

[Thefrank]

try this: https://github.com/dotnet/runtime/issues/14537#issuecomment-851286936 make sure to use certctl to rehash

[sec]

Does this mean that pkgs.dev.azure.com is using nontrusted cert?

[Thefrank]

did it work? if yes, that means...well, its complicated...that cert was removed from ca_root_nss it was not added to the blacklist however. So, is the cert not trusted? Yes, but only by Mozilla. Is the cert not to be trusted? Well, that is up to you.

[Slesa]

I called

certctl rehash

and now I get " The author primary signature validity period has expired", but mixed with "The repository countersignature validity period has expired"

[sec]

Yeah, it didn't help. Wonder why I can dotnet restore on new project, but can't when building runtime... Doing openssl s_client -showcerts -connect pkgs.dev.azure.com:443 is also fine. I do not see MS in certctl untrusted.

Also the certifacte from the comment, looking at bug report, it was removed/fixed in 3.63 - I have 3.63 on one machine and it's fine there, but using 3.69 produce this error :D

But also removing ca_root_nss from 14 system, still produce this error (I assume they imported newest trusted/untrusted into base system).

BUT I just wan't to know which certificate it's failing :D

[sec]

Wild guess, but looking at https://github.com/NuGet/Home/issues/10491 - does this mean that those CA's are "embedded" into SDK? So we need to crossbuild "new" SDK or what? :)

[Slesa]

I tried a

nuget restore

(on FreeBSD 13 with ca_root_nss 3.69_1) in a dotnet5/6 project and get a 'unable to load index.json, Problem with the SSL CA cert', but once again - Firefox and wget display the file. Now how could I debug nuget's certificate negotiation? Microsoft is in cert.pem...

[sec]

You tried to run nuget.exe using mono or?

[Slesa]

Sorry, dotnet restore

[sec]

@Slesa which SDK did you use and which project did you try to restore?

[Slesa]

I am checking out the main branch of this repo. I called init.sh and _installtools.sh (and get a mismatch for the kernel from the latter). Then I call _buildruntime.sh, which means the project is the runtime itself.

When I checked out the sdk itself, I got the same errors when calling build.sh there.

Now I've extracted a 6.0.100-rc.1.21458.71 - and I have no idea what to do with it

[sec]

You want to compile the SDK yourself or just want to use SDK? If you want to just use SDK, then just extract it somewhere, add this directory to PATH (so that you have dotnet available) and you can use it like dotnet new etc. main branch is right now w.i.p. for rc-2. For rc-1 use the proper tag. Are you getting author's primary signature expired when trying to dotnet restore on some of your projects or when trying to compile the SDK from sources (this error I'm also getting with new ca_root_nss package and have no idea how to fix that atm).

[Slesa]

I am trying to build this repo exactly as it is and exactly as described in Readme.md and I am getting the error exactly in those build scripts. Can't we ask the maintainers of the ca_root_nss package, or is there a way to use old versions of it and find the differences?

[Slesa]

The packages on the NuGet server must be resigned, or the signature stuff must be turned off somehow. I've called build directly in runtime and the NuGet.conf points there. Or am I missing someting?

[sec]

I have no idea why this error is throwing out and to fix it without doing magic with certificates from ca_root_nss package - that should be question to .NET team I think or someone who's more familiar with those kind of stuff :(

[Thefrank]

Other things to check for: expired certs ( e.g., DST Root CA X3 should be deleted and db should be rehashed), certs that need updates (e.g., ISRG Root X1 should be self-signed and not cross-signed...and rehash the db), odd edge-cases like an IPv6 needing to be assigned to your jail/bridge/interface for dotnet restore to not throw a fit randomly, Micrsoft/NuGet's expired signing keys still being baked in and needing overrides (https://devblogs.microsoft.com/nuget/microsoft-author-signing-certificate-update/ and https://devblogs.microsoft.com/nuget/the-nuget-org-repository-signing-certificate-will-be-updated-as-soon-as-march-15th-2021/)

[sec]

I don't get this. Using the same ca_root_nss version 3.69 - under 13 build runs fine, under 14 there are errors about those signatures expired. Only diffrence is openssl 1.1.1k vs 1.1.1l but I don't think it should be that...

[sec]

Ok I know what's up and it's working on some of my VM's and on some not - @Slesa I will follow up on this tomorow :)

[sec]

@Slesa this should fix the error:

rm /usr/share/certs/blacklisted/VeriSign_Universal_Root_Certification_Authority.pem
certctl rehash

also added info about this to main branch.

[arrowd]

Is this a workaround or a correct fix?

[sec]

Is this a workaround or a correct fix?

@arrowd to be honest - I have no idea why this cert got blacklisted... This is just a temp fix I assume to get the build going.

[arrowd]

Then closing this issue may be a bit premature?

[sec]

Maybe, I can leave it open, but nothing more I can do about this :)

edit: as you can read on https://bugzilla.mozilla.org/show_bug.cgi?id=1686854 - this cert was removed - wodner why MS is still using those?

edit 2: reading this and that - looks like the issue is known, but msbuild is still doing that verification :)

[Thefrank]

Good to see that blacklist overrides trustlist even if its causing all this confusion

[sec]

Closing this, as:

• there is a workaround provided in README
• it's fixed now by https://github.com/NuGet/NuGet.Client/pull/4389 and should no longer be an issue

[Thefrank]

Footnote to the above mentioned PR: it might be a while before that actual makes it into an SDK. 6.0.3xx looks like the earliest it will be in.