Nuget (v2) redirects to `http` URL when running `chocolatey install` with authenticated repo

Sonatype Nexus Repository
1

Good afternoon!

I’m trying to sort out why my Nexus OSS v3 instance (running from Docker, in AWS, behind CloudFront SSL termination) is handing out http links (redirects?) when chocolatey is trying to pull custom packages from from an authenticated Nuget v2 group.

PS C:\Windows\system32> choco install -y my-package -s='https://my-distribution.cloudfront.net/repository/chocolatey-TEST-group/' --debug --verbose
Chocolatey v1.1.0
Chocolatey is running on Windows v 10.0.22621.0
[...]
Installing the following packages:
my-package
By installing, you accept licenses for the packages.
Using 'https://my-distribution.cloudfront.net/repository/chocolatey-TEST-group/'.
Attempting to gather credentials for 'https://my-distribution.cloudfront.net/repository/chocolatey-TEST-group/'
Asking user for credentials for 'https://my-distribution.cloudfront.net/repository/chocolatey-TEST-group/'
Please provide credentials for: https://my-distribution.cloudfront.net/repository/chocolatey-TEST-group/
User name: choco-readonly
Password: **************************************
[...]
Asking user for credentials for 'http://my-distribution.cloudfront.net/repository/chocolatey-TEST-group/my-package/1.2.3.4.5'
Please provide credentials for: http://my-distribution.cloudfront.net/repository/chocolatey-TEST-group/my-package/1.2.3.4.5
User name:

As you can see in the last few lines above, while the source is https, there’s a redirect or response in the nuget V2 payload that returns an (invalid) http URL. Not surprisingly, this doesn’t work and I can’t install the package.

The CloudFront distribution is configured as indicated in the docs for ReverseProxySSLTerminationatBasePath, that is, I’ve added the X-Forwarded-Proto: https header to the distribution config. I’ve also added the Base URL capability in the Nexus System configuration - this is set to https://my-distribution.cloudfront.net.

Things tried:

  1. Create a CloudFront invalidation to clear anything cached
  2. Invalidate cache / re-index, respectively, on the group/hosted/proxy nuget repos in Nexus
  3. Delete & re-create the repos & re-publish the package

I’m out of ideas. Everything works as expected, sans https when hitting the direct origin URL of the Nexus docker instance/container.

Any sage advice would be appreciated.

Cheers,
Brice

2

Since SSL is terminated outside of Nexus Repo you need to configure the reverse proxy in front of it to send the “X-Forwarded-Proto” header with value “https”. This will let Nexus Repo know it should return https URL’s.

https://help.sonatype.com/display/NXRM3/Run+Behind+a+Reverse+Proxy#RunBehindaReverseProxy-Example:ReverseProxySSLTerminationatBasePath

3

Agreed, that should do the trick, which is why I mentioned doing that in my original post, as it was the only reference I could find in the Nexus 3 docs.

And yet … the issue persists. So, either this is a bug that nobody else has noticed because they aren’t using authenticated NuGet v2 repos on Nexus 3 or there’s some other setting missing (I really hope it’s the latter).

4

Suggest checking to see if the header is actually reaching Nexus Repo. You can do that by changing the request.log’s pattern.

Edit the $installdir/etc/logback/logback-access.xml file and change this line…

FROM

<pattern>%clientHost %l %user [%date] "%requestURL" %statusCode %header{Content-Length} %bytesSent %elapsedTime "%header{User-Agent}"  [%thread]</pattern>

TO

<pattern>%clientHost %l %user [%date] "%requestURL" %statusCode %header{Content-Length} %bytesSent %elapsedTime "%header{User-Agent}" "%header{X-Forwarded-Proto}"  [%thread]</pattern>
5

Yeah, that was suggested by a colleague this morning, too - I’m going to run a tcpdump because it’s a little easier than modifying what’s running in the Docker container.

6

Mea culpa. It turns out it wasn’t … inconsistently. If you read this post you’ll see mention of this bit towards the end:

:exploding_head: :exploding_head: :exploding_head:

My tcpdump captured this behavior as well. Crazy. So, how to fix? Well, we removed X-Forwarded-Proto in exchange for Forwarded: proto=https and this does reach the Nexus 3 container and, bonus, has the desired effect.

So, for now, it seems, problem solved. Thanks for making something super simple like always forwarding a statically configured Origin header, intermittently fail, Amazon. :rage:

@rseddon - thx for your time. Appreciate the responses to keep this moving forward.

7

Thanks for letting us know the cause. That was a tricky one!

Rich

1 Like