Sign fails with untrusted certificates

[rido-min]

Nuget.exe 4.6.2.5055

nuget sign mypackage.nupkg -certificateapth MySelfSignedCert.pfx

fails with

NU3018: A certificate chain could not be built to a trusted root authority.
WARNING: NU3018: The revocation function was unable to check revocation for the certificate.
WARNING: NU3018: The revocation function was unable to check revocation because the revocation server was offline.
NU3018: Certificate chain validation failed.

Expected. Same behavior as SignTool (allows to sign without trusting the certificate)

[PatoBeltran]

This is not an issue for nuget.exe sign. Sign accepts untrusted self issued certificates as signers with a warning (https://github.com/NuGet/NuGet.Client/blob/91316ff8e9b1092900961b8ddfc95766d74a8969/test/NuGet.Clients.FuncTests/NuGet.CommandLine.FuncTest/Commands/SignCommandTests.cs#L663).

Nevertheless, if a signing certificate is untrusted but is not self issue the sign operation does fail. This is by design and there is no current plan to update this behavior. I will close this issue because there is no current significant scenario where signing with untrusted not self issued certificates is needed. Feel free to reopen it in the future if an scenario is blocked by this.

[drauch]

@PatoBeltran : We're using an in-house CA and would like to sign in-house deployment packages (which are NuGet packages, as Octopus Deploy requires NuGet packages) with certificates signed by our in-house CA. We're using a 3rd-party service to sign our packages. The 3rd party service is not able to install our CA-root as a trusted root certificate. Therefore all our signing attempts with this 3rd party service fail. There should be an option to "ignore" certificate chains when signing NuGet packages. Please reopen and provide such an option! The 3rd party already confirmed us that they would use this option if provided.

[rido-min]

We will investigate what's the best option to implement this. We need to build the chain anyway, one option will be to accept all the needed certificates.

[drauch]

There is now even the option to verify a chain with an untrusted root when using the trusted-signers feature (see "AllowUntrustedRoot" in https://docs.microsoft.com/en-us/nuget/tools/cli-ref-trusted-signers). So it's even more a pity that signing does not have an option "-allowUntrustedRoot" yet :-)

[drauch]

Is there any update on this? Would you accept pull requests for this?

[Dammmien]

Hi,

I have a very similar issue but can't figure out what's the root cause. Can anyone help ?

[rido-min]

/c @dtivel @rrelyea

[drauch]

Any updates?

[rgnote]

Any updates on this issue? @drauch I'm in the same boat as you. Were you able to get around this issue?

[drauch]

Unfortunately, no.

[gaoalexander]

We would be willing to submit a PR to support this option to ignore certificate chain when signing a NuGet package. @rido-min Would the NuGet team be open to reviewing / accepting this PR?

[anangaur]

+ @JonDouglas @dtivel to weigh in the request.

[JonDouglas]

Hi everyone,

To help our team prioritize this issue, can those interested in the completion of this feature/contribution upvote this issue using an 👍?

https://github.com/NuGet/Home/blob/dev/CONTRIBUTING.md#before-submitting-an-issue

Additionally, if you are interested in contributing such an option to the tooling, the NuGet team reviews proposals every couple weeks or so once there has been enough time for the community to upvote & engage:

https://github.com/NuGet/Home/tree/dev/meta#how-do-i-create-a-proposal

@gaoalexander if you'd be so kind to create a proposal of what you plan to implement for ignoring the certificate chain, we would be able to review it as a community/team & accept the contribution(for you to move forward with a PR) or help explain why we won't be able to take on the contribution.

EDIT: Upvote the initial issue if you can! That way it can be tracked better ;)

[gaoalexander]

@JonDouglas thank you for your response, I am working on the proposal currently.

I had another question regarding general releases on nuget.org - in the event that this PR is merged into the dev branch, do you have any guidance as to what to expect in terms of the change being released on nuget.org (i.e. expected timeline, other factors)?

[JonDouglas]

@gaoalexander The PR would likely address an optional parameter in the client tooling & plumb it to the respective OS signing tool(i.e. SignTool). The client tooling follows the Visual Studio Release Rhythm in which new features/changes are brought in regularly in future minor release versions. You can get an idea of how long that may take by reading the documentation linked above. Just a quick note that we typically give proposals a couple of weeks of time to be reviewed by the community to help provide feedback, upvotes, and do an internal review afterwards.

[ivandamyanov]

Just like @drauch, we are trying to use an in-house CA. Unfortunately, trusted CAs can't be modified in Azure pipelines on public agents so we'd be interested in such a change. I up-voted the issue.

[dlemstra]

I also ran into this issue when I was trying to create a test code signing certificate in a GitHub actions build. I was able to "fix" this issue by using this command certutil -addstore Root ca.crt in the build pipeline.