Support Azure Trusted Signing certificate on NuGet.org account settings

[jozefizso]

NuGet Product(s) Involved

Other/NA

The Elevator Pitch

The Azure Trusted Signing service rotates the managed authenticode certificates each three days.

As the NuGet Gallery requires to specify a single, long lived certificate, it is not feasible to sign nuget packages with the ATS.

Additional Context and Details

No response

[jebriede]

@jozefizso thanks for reaching out. Could you please include details of what feature or change you are proposing? Thanks!

[jozefizso]

The Gallery should support the code signatures made by Azure Trusted Signing. It is unfeasible to upload new signature to Gallery each three days to get the verified badge.

[joelverhagen]

Thanks for opening the issue @jozefizso. I agree using Trusted Signing with NuGet.org is a painful process today. You need to extract the .cer file from your signed artifact (or get it from Trusted Signing directly, perhaps) and then manually upload it to your account profile on NuGet.org.

For my own experiments I created a CLI tool to extract the .cer file and include it as a GitHub Actions artifact.
Tool: https://www.nuget.org/packages/Knapcode.CertificateExtractor
Workflow: https://github.com/joelverhagen/PackageLifeCycle/blob/7930b64f7e72518faf6b646187b47b46e2d64d22/.github/workflows/build.yml#L76-L87

This is better than nothing, but not much better!

[dlemstra]

I would nice if we could get a new option to specify the Enhanced key usage that is shown on the page of our Certificate Profile inside our Trusted Signing Account. That is the same one as the bottom one that is shown here:

And then when we upload the NuGet package the server checks if this matches and also checks if the signing of the package is done by the right authority.

[ianjmcm]

Supporting the Subscriber identity validation EKU as @dlemstra points out would be durable over all certificate rotations/renewals. Here is the public docs on these values: https://learn.microsoft.com/en-us/azure/trusted-signing/concept-trusted-signing-cert-management#subscriber-identity-validation-eku.

[mjcheetham]

This problem is currently impacting Git Credential Manager that ships a NuGet package that's signed by Azure Trusted Signing – would love to see some support for these sorts of certificates/signed packages, and a solution that is durable over all of the short-lived certs.

[jmecosta]

Thanks for opening the issue @jozefizso. I agree using Trusted Signing with NuGet.org is a painful process today. You need to extract the .cer file from your signed artifact (or get it from Trusted Signing directly, perhaps) and then manually upload it to your account profile on NuGet.org.

For my own experiments I created a CLI tool to extract the .cer file and include it as a GitHub Actions artifact. Tool: https://www.nuget.org/packages/Knapcode.CertificateExtractor Workflow: https://github.com/joelverhagen/PackageLifeCycle/blob/7930b64f7e72518faf6b646187b47b46e2d64d22/.github/workflows/build.yml#L76-L87

This is better than nothing, but not much better!

@joelverhagen is the & "bin\Sign.Cli\sign.exe" something that you have created? can you share it? or do you have any pointers how to get nuget sign with trusted service? or are you using dotnet/sign#716

[dlemstra]

The "bin\Sign.Cli\sign.exe" executable is the output of the dotnet/sign project. The branch of my PR is still work in progress so it's subject to change. I have been using it locally but not yet in a pipeline.

[jmecosta]

yep, just getting to that conclusion also, there are a few cli options changed but pretty much what im looking for... thank you

[dlemstra]

And those options might still change because the PR is still being reviewed by the team.

[jmecosta]

Yep important is the sign functionality itself if that works we can start integrating it already

[joelverhagen]

@dlemstra is spot on. I have a private build of sign CLI used in the pipeline links above.

But to be clear this GitHub issue tracks better support of Trusted Signing on NuGet.org (verification of signing at push time in NuGet.org) and not the sign flow which is tracked by dotnet/sign#683.