Docker-gitlab: GITLAB_HTTPS, SSL_CERTIFICATE_PATH and mixed content issue

[hoto]

Hi,

We have HaProxy which handles all http and https requests and have all SSL certs.
Gitlab container is exposing only port 22 and 80. It looks like this:

HaProxy [80] (redirects to https) -> Haproxy[443]
HaProxy[443] (drops ssl) -> Gitlab(Nginx)[80] -> (returns the content to the browser)

We had this problem with mixed content when loading avatarts and build logs.

Avatarts requests were redirected from http to https by haproxy and were resolved by the browser so it was fine (just warnings)

But the build logs json files requests over http were blocked by the browser as they are XMLHttpRequest requests and browsers does not let you make XMLHttpRequest to http if page is loaded over https.
Haproxy did not even received that http request as browser was cancelling it.

Command that I tried first to spawn gitlab (I removed stuff that is not related):

/usr/bin/docker run \
  -p 22:22 \
  --link redis:redisio \
  -e 'GITLAB_HOST=gitlab.mydomain.com' \
  -e 'GITLAB_HTTPS=true' \
  --volume-driver=convoy \
  -v gitlab_mgmt:/home/git/data/ \
  -v gitlab_log_mgmt:/var/log/gitlab \
  -v gitlab_certs:/certs \
  --name=gitlab \
  sameersbn/gitlab:9.2.2

Command that we use NOW to spawn gitlab (I removed stuff that is not related):

/usr/bin/docker run \
  -p 22:22 \
  --link redis:redisio \
  -e 'GITLAB_HOST=gitlab.mydomain.com' \
  -e 'GITLAB_HTTPS=true' \
  -e 'SSL_CERTIFICATE_PATH=/this_path_must_not_exits_for_https_to_work_properly' \
  -e 'SSL_KEY_PATH=/this_path_must_not_exits_for_https_to_work_properly' \
  -e 'SSL_DHPARAM_PATH=/this_path_must_not_exits_for_https_to_work_properly' \
  --volume-driver=convoy \
  -v gitlab_mgmt:/home/git/data/ \
  -v gitlab_log_mgmt:/var/log/gitlab \
  -v gitlab_certs:/certs \
  --name=gitlab \
  sameersbn/gitlab:9.2.2

PROBLEM IS:

If I just set GITLAB_HTTPS=true and omit UNSETING (or setting them to a path that does not exist) SSL_CERTIFICATE_PATH SSL_KEY_PATH SSL_DHPARAM_PATH then /etc/nginx/sites-enabled/gitlab nginx configuration file is wrong (in our use case) because of this nested if statement:
https://github.com/sameersbn/docker-gitlab/blob/master/assets/runtime/functions#L1307

SSL_CERTIFICATE_PATH SSL_KEY_PATH SSL_DHPARAM_PATH are being set to default values here:
https://github.com/sameersbn/docker-gitlab/blob/master/assets/runtime/env-defaults#L131

There are some (default) files in the location those three variables are pointing when you start the container so the wrong nginx configuration file was being copied (which redirects calls from port 80 to 443). This makes an infinite loop of 301 redirects when I tried our gitlab external url. It looked something like this:

HaProxy[443] (drops ssl) -> Gtilab(Nginx)[80] (Nginx now redirects to 443) -> Haproxy[443] -> (drops ssl) -> Gtilab(Nginx)[80] -> the cycle continue indefinitely...

I set those three variables to a folder that does not exist (as can be seen in the docker run command above) and the mixed content warnings/errors disappeared and everything seems to be working fine. Now the right (for our use case) nginx config file is being copied by the functions shell script (which now makes nginx to serve on port 80 only).

[avluis]

This explains why my configuration was not working properly when following the instructions -- great to know that this will correct the default behavior so thanks for posting this with so much detail~

[Coffee2CodeNL]

I don't see such behaviour.

Don't set the SSL_CERTIFICATE_PATH, SSL_KEY_PATH and SSL_DHPARAM_PATH but do set the GITLAB_HTTPS parameter.

That'll set the scheme for gitlab to https:// but it only listens on port 80, which allows your reverse proxy to handle SSL.

[Coffee2CodeNL]

Check out my fork, and keep checking it out, since I'll add an Envvar tomorrow to fix this issue, after studying it a bit closer I see what you mean... 😅

[hoto]

First thing I did was to set GITLAB_HTTPS=true and set nothing else.
Then we had this 301 infinite loop in the browser when I hit our gitlab page.
So I checked docker exec gitlab cat /etc/nginx/sites-enabled/gitlab and that nginx config was redirecting all calls from port 80 to 443.

So I pulled the source code of this project and looked what is going on.
I noticed that nested if statement and changed SSL_CERTIFICATE_PATH, SSL_KEY_PATH and SSL_DHPARAM_PATH to a path that does not exist (I would unset them but it was easier to set them to something that does exists) and everything started to work.
I checked docker exec gitlab cat /etc/nginx/sites-enabled/gitlab and the nginx config was different, it just served on port 80.

[Coffee2CodeNL]

Does this help?

https://github.com/iSDP/docker-gitlab-dokku/commit/53d6e0ea5055ad651622e4047d663430e2b4e0d4

[frakman1]

How would you workaround this issue if you are using the Omnibus package installation and not using docker?

[stale[bot]]

This issue has been automatically marked as stale because it has not had any activity for the last 60 days. It will be closed if no further activity occurs during the next 7 days. Thank you for your contributions.

[JohnStarich]

From what I can tell, the /this_path_must_not_exist hack is still required.

Is this really a “won’t fix”?

[solidnerd]

Hey @JohnStarich,
I think our default label needs to be changed to something that it's not looking like an action. It should be something like stale or rotten. We enabled this only to get rid of not active issues because this project is a little bit older now these days and I hope from this that it will help us to see which issues still persist or need help from us by now.

I will look into this issue and try to help with a solution thanks for letting this issue open. :+1:

[flavienbwk]

I can exactly reproduce this issue. Upgrading from 12.7.7 to 12.9.5.