1

We have a private Gitlab instance that we plan on exposing externally, in order to ensure that only employees can connect to the website I have rolled out a small internal CA with user certs in order to have mutual auth. When I turn ssl_verify_client on it does what is expected on the web server side, if no cert (or invalid cert) is presented a 400 error is returned, if a valid cert is submitted then the page loads correctly.

What's weird is that it breaks Gitlab's ability to identify users based on their ssh key.

Example:

Site conf snippet:

ssl_certificate /usr/local/nginx/config/gitlab.chained.crt;
ssl_certificate_key /usr/local/nginx/config/gitlab.key;
ssl_client_certificate /usr/local/nginx/config/Root_CA.crt;
ssl_ciphers HIGH+aRSA:!kSRP;
ssl_prefer_server_ciphers on;
ssl_dhparam /usr/local/nginx/config/dh2048.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
#  ssl_verify_client on;
ssl_verify_depth 2;

User box:

% ssh git@gitlab
PTY allocation request failed on channel 0
Welcome to GitLab, [username]!
Connection to gitlab.domain.local closed.

Site conf snippet:

ssl_certificate /usr/local/nginx/config/gitlab.chained.crt;
ssl_certificate_key /usr/local/nginx/config/gitlab.key;
ssl_client_certificate /usr/local/nginx/config/Root_CA.crt;
ssl_ciphers HIGH+aRSA:!kSRP;
ssl_prefer_server_ciphers on;
ssl_dhparam /usr/local/nginx/config/dh2048.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_verify_client on;
ssl_verify_depth 2;

User box:

% ssh git@gitlab
PTY allocation request failed on channel 0
Welcome to GitLab, Anonymous!
Connection to gitlab.domain.local closed.

Can someone explain how this happens and how to fix it? I'm at a loss since they're completely different services surely? Unless there's something I'm missing and the shell handling ssh is making a connection through nginx which is failing. To be honest I don't completely understand how the gitlab architecture works with the integration between ssh, git and gitlab-shell. Maybe if I make this apply to just external connections then it will work? Would appreciate input before I shoot in the dark.

EDIT:

Okay, that is definately what is happening based on these entries in the gitlab-shell logs:

E, [2014-02-18T12:12:46.275674 #20681] ERROR -- : API call <GET https://gitlab.premiumsoftware.co.za//api/v3/internal/discover?key_id=2> failed: 400 => <<html>
<head><title>400 No required SSL certificate was sent</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>No required SSL certificate was sent</center>
<hr><center>nginx</center>
</body>
</html>
>.

The question is, is it better to give it a client cert to work with or modify the nginx conf so it only requires HTTPS from external IPs? I think the latter is better otherwise there is an SSL connection overhead that is unnecessary since it's only between services on the box.

0

I wrote a blog post on how I resolved the problem, you can read it here.

As a summary, I setup one nginx server to handle HTTPS connections external to the box (i.e. users browsing the web interface) and a second HTTP server that only listens on the localhost. I then configure gitlab-shell to use connect to http://localhost/ therefore bypassing the problem of HTTPS certificate errors.

| improve this answer | |
  • Linked page does not exist. – Martin York Jul 6 '17 at 20:45
0

I had the same error after moving our gitlab server to a new domain. The issue was resolved for me after editing /home/git/gitlab-shell/config.yml

The setting changed was the gitlab_url: "https://mynewdomain.com/" near the top of the file.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.