0

Dear serverfault community,

I have recently installed bundled GitLab on my VPS running Ubuntu14.04. To get it running, I have used nginx, which is routing one particular subdomain to GitLab over http. So far so good, it works fine and does not collide with another services installed, i.e. Taiga.io.

Since it is a very bad idea to not use https, I've decided to change that - I've used Let's Encrypt to get certificates for my domains and subdomains, and then set it up accordingly. Taiga.io went fine without any trouble, and then I proceeded to GitLab.

Unfortunately, when trying to set up https on GitLab, I have 502 Bad Gateway nginx/1.4.6 (Ubuntu) error.

Here is my setup:

/etc/gitlab/gitlab.rb:
external_url 'https://gitlab.example.com:8090'
nginx['enable'] = false

/opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml:
host: gitlab.example.com
port: 8090
https: true

/etc/ngingx/sites-enabled/gitlab:
server {
    listen 80;
    server_name gitlab.example.com;
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name gitlab.example.com;

    large_client_header_buffers 4 32k;
    client_max_body_size 50M;
    charset utf-8;

    access_log /opt/gitlab/logs/nginx.access.log;
    error_log /opt/gitlab/logs/nginx.error.log;

    location / {
        proxy_pass http://127.0.0.1:8090;
        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;
    }
    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
    # This line was taken from another config file, not sure if those pins shouldn't be changed or something?
    add_header Public-Key-Pins 'pin-sha256="klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY="; pin-sha256="633lt352PKRXbOwf4xSEa1M517scpD3l5f79xMD9r9Q="; max-age=2592000; includeSubDomains';

    ssl on;
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK';
    ssl_session_cache shared:SSL:10m;
    ssl_dhparam /etc/ssl/dhparam.pem;
    ssl_stapling on;
    ssl_stapling_verify on;
}

I was thinking, every tutorial on this is suggesting setting the port to 443 (obviously), but I think that this not should be the case here, since I am redirecting from 443 to :8090 in nginx anyway. Am I missing something?

Best regards!

Filip

=================

EDIT:

I see that sudo netstat -plutn is not showing anything listening on 8090. It looks like I have messed up something with config files I suppose? I will look forward into that.

olhur
  • 3
  • 4
  • GitLab Omnibus has its own bundled nginx server, which you should use instead of the one shipped with Ubuntu. It's perfectly capable of using Let's Encrypt certificates. I have such a setup myself. – Michael Hampton Aug 28 '16 at 00:12

2 Answers2

0

The gitlab configuration thinks it will receive https traffic but the nginx config is speaking http to it. Change the https references in the gitlab config files to http and all should be well. This will not impact what nginx speaks to clients (https).

Jonah Benton
  • 1,242
  • 7
  • 13
  • Unfortunately, that is not the solution. The only reference here is `external_url 'https://gitlab.example.com:8090'`, and I have changed it + done `sudo gitlab-ctl reconfigure; sudo gitlab-ctl restart; sudo service nginx restart` and it seems to not change anything, even on guest session (to avoid any caching). – olhur Aug 27 '16 at 22:09
  • But! I see that `sudo netstat -plutn` is not showing anything listening on 8090. It looks like I have messed up something with config files I suppose? – olhur Aug 27 '16 at 22:11
  • Look also at https: true in the gitlab rails yaml. Changing that to false may enable gitlab to listen for http on 8090. – Jonah Benton Aug 27 '16 at 22:15
  • It looks like the https: true in yml file is changed automatically after `reconfigure` command after the previous change. Still nothing. – olhur Aug 27 '16 at 22:26
  • Ok, after some messing around, it seems that your solution, along with enabling built-in nginx, made it work. Thank you! – olhur Aug 27 '16 at 22:29
  • Great, glad to hear it. – Jonah Benton Aug 27 '16 at 22:34
0

On gitlabs website there is a guide on how you set it up with non-bundled webserver. http://docs.gitlab.com/omnibus/settings/nginx.html#using-a-non-bundled-web-server shows you the required changes for the gitlab configuration. Have you set 'web-server['external_users'] to your nginx user?. They also have a ready nginx.conf that you can add as a virtualhost. https://gitlab.com/gitlab-org/gitlab-recipes/blob/master/web-server/nginx/gitlab-omnibus-ssl-nginx.conf , it proxy_passes to a unix socket instead of through tcp.

sebastian
  • 46
  • 4