У нас есть частный экземпляр Gitlab, который мы планируем раскрыть извне, чтобы гарантировать, что только сотрудники могут подключаться к веб-сайту. Я развернул небольшой внутренний центр сертификации с пользовательскими сертификатами, чтобы иметь взаимную аутентификацию. Когда я включаю ssl_verify_client, он делает то, что ожидается на стороне веб-сервера, если сертификат (или недействительный сертификат) не представлен, возвращается ошибка 400, если действительный сертификат отправлен, страница загружается правильно.
Что странно, так это то, что это нарушает способность Gitlab идентифицировать пользователей на основе их ssh-ключа.
Пример:
Фрагмент конфигурации сайта:
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;
Ящик пользователя:
% ssh git@gitlab
PTY allocation request failed on channel 0
Welcome to GitLab, [username]!
Connection to gitlab.domain.local closed.
Фрагмент конфигурации сайта:
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;
Ящик пользователя:
% ssh git@gitlab
PTY allocation request failed on channel 0
Welcome to GitLab, Anonymous!
Connection to gitlab.domain.local closed.
Может кто-нибудь объяснить, как это происходит и как это исправить? Я в недоумении, ведь это совершенно разные услуги? Если что-то мне не хватает, и оболочка, обрабатывающая ssh, не устанавливает соединение через nginx, что дает сбой. Если честно, я не совсем понимаю, как архитектура gitlab работает с интеграцией между ssh, git и gitlab-shell. Может быть, если я сделаю это применимо только к внешним соединениям, тогда это сработает? Буду признателен за ввод, прежде чем снимать в темноте.
Хорошо, это определенно то, что происходит на основе этих записей в gitlab-shell журналы:
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>
>.
Вопрос в том, лучше ли предоставить ему сертификат клиента для работы или изменить конфигурацию nginx, чтобы он требовал HTTPS только от внешних IP-адресов? Я думаю, что последнее лучше, иначе есть накладные расходы на SSL-соединение, которые не нужны, поскольку они только между службами на коробке.
У меня была такая же ошибка после перемещения нашего сервера gitlab в новый домен. Проблема была решена для меня после редактирования /home/git/gitlab-shell/config.yml
Изменилась настройка gitlab_url: "https://mynewdomain.com/" в верхней части файла.
Я написал сообщение в блоге о том, как я решил проблему, вы можете прочитать его Вот.
Подводя итог, я настраиваю один сервер nginx для обработки HTTPS-подключений, внешних по отношению к ящику (т.е. пользователей, просматривающих веб-интерфейс), и второй HTTP-сервер, который прослушивает только локальный хост. Затем я настраиваю gitlab-shell для использования подключения к http://localhost/ Таким образом, можно обойти проблему ошибок сертификата HTTPS.