Docker-gitlab: Mixed HTTP / HTTPS content with Gitlab behind a reverse proxy

Created on 3 May 2017  路  19Comments  路  Source: sameersbn/docker-gitlab

I'm running sameersbn/docker behind a nginx reverse proxy, but I get a mixed content warning on the avatar image.

No matter what I try, it is either the mixed content warning or a too many redirects error page.
I forward my http traffic automatically in nginx with this config:

{
    listen 80;
    server_name myserver.com;
    return 301 https://myserver.com$request_uri;
}

server
{
    listen 443 ssl;
    server_name myserver.com;

    ssl on;
    ssl_certificate myserver.cert.combined;
    ssl_certificate_key myserver.key;
    include nginx_php.conf;

    location / {
       proxy_set_header X-Forwarded-Proto: https;
       proxy_set_header X-Forwarded-Ssl: on;
       proxy_pass http://127.0.0.1:10080;
       proxy_redirect off;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    include /etc/nginx/webapps.ssl.conf;
}

As soon as I run my gitlab container with the following options, I get the too many redirects

- GITLAB_HTTPS=true
- SSL_SELF_SIGNED=false

- GITLAB_HOST=myserver.com
- GITLAB_PORT=443
- GITLAB_SSH_PORT=22

What am I doing wrong here? And why does Gitlab try to load the avatar over http?

wontfix

Most helpful comment

@sprucify perhaps to help you out, I was faced with the same behavior and managed to solve it.

The issue on my end was that the default SSL_CERTIFICATE_PATH, SSL_KEY_PATH and SSL_DHPARAM_PATH were not pointing to the right certificate, key and dhparam respectively. Fixing this stopped the redirects.

Hope this helps you out!

All 19 comments

I remember having this issue as well since I use NGINX as a load balancer with forward facing HTTPS (with HTTP/2 and HSTS) with gitlab traffic over HTTP -- let me track down what I changed in order to force gravatar over HTTPS and I'll edit.


Looks like I just got rid of Gravatar altogether (since my NGINX install is controlled by a third-party GUI).
If you are able to, have you tried following this: https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl

I am using GitLab behind an nginx reverse proxy as well and it works fine (it uses the https://secure.gravatar.com/ domain).

My configuration (docker-compose.yml) is as yours:

- GITLAB_HTTPS=true
- SSL_SELF_SIGNED=false

- GITLAB_HOST=myserver.com
- GITLAB_PORT=443
- GITLAB_SSH_PORT=22

My nginx config looks like this:

        location / {
                proxy_set_header    Host                $host;
                proxy_set_header    X-Real-IP           $remote_addr;
                proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
                proxy_set_header    X-Forwarded-Proto   $scheme;

                proxy_set_header X-Forwarded-Ssl on;
                proxy_pass http://gitlab;
        }

I am not sure if the : character might confuse Gitlab making it not recognising the headers.

Note: I defined a backend called gitlab 馃槈

I put them in the same order and removed the : character, but no luck.
Too many redirects.

@frostieDE How is your nginx port 80 entry look like? Do you have a redirect there?

Sorry, this is my complete nginx configuration for GitLab:

upstream gitlab {
        server 127.0.0.1:10080;
}

server {
        server_name git.example.com;
        listen  80;
        listen  [::]:80;
        return  301 https://$host$request_uri;
}

server {
        server_name git.example.com;

        listen  443 ssl http2;
        listen  [::]:443 ssl http2;

        ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;

        ssl_ciphers                     "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256";
        ssl_dhparam                     /etc/ssl/private/dhparams.pem;
        ssl_prefer_server_ciphers       on;

        ssl_session_cache               shared:SSL:10m;
        ssl_session_timeout             5m;

        # OCSP
        ssl_stapling on;
        ssl_stapling_verify on;
        resolver 8.8.4.4 8.8.8.8 valid=300s;
        resolver_timeout 30s;

        root /usr/share/nginx/html/;

        ssl_certificate /etc/letsencrypt/live/git.example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/git.example.com/privkey.pem;

        location / {
                proxy_set_header    Host                $host;
                proxy_set_header    X-Real-IP           $remote_addr;
                proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
                proxy_set_header    X-Forwarded-Proto   $scheme;

                proxy_set_header X-Forwarded-Ssl on;
                proxy_pass http://gitlab;
        }
}

Note: I am using own server directives for each of my webservice. According to your nginx configuration for GitLab, you include other web apps and even php which isn't necessary ;-) This may not have anything to do with your problem but it's common (and good) practise :-)

Maybe it would be useful if you paste the (sanitised!) contents of nginx_php.conf and webapps.ssl.conf ;-)

This is my latest version of nginx conf.
Still no luck.

  ```
  server
  {
    server_name gitlab.myserver.nl www.gitlab.myserver.nl;
    listen _myserverIP_:80;

    return 301 https://$host$request_uri;
  }

  server
  {
    server_name gitlab.myserver.nl www.gitlab.myserver.nl;
    listen _myserverIP_:443 ssl;

    access_log /var/log/nginx/domains/myserver.nl.log;
    access_log /var/log/nginx/domains/myserver.nl.bytes bytes;
    error_log /var/log/nginx/domains/myserver.nl.error.log;


    ssl on;
    ssl_certificate /usr/local/directadmin/data/users/myserver/domains/myserver.nl.cert.combined;
    ssl_certificate_key /usr/local/directadmin/data/users/myserver/domains/myserver.nl.key;
    #include /usr/local/directadmin/data/users/myserver/nginx_php.conf;

    location / {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto https;

            #proxy_redirect off;

            proxy_set_header X-Forwarded-Ssl on;
            proxy_pass http://127.0.0.1:10080;
    }

    #include /etc/nginx/webapps.ssl.conf;
 }
 ```

I noticed you don't have ssl on; option probably they turn that on if you specify the protocols?

As of the nginx documentary, it is recommended to use the ssl parameter within the listen directiveinstead ofssl on;`. But I doubt that this causes your behaviour.

Does this behaviour occur when using other browsers? Have you tried clearing all cookies for your GitLab domain? (seems stupid but I was having some redirecting issues because of that in other web applications...)

Also, I assume you are using the latest version of GitLab and nginx :wink:

Yep I'm on Nginx 1.12.0 and Gitlab 9.1.2
I did clean my cookies multiple times, but I'm wondering if the redirects are stored in there.

I can not believe I'm the only person with this issue?
I keep seeing the "too many redirects" error page

Seems odd to me, too. I am successfully running two GitLab instances behind an nginx...

Did you some sort of debugging? Does it always redirect to the same page or does pageA redirect to pageB which redirects to pageA again? Maybe you can post the full HTTP response.

Did you provide any SSL certificate paths in your docker-compose.yml?

@sprucify yeah I'm facing the same behavior, so you're not alone. Looking into it right now.

@sprucify perhaps to help you out, I was faced with the same behavior and managed to solve it.

The issue on my end was that the default SSL_CERTIFICATE_PATH, SSL_KEY_PATH and SSL_DHPARAM_PATH were not pointing to the right certificate, key and dhparam respectively. Fixing this stopped the redirects.

Hope this helps you out!

You mean paths in your docker-compose.yml? Or in nginx.conf?

The paths in docker-compose.yml are more interesting, I guess :wink: Did you provide any of them there?

I placed /users/sign_in behind my URL and discovered that the "too many redirects" error was gone.
That pointed my to the direction of checking my gitlab settings after I managed to login and discovered that my Homepage was set to a http url instead of https.

Would be nice if Gitlab changed that automatically when you use HTTPS = true.

@niksubramanian pointed out those three variables SSL_CERTIFICATE_PATH, SSL_KEY_PATH and SSL_DHPARAM_PATH, and here they go again:

(not sure if it is really related but I think this could help some people a bit)
https://github.com/sameersbn/docker-gitlab/issues/1248

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.

Was this page helpful?
0 / 5 - 0 ratings