Gitlab ce on ubuntu 16.04 with letsencrypt on subdomain

Question

I installed gitlab-ce on my v-server running Ubuntu 16.04 with apache as webserver. The installation of gitlab under git.example.com worked and I was able to setup my user via http.

I'm running my example.com website, a nextcloud instance under cloud.example.com and gitlab under git.example.com on this server and I decided to use letsencrypt.

The installation of letsencrypt for example.com and cloud.example.com works fine. I used the Gitlab Recipes for configuration, but it doesn't work properly. When I try to access gitlab under http://git.example.com the redirection to https://git.example.com does work but the https part redirects me to http://example.com and I have no idea why.

This is the server response

Request URL:https://git.example.com/
Request Method:GET
Status Code:302 Found
Remote Address:*:443
Referrer Policy:no-referrer-when-downgrade
HTTP/1.1 302 Found
Date: Sat, 03 Mar 2018 10:36:24 GMT
Server: Apache/2.4.18 (Ubuntu)
Cache-Control: no-cache
Content-Type: text/html; charset=utf-8
Location: http://example.com
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Request-Id: bdfffb7e-1c89-4308-be13-5c35a64f31f3
X-Runtime: 0.010298
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Content-Length: 90
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

And these are my apache config files:

<VirtualHost git.example.com:80>
  ServerName git.example.com
  DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public/
  ServerSignature Off

  RewriteEngine on
  RewriteCond %{HTTPS} !=on
  RewriteCond %{SERVER_NAME} =git.example.com
  RewriteCond %{REQUEST_URI} !^/.well-known/.*
  RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [NE,R,L]

</VirtualHost>

SSL

<IfModule mod_ssl.c>
<VirtualHost git.example.com:443>
    SSLEngine on
    SSLCipherSuite    SSLv3:TLSv1:+HIGH:!SSLv2:!MD5:!MEDIUM:!LOW:!EXP:!ADH:!eNULL:!aNULL
    SSLCertificateFile /etc/letsencrypt/live/git.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/git.example.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf

    ServerName git.example.com
    ServerSignature Off
    ProxyPreserveHost On
    ProxyPass / https://localhost:8181/
    ProxyPassReverse / https://git.example.com:8181/

    # http://doc.gitlab.com/ce/api/projects.html#get-single-project
    AllowEncodedSlashes NoDecode

    <Location />
        # Apache 2.2
        Order allow,deny
        Allow from all

        # New authorization commands for apache 2.4 and up
        # http://httpd.apache.org/docs/2.4/upgrading.html#access
        Require all granted
        ProxyPassReverse http://127.0.0.1:8181
        ProxyPassReverse http://git.example.com/
    </Location>

    <Directory /opt/gitlab/embedded/service/gitlab-rails/public/>
       Require all granted
    </Directory>

    # needed for downloading attachments
    DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public/

    RewriteEngine on

    # Apache equivalent of nginx try files
    RewriteCond %{DOCUMENT_ROOT}/{REQUEST_FILENAME} !-f [OR]
    RewriteCond %{REQUEST_URI} ^/uploads/.* [OR]
    RewriteCond %{REQUEST_URI} !/\.well-known/.*
    RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]

    RequestHeader set Host "git.example.com"
    RequestHeader set X-Forwarded-Ssl on
#    RequestHeader set X-Forwarded-For %<span class="pl-s1"><span class="p1-    pse">{</span>REMOTE_ADDR<span class="ps1-pse">}</span></span>e  
    RequestHeader set X_FORWARDED_PROTO 'https'

    #Set up apache error documents, if back end goes down (i.e. 503 error) then a maintenance/deploy page is thrown up.
    ErrorDocument 404 /404.html
    ErrorDocument 422 /422.html
    ErrorDocument 500 /500.html
    ErrorDocument 502 /502.html
    ErrorDocument 503 /503.html

    # It is assumed that the log directory is in /var/log/httpd.
    # For Debian distributions you might want to change this to
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>
</IfModule>

In production.log I found this

Started GET "/" for 93.200.218.17 at 2018-03-03 11:34:31 +0100
Processing by RootController#index as HTML
Redirected to http://example.com
Filter chain halted as :redirect_unlogged_user rendered or redirected
Completed 302 Found in 4ms (ActiveRecord: 0.0ms)

But searching for this didn't help me so far. I guess there's some kind of loop where apache decides to root to domain.net but I couldn't find the source of it.

If anyone has an idea where to look for the error or can see what's wrong with my configuration I'd be grateful.

Answer to

curl -v http://127.0.0.1:8181

was:

> GET / HTTP/1.1
> Host: 127.0.0.1:8181
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 302 Found
< Cache-Control: no-cache
< Content-Type: text/html; charset=utf-8
< Date: Mon, 05 Mar 2018 09:58:40 GMT
< Location: http://example.com
< X-Content-Type-Options: nosniff
< X-Frame-Options: DENY
< X-Request-Id: 17cb8d7d-918f-4d72-95ca-f6262e7537b2
< X-Runtime: 0.015595
< X-Ua-Compatible: IE=edge
< X-Xss-Protection: 1; mode=block
< Content-Length: 90
<
* Connection #0 to host 127.0.0.1 left intact

Update 1

I checked what's redirecting on the Port 8181 but I only got this:

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
gitlab-wo 312  git    3u  IPv4 188680      0t0  TCP localhost:8181 (LISTEN)

So I believe that there is some configuration error in Gitlab itself

These answers might help https://stackoverflow.com/q/19456129/1145196 — Dusan Bajic, Mar 03 '18 at 14:05
I don't understand which part of this answer might help me. Could you be more specific on what part might be the answer to my problem? Thanks. — OLF, Mar 03 '18 at 15:42
Perhaps your GitLab is configured with wrong hostname? (that might cause such redirects) — Dusan Bajic, Mar 03 '18 at 15:51
I checked it. The hostname is git.example.com in every config. Ans as well in the gitlab.rb — OLF, Mar 04 '18 at 17:36
What is the response if you directly in the instance shell try `curl -v http://127.0.0.1:8181`? — Dusan Bajic, Mar 04 '18 at 19:29
From the curl response `302 Found`, `Location: http://example.com` you can see that the redirect comes form the application running on port 8181 (because the above request bypasses apache) — Dusan Bajic, Mar 06 '18 at 08:10
Please post your solution as an answer of its own, not as an edit. — Cœur, Apr 22 '18 at 17:57

score 0 · Answer 1 · answered Apr 22 '18 at 20:29

Solution I found a hint at https://serverfault.com/questions/721698/gitlab-redirects-to-other-page and that really was the problem...

The settings of gitlab itself were wrong. THe Sign-in restrictions got http://git.example.com so I had to login with the direct link git.example.com/users/sign_in and change my settings. Now it's working.

Thanks to Dusan Bajic.

Addition

What also was a problem was, that the settings for "Home page URL" was set to my main domain. I had to change that to https://git.example.com. A simple setting I just forgot

Gitlab ce on ubuntu 16.04 with letsencrypt on subdomain

1 Answers1