1

I deployed new private NuGet server (NuGet.Server.3.4.1) and set up API key in web.config.

Then I created first nuget package from my .net core class library project.

But when I try to run following command

dotnet nuget push packageName.1.0.0.nupkg --api-key myKey --source https://privateNugetServer.com/nuget

I get an error from the server

error: Response status code does not indicate success: 502 (Bad Gateway).

I tried workaround when I uploaded package manually with Nuget server itself, but than I still got this error when I add additional Package source to visual studio nuget manager pointing to my server.

error: Response status code does not indicate success: 502 (Bad Gateway).

What might be an issue ?

Muflix
  • 6,192
  • 17
  • 77
  • 153
  • 1
    How long does it take for error to occur. You may be going to a proxy server and the net library waits 30 seconds to timeout waiting for a response from the proxy. Did code ever work? When did it stop working? Five years ago industry decided to stop using TLS 1.0/1.1 for authentication and instead use TLS 1.2/1.3. Microsoft pushed a security update in June for servers to disable TLS 1.o/1.1. If a client is still using TLS 1.0/1.1 an error will occur. So you may still be using old TLS. Use a sniffer like wireshark or fiddler and verify version of TLS – jdweng Sep 17 '20 at 11:48
  • Thank you for the tip. The nuget server (website) is brand new, so it has no working history yet. The error occure immediately. The connection use `TLS 1.2, AES with 256 bit encryption (High); ECDH with 255 bit exchange` so it should be ok, but there might be an issue with corporate proxy. I don't know yet, but I will investigate it further. – Muflix Sep 17 '20 at 11:56
  • Do you need the proxy? Does server want TLS 1.3 instead of 1.2? I've seen a case this week where TLS worked and TLS 1.2 failed. Does query work in Postman? If so, you can compare the Postman and c# to see differences. – jdweng Sep 17 '20 at 12:47
  • I forgot about this question. But I think the reason was the corporate proxy and we had to allow the Azure DevOps URL. I think the proxy decrypted the request and encrypted it again and that invalidated the certificate chain and the server threw an error. – Muflix Jul 18 '23 at 09:21

0 Answers0