Trouble configuring wildcard domain of gitlab pages with TLS/SSL

How to Use GitLab
1

Having trouble to get wildcard domain of gitlab pages to work over https. I followed instructions at https://docs.gitlab.com/ee/administration/pages/2.

Http access is ok, but when using https I get an ERR_SSL_PROTOCOL_ERROR in Chrome. When doing curl, I get following error:

    ~$ curl -v https://xxx.wildcard.domain
    * Rebuilt URL to: https://xxx.wildcard.domain/
    *   Trying 1.1.1.2...
    * TCP_NODELAY set
    * Connected to xxx.wildcard.domain (1.1.1.2) port 443 (#0)
    * Unknown SSL protocol error in connection to xxx.wildcard.domain:-9838
    * Closing connection 0
    curl: (35) Unknown SSL protocol error in connection to xxx.wildcard.domain:-9838

I’m using Gitlab CE 10.1.0 omnibus installation on CentOS 6.8. My pages config is:

    pages_external_url "https://wildcard.domain/"
    nginx['listen_addresses'] = ['1.1.1.1']
    gitlab_pages['external_http'] = ['1.1.1.2:80']
    gitlab_pages['external_https'] = ['1.1.1.2:443']
    gitlab_pages['cert'] = "/etc/gitlab/ssl/wildcard.domain.crt"
    gitlab_pages['cert_key'] = "/etc/gitlab/ssl/wildcard.domain.key"
    pages_nginx['redirect_http_to_https'] = true
    pages_nginx['enable'] = false

Any hints how to troubleshoot this?

2

Anybody here to help me?

3

Well, 3 years later I’m facing the same problem, with almost the same settings as above.
On my example, gitlab-pages service can’t be loaded because nginx is listening all IP’s (although defined as above to listen only one IP).

After gitlab-ctl reconfigure, gitlab-pages is down
In the gitlab-pages logs:

{"level":"debug","listener":"1.1.1.2:80","msg":"Set up HTTP listener","time":"2021-03-20T16:12:07+01:00"}
{"error":"listen tcp 1.1.1.2:443: bind: address already in use","level":"fatal","msg":"could not create socket","time":"2021-03-20T16:12:07+01:00"}

Indeed, netstat is showing that nginx is listening 0.0.0.0:443 and 0.0.0.0:80 although in gitlab.rb is defined to listen own address.:

$ netstat -tlpune | grep nginx
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      0          587772189  2009025/nginx: mast 
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          587772188  2009025/nginx: mast

This looks as a bug to me, but it doesn’t look much that solution will be found on this place.