Error NU1301 instead of "TLS validation failed" displays when running ‘dotnet restore’ before TLS certificate validation is disabled

[v-luzh]

NuGet Product Used

dotnet.exe

Product Version

dotnet SDK 8.0.400-preview.0.24324.5

Worked before?

It’s not a regression since it is a new feature.

Impact

It bothers me. A fix would be nice

Repro Steps & Context

Repro Steps:

1. Create a C# Console App (.NET 8.0) project.
2. In the solution folder, create a file named nuget.config with the following content:

   <?xml version="1.0" encoding="utf-8"?>
   <configuration>
   <packageSources>
   <clear />
   <add key="mySource" value="https://127.0.0.1:44444/v3/index.json"/>
   </packageSources>
   </configuration>

3. Open the .csproj file for your project and insert the following package reference within an ItemGroup:

   <ItemGroup>
   <PackageReference Include="abcdefghijkl" Version="1.0.0" />
   </ItemGroup>

4. Open a command prompt and navigate to the solution directory.
5. Open a second command prompt window, download the Entropy/filebackedserver and go to the ‘filebackedserver’ solution directory and build the server by running: dotnet build .\filebackedserver\filebackedserver.csproj
6. Start the local server by executing: dotnet run --project .\filebackedserver\filebackedserver.csproj
7. Switch back to the first terminal where your original project is located and run: dotnet restore
8. Modify the nuget.config file to disable TLS certificate validation as follows and run dotnet restore again.

   <?xml version="1.0" encoding="utf-8"?>
   <configuration>
   <packageSources>
   <clear />
   <add key="mySource" value="https://127.0.0.1:44444/v3/index.json" disableTLSCertificateValidation="true"/>
   </packageSources>
   </configuration>

Expected Result:

Error "TLS validation failed" should be displayed in the first command prompt in step7.

Actual Result:

Error NU1301 displays in the first command prompt as the screenshot below in step7.

Notes:    

1. The repro rate is 100%.

Verbose Logs

No response

[Nigusu-Allehu]

From the error, what I can understand is that dotnet was trying to make a connection with the source but the source was not available. Could you please make sure both consoles are running simultaneously: one where you run the server and another one where you are performing dotnet restore? Please don't close the console where you are running the server until the testing is complete. If the problem persists, could you please provide me with a screenshot of both consoles side by side after executing the restore command?

[zivkan]

@Nigusu-Allehu that error message is displayed for any reason the service index can't be loaded. The connection being rejected is one reason, but TLS failing is possible. If the server used a hostname, rather than IP address, then that DNS failure could also be a possibility. TCP connection timeout. I think if the service index is not valid JSON, the same error message will be displayed in restore as well.

I'm pretty sure we have a duplicate issue about this somewhere, I just can't find it at the moment.

On the other hand dotnet add package will show ProtocolException's inner exception, so it will tell you exactly why the service index failed to load.

[zivkan]

ok, I found the duplicate:

• https://github.com/NuGet/Home/issues/12530

[Nigusu-Allehu]

That’s a good point. However, I did the testing myself and the TLS errors are clearly logged during restore.

[v-luzh]

From the error, what I can understand is that dotnet was trying to make a connection with the source but the source was not available. Could you please make sure both consoles are running simultaneously: one where you run the server and another one where you are performing dotnet restore? Please don't close the console where you are running the server until the testing is complete. If the problem persists, could you please provide me with a screenshot of both consoles side by side after executing the restore command?

Hi @Nigusu-Allehu, yes, I didn't close any console until the testing is completed. I have attached the screenshot below for your investigation.

[Nigusu-Allehu]

Is the second execution after adding disableTLSCertificateValidation=true by the way? As @zivkan mentioned, it seems that the exact error is being obscured by the 'Unable to load the service index' message. We should update the expected output in the manual test instructions to state: if disableTLSCertificateValidation="true", then expect success; otherwise, expect failure.

[v-luzh]

@Nigusu-Allehu, no we didn't set the allowInsecureConnections=true when executing the test. Where should we add the setting: allowInsecureConnections=true? Is that the necessary step in the testing?

[Nigusu-Allehu]

Oh my bad, I meant to write disableTLSCertificateValidation="true"

[Nigusu-Allehu]

Is the second execution after adding disableTLSCertificateValidation=true by the way? As @zivkan mentioned, it seems that the exact error is being obscured by the 'Unable to load the service index' message. We should update the expected output in the manual test instructions to state: if disableTLSCertificateValidation="true", then expect success; otherwise, expect failure.

@v-luzh , what do you think?

[v-luzh]

@Nigusu-Allehu Yes, in the second execution, the info under the 3rd line will display after adding disableTLSCertificateValidation=true. The screenshot below would show it more clearly.

[Nigusu-Allehu]

Thank you. Then, as I mentioned previously, it seems that the exact error is being obscured by the 'Unable to load the service index' message. We should update the expected output in the manual test instructions to state:	operation	checkpoint
run dotnet restore without disableTLSCertificateValidation="true"	This should result in a "TLS validation failed" error or "Unable to load the service index" error.
Modify the nuget.config file to disableTLSCertificateValidation="true" Run dotnet restore again	This time, restore should succeed without TLS errors.