Getting NU3018 after upgrading to Duende version 6.2.5

[daphneSot]

Which version of Duende IdentityServer are you using? 6.2.5 Which version of .NET are you using? 8.0.303 sdk Describe the bug While trying to update nuget from 6.2.4 to 6.2.5 getting NU3018 while restoring packages for duende. It is complaining for certificate not in trusted root

Stacktrace: error NU3042: Warning As Error: Package 'Duende.IdentityServer.Storage 6.2.5' from source '****': The following X.509 root certificate is untrusted because it is not present in the certificate bundle at /usr/share/dotnet/sdk/8.0.303/trustedroots/#######.pem. For more information, see documentation for NU3042

[daphneSot]

This is happening, when restoring packages from within a docker image: mcr.microsoft.com/dotnet/sdk:8.0.

We are using the latest image from microsoft for dotnet 8 sdk (8.0.303 sdk)

[stylianosnicoletti]

Facing the same issue with latest .NET 8 SDK Debian 8.0.7-bookworm-slim-amd64 image.

DOTNET_SDK_VERSION=8.0.303

Please also see: https://github.com/dotnet/sdk/issues/42493

[roemba]

We face the same issue when upgrading to 6.3.10. This occurs in the latest, offical SDK Docker image mcr.microsoft.com/dotnet/sdk:8.0 and restoring our solution:

error NU3042: Warning As Error: Package 'Duende.IdentityServer.Storage 6.3.10' from source 'https://api.nuget.org/v3/index.json': The following X.509 root certificate is untrusted because it is not present in the certificate bundle at /usr/share/dotnet/sdk/8.0.303/trustedroots/codesignctl.pem.  For more information, see documentation for NU3042.
error NU3042:     Subject:  CN=Sectigo Public Code Signing Root R46, O=Sectigo Limited, C=GB
<certificate follows>

It is a very nasty issue, as we currently also get a CVE warning for 6.3.9 that breaks our pipelines (warningsAsError is enabled). But if we want to upgrade, we can't because of this issue...

[josephdecock]

Thanks everyone for reporting this. We've done more investigation and have a better understanding of why this is now necessary (see below). The resolution is to add Sectigo's root CA to your build pipelines. Read on for more details on why.

Sectigo issues our signing cert, and they have changed their certificates. Initially, they had an intermediate certificate signed by AAA. Now, they have their own self-signed root certificate. On May 28, windows updated to include their root CA in the default trusted root CAs. Eventually that update made its way into our build environment, which now resolves the certificate chain using the new root CA. It appears that other environments don't yet trust the new certificate from sectigo. That's why you need to manually add the new certificate to your build pipeline.

[josephdecock]

I'm closing this issue, as it is a duplicate of #1352 . Please see that thread for more details.