Closed altso closed 2 months ago
This looks similar to what we describe here: https://docs.duendesoftware.com/identityserver/v7/overview/security/#package-signing.
But if I read the log above right, you are downloading from nuget.org and as far as we've seen before it has worked when downloaded from nuget.
I have just verified that 7.0.6 is signed in the same way as our previous releases. As we describe in the linked documentation, we sign everything we publish, and the certificate used in 7.0.6 is the same as previous builds. Our packages are also signed by nuget.org. Most build environments (e.g., the .net 8 SDK docker image microsoft produces) trust the root ca that signs nuget.org's certificate only. As long as you trust 1 of the signatures, nuget will allow a package to be used. It seems like in your case, your nuget tooling in your build environment doesn't trust nuget.org or Duende's signature. We definitely encourage you to trust our signature (and verify it against some other out of band source - easy to do because our cert is signed by a root ca that is trusted by default on most desktop environments). Again, see the linked docs for more details.
Thanks for a prompt reply and providing the docs.
Just to confirm a few things: Yes, we are downloading from nuget.org. We are running the build in GitHub Actions using a standard runner with dotnet build
command (no docker). According to the history of build executions we only get this warning with 7.0.6.
Do you know if GitHub Actions standard runners do not trust the Sectigo certificate? Docs only mention dotnet docker.
I downgraded to 7.0.5 and got the same warnings using GitHub Actions. Something must have changed in the build environment in the last 2 weeks. I'll follow the instructions to trust the certificate. Thank you.
I am running into the same issue, using GitHub actions.
I have tried to modify the build as such to trust the cert before doing the build. I see the commands from the docs have run successfully prior to the build. I additionally tried doing this earlier in the build as a separate step, with no luck.
- name: Restore NuGet packages
working-directory: ${{ inputs.SRC_PATH }}
run: |
wget http://crt.sectigo.com/SectigoPublicCodeSigningRootR46.p7c
openssl pkcs7 -inform DER -outform PEM -in SectigoPublicCodeSigningRootR46.p7c -print_certs -out sectigo.pem
dotnet restore
This still fails with the NU3042.
Also experiencing the error building with 6.3.10 in Docker using mcr.microsoft.com/dotnet/sdk:8.0
.
We're not trusting any extra certificates, but haven't run into problems before.
Comparing the certificate chain using nuget verify, there is a small difference. I don't know what it means. The same different appears between 7.0.5 and 7.0.6.
6.3.9
Verifying Duende.IdentityServer.6.3.9
/Users/josephdaigle/Downloads/duende.identityserver.6.3.9.nupkg
Signature Hash Algorithm: SHA256
Signature type: Author
Verifying the author primary signature with certificate:
Subject Name: CN=Duende Software Inc., O=Duende Software Inc., S=Rhode Island, C=US
SHA1 hash: A31FF35243846A9CDDC21726961E9DBB826E0824
SHA256 hash: 1FFA5C758242236AF43B16797C52907F7F08354D14B7DF913B6E9DCE18A86348
Issued by: CN=Sectigo Public Code Signing CA R36, O=Sectigo Limited, C=GB
Valid from: 1/6/2022 7:00:00 PM to 1/6/2025 6:59:59 PM
trace: Subject Name: CN=Sectigo Public Code Signing CA R36, O=Sectigo Limited, C=GB
trace: SHA1 hash: 0BC5E76773D2E44FC9903D4DFEFE451553BBEC4A
trace: SHA256 hash: 7FB0F58D71130ABE724969F1CDC9B6A8D3274DA18D059229B009A5B9B5557445
trace: Issued by: CN=Sectigo Public Code Signing Root R46, O=Sectigo Limited, C=GB
trace: Valid from: 3/21/2021 8:00:00 PM to 3/21/2036 7:59:59 PM
trace: Subject Name: CN=Sectigo Public Code Signing Root R46, O=Sectigo Limited, C=GB
trace: SHA1 hash: 329B78A5C9EBC2043242DE90CE1B7C6B1BA6C692
trace: SHA256 hash: 7DB9F7402A523DD338663B33D55AAD0DD08CB67E687DF0D4D98E7C5FCA27EFD1
trace: Issued by: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, S=Greater Manchester, C=GB
trace: Valid from: 5/24/2021 8:00:00 PM to 12/31/2028 6:59:59 PM
trace: Subject Name: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, S=Greater Manchester, C=GB
trace: SHA1 hash: D1EB23A46D17D68FD92564C2F1F1601764D8E349
trace: SHA256 hash: D7A7A0FB5D7E2731D771E9484EBCDEF71D5F0C3E0A2948782BC83EE0EA699EF4
trace: Issued by: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, S=Greater Manchester, C=GB
trace: Valid from: 12/31/2003 7:00:00 PM to 12/31/2028 6:59:59 PM
Compared to 6.3.10
Verifying Duende.IdentityServer.6.3.10
/Users/josephdaigle/Downloads/duende.identityserver.6.3.10.nupkg
Signature Hash Algorithm: SHA256
Signature type: Author
Verifying the author primary signature with certificate:
Subject Name: CN=Duende Software Inc., O=Duende Software Inc., S=Rhode Island, C=US
SHA1 hash: A31FF35243846A9CDDC21726961E9DBB826E0824
SHA256 hash: 1FFA5C758242236AF43B16797C52907F7F08354D14B7DF913B6E9DCE18A86348
Issued by: CN=Sectigo Public Code Signing CA R36, O=Sectigo Limited, C=GB
Valid from: 1/6/2022 7:00:00 PM to 1/6/2025 6:59:59 PM
trace: Subject Name: CN=Sectigo Public Code Signing CA R36, O=Sectigo Limited, C=GB
trace: SHA1 hash: 0BC5E76773D2E44FC9903D4DFEFE451553BBEC4A
trace: SHA256 hash: 7FB0F58D71130ABE724969F1CDC9B6A8D3274DA18D059229B009A5B9B5557445
trace: Issued by: CN=Sectigo Public Code Signing Root R46, O=Sectigo Limited, C=GB
trace: Valid from: 3/21/2021 8:00:00 PM to 3/21/2036 7:59:59 PM
trace: Subject Name: CN=Sectigo Public Code Signing Root R46, O=Sectigo Limited, C=GB
trace: SHA1 hash: 8E3405F3470E2E072AAB66DEF8DA7B160822E5CD
trace: SHA256 hash: 17A999FE8BB02FAE28C5EA8B0FDA68AE4828B6B589E13E27D9D5E4017F776418
trace: Issued by: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, S=New Jersey, C=US
trace: Valid from: 3/21/2021 8:00:00 PM to 1/18/2038 6:59:59 PM
trace: Subject Name: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, S=New Jersey, C=US
trace: SHA1 hash: 2B8F1B57330DBBA2D07A6C51F70EE90DDAB9AD8E
trace: SHA256 hash: E793C9B02FD8AA13E21C31228ACCB08119643B749C898964B1746D46C3D4CBD2
trace: Issued by: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, S=New Jersey, C=US
trace: Valid from: 1/31/2010 7:00:00 PM to 1/18/2038 6:59:59 PM
Thanks for these additional details. We are investigating, and I have reproduced this issue.
I am running into the same issue, using GitHub actions.
I have tried to modify the build as such to trust the cert before doing the build. I see the commands from the docs have run successfully prior to the build. I additionally tried doing this earlier in the build as a separate step, with no luck.
- name: Restore NuGet packages working-directory: ${{ inputs.SRC_PATH }} run: | wget http://crt.sectigo.com/SectigoPublicCodeSigningRootR46.p7c openssl pkcs7 -inform DER -outform PEM -in SectigoPublicCodeSigningRootR46.p7c -print_certs -out sectigo.pem dotnet restore
This still fails with the NU3042.
I think you need to append the sectigo.pem to the certificate store. In my own reproduction of this issue (which is running in the mcr.microsoft.com/dotnet/sdk:8.0 docker image, I did so like this:
cat sectigo.pem >> /usr/share/dotnet/sdk/8.0.303/trustedroots/codesignctl.pem
And was then able to validate the nuget package.
To be clear though, we are still investigating why this is necessary.
This seems like the same issue that is experienced here https://github.com/DuendeSoftware/Support/issues/1354
To be clear though, we are still investigating why this is necessary.
Yes, It shouldn't be necessary right?
Same error here when updating from 7.0.5 to 7.0.6 version, what is the current investigation progress?
For what its worth, it seems the certificate our builds report can't be found is present in the .NET 9 Preview 6 SDK, just not in the .NET 8 SDKs
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.
So... any idea how often the root CAs in mcr.microsoft.com/dotnet/sdk
get updated? If the new Root CA has been around for at least two months it means it is not a frequent update cycle.
It might even be the case, as @yarhamjohn reports, that it will only ever be available in .NET 9 but not in the .NET 8 SDKs... It would help in determining if we have to go for the workaround or wait until the CAs get updated. Perhaps it is good to open an issue at https://github.com/dotnet/dotnet-docker/issues to alert them that users are encountering issues with their outdated CA store?
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 Sectigo's root certificate link is pointing to non-secure http
scheme URL (http://crt.sectigo.com/SectigoPublicCodeSigningRootR46.p7c). I'm not so inclined to add that to our CI, is there another source where we can grab the root cert from?
So... any idea how often the root CAs in
mcr.microsoft.com/dotnet/sdk
get updated? If the new Root CA has been around for at least two months it means it is not a frequent update cycle.It might even be the case, as @yarhamjohn reports, that it will only ever be available in .NET 9 but not in the .NET 8 SDKs... It would help in determining if we have to go for the workaround or wait until the CAs get updated. Perhaps it is good to open an issue at https://github.com/dotnet/dotnet-docker/issues to alert them that users are encountering issues with their outdated CA store?
This is a good idea. I'm doing a bit more research and then will open an issue there.
@josephdecock Sectigo's root certificate link is pointing to non-secure
http
scheme URL (http://crt.sectigo.com/SectigoPublicCodeSigningRootR46.p7c). I'm not so inclined to add that to our CI, is there another source where we can grab the root cert from?
This is a classic boot strapping problem in a chain of trust and in this case I believe they do not publish their certificate any other way. You need an out of band mechanism for validating the certificate, and fortunately that is fairly straightforward to do. Windows (and I believe also Mac) already trust this certificate and include it by default in the trusted root certificate store in desktop environments. So an easy way to validate the certificate is to compare its thumbprint to the thumbprint of the certificate that is already in your desktop environment.
So... any idea how often the root CAs in
mcr.microsoft.com/dotnet/sdk
get updated? If the new Root CA has been around for at least two months it means it is not a frequent update cycle. It might even be the case, as @yarhamjohn reports, that it will only ever be available in .NET 9 but not in the .NET 8 SDKs... It would help in determining if we have to go for the workaround or wait until the CAs get updated. Perhaps it is good to open an issue at https://github.com/dotnet/dotnet-docker/issues to alert them that users are encountering issues with their outdated CA store?This is a good idea. I'm doing a bit more research and then will open an issue there.
I've opened https://github.com/dotnet/dotnet-docker/issues/5750 to see if the docker sdk team can help here.
For now, our advice is to add the sectigo certificate to your build pipelines and update to one of the latest patch versions of IdentityServer.
The dotnet docker team has already added the new sectigo cert to their mainline, and it will be included in the next patch release, which is scheduled for patch Tuesday (second Tuesday of the month, August 13). At that time, you should be able to validate our packages without any additional steps.
In case someone is looking for a copy-paste solution for their dockerfile (this is for alpine, but should work in general):
RUN wget http://crt.sectigo.com/SectigoPublicCodeSigningRootR46.p7c -O sectigo.p7c && \
openssl pkcs7 -inform DER -outform PEM -in sectigo.p7c -print_certs -out sectigo.pem && \
[[ "$(openssl x509 -in sectigo.pem -fingerprint -sha1 -noout)" = 'sha1 Fingerprint=CC:BB:F9:E1:48:5A:F6:3C:E4:7A:BF:8E:9E:64:8C:25:04:FC:31:9D' ]] && \
cat sectigo.pem >> /usr/share/dotnet/sdk/8.0.303/trustedroots/codesignctl.pem && \
rm -v sectigo.p7c sectigo.pem
To me it looks like this issue is resolved (at least as much resolved as we can do until the new SDK is released on August 13).
I would prefer to keep this issue open until then to keep on top of the list of issues for anyone else having the same problem. If nobody objects, I will close the issue after August 13.
In case someone is looking for a copy-paste solution for their dockerfile (this is for alpine, but should work in general):
RUN wget http://crt.sectigo.com/SectigoPublicCodeSigningRootR46.p7c -O sectigo.p7c && \ openssl pkcs7 -inform DER -outform PEM -in sectigo.p7c -print_certs -out sectigo.pem && \ [[ "$(openssl x509 -in sectigo.pem -fingerprint -sha1 -noout)" = 'sha1 Fingerprint=CC:BB:F9:E1:48:5A:F6:3C:E4:7A:BF:8E:9E:64:8C:25:04:FC:31:9D' ]] && \ cat sectigo.pem >> /usr/share/dotnet/sdk/8.0.303/trustedroots/codesignctl.pem && \ rm -v sectigo.p7c sectigo.pem
Thanks for sharing this script. I do want to remind everyone that you should always independently verify fingerprints of certificates that you are choosing to trust. As I've said previously, the easiest way to do that is to take a look at the thumbprint of the same certificate that is already trusted by your desktop environment.
Can be closed, with dotnet SDK 8.0.400 there is no longer an error
Which version of Duende IdentityServer are you using? 7.0.6
Which version of .NET are you using? .NET 8
Describe the bug
Getting warning NU3042 when building a project.
To Reproduce
Expected behavior
No warnings
Log output/exception with stacktrace
Additional context
We followed Security Notification (CVE-2024-39694) and upgraded to 7.0.6. Builds without warnings on Windows.