Как настроить Gitlab EE с HTTPS на сервере DirectAdmin? - PullRequest
Новая
       79

Как настроить Gitlab EE с HTTPS на сервере DirectAdmin?

0 голосов
/ 05 февраля 2019

Я уже настроил сервер Omnibus Gitlab на моем Centos7 VPS (DirectAdmin), используя этот пост: как установить gitlab на сервере directadmin

Он отлично работал с HTTP-запросами.Из соображений безопасности я хочу настроить HTTPS на поддомене GitLab gitlab.domain.com.Я хочу использовать бесплатные SSL-сертификаты LetsEncrypt.Проблема в том, что LetsEncrypt не может аутентифицировать мой домен с помощью Certbot: certbot certonly --webroot --webroot-path = / var / www / letsencrypt -d gitlab.domain.com

Сбой при выводе: 

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: gitlab.domain.com
   Type:   unauthorized
   Detail: Invalid response from
   http://gitlab.domain.com/.well-known/acme-challenge/8Xj5vc-KMfhHYgH7PhXCFEetcxzQBDk-puiA2tRfoB4:
   "<!DOCTYPE html>\n<html class=\"devise-layout-html\">\n<head
   prefix=\"og: http://ogp.me/ns#\">\n<meta charset=\"utf-8\">\n<meta
   content=\"IE"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

Я гуглил его, и, похоже, LetsEncrypt должен найти путь к папке:

http://gitlab.domain.com/.well-known/acme-challenge/xxxxxxxxxx

Итак, я создал путь и дал разрешение 777 и для целей тестированияпоместите в него test.html.Теперь у меня есть доступ к файлу по HTTP, но я не могу получить по нему HTTPS. 

curl -I -k https://gitlab.domain.com/.well-known/acme-challenge/test.html

Вывод: 

HTTP/1.1 301 Moved Permanently
Date: Wed, 06 Feb 2019 10:05:40 GMT
Server: Apache/2
Location: http://gitlab.domain.com/.well-known/acme-challenge/test.html
Content-Type: text/html; charset=iso-8859-1

У меня уже есть DirectAdmin на сервере, и я не могувыясните, как настроить файл HTTPD.conf моего субдомена, чтобы все работало нормально.

Пользовательский раздел HTTPD.conf прямого администратора: 

ServerName gitlab.domain.com
ServerSignature Off

ProxyPreserveHost On

# Ensure that encoded slashes are not decoded but left in their encoded state.
# http://doc.gitlab.com/ce/api/projects.html#get-single-project
AllowEncodedSlashes NoDecode

<Location />
  Order deny,allow
  Allow from all

  #Allow forwarding to gitlab-workhorse
  ProxyPassReverse http://127.0.0.1:8181
  ProxyPassReverse http://gitlab.domain.com/
</Location>

# Apache equivalent of nginx try files
# http://serverfault.com/questions/290784/what-is-apaches-equivalent-of-nginxs-try-files
# http://stackoverflow.com/questions/10954516/apache2-proxypass-for-rails-app-gitlab
RewriteEngine on

# Forward all requests to gitlab-workhorse except existing files like error documents
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_URI} ^/uploads/.* [NC,OR]
RewriteCond %{REQUEST_URI} !^.*/\.well-known/acme-challenge/.*$ [NC]
RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]

Alias /.well-known/acme-challenge/ /var/www/letsencrypt/
<Directory "/var/www/letsencrypt/">
     Order allow,deny
     Options Indexes FollowSymLinks MultiViews
     AllowOverride None
     Allow from all
</Directory>

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

Стоит отметить, что тестирование моего доменаиспользование https://letsdebug.net/ с методами HTTP-01 и DNS-01 возвращает, что все в порядке.

Я думаю, если бы я мог обрабатывать запросы HTTPS, чтобы гарантировать доступ API-интерфейса LetsEncrypt к http://gitlab.domain.com/.well-known/acme-challenge/ URLпо HTTP и HTTPS все будет в порядке.

1 Ответ

0 голосов
/ 09 февраля 2019

Поскольку никто не ответил на мой вопрос, я работал над ним и, наконец, нашел ответ.

На самом деле проблема возникла из двух частей:

1. Когда вы хотите указатьк пути, который содержит специальные символы, такие как «.», «\» или пробел в строке с «...», вы должны использовать его в «\.»формат.Я настаиваю на том, что это применимо только в том случае, если у вас есть строка, заключенная в двойные кавычки, а не все параметры, которые есть в вашем файле конфигурации. 

<Directory "/var/www/default/\.well-known/acme-challenge/">

Таким образом, правильная форма части псевдонима / каталога приведена ниже.: 

Alias /.well-known/acme-challenge/ /var/www/default/.well-known/acme-challenge/
<Directory "/var/www/default/\.well-known/acme-challenge/">
    Options None
    AllowOverride None
    ForceType text/plain
    RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
</Directory>

Вы можете получить «HTTP / 1.1 302 Found», а не «HTTP / 1.1 200 OK», когда вы называете URL тестового файла 'curl'.Он возвращает 302, потому что вы каким-то образом перенаправляете запрос куда-то еще, чем вы видите в адресной строке.Но это нормально для авторизации домена LetsEncrypt. 

curl -I http://example.com/.well-known/acme-challenge/test.html

2. Когда вы вызываете команду certbot или letsencrypt, в параметре webroot он должен указывать на корень вашего каталога вызова ACME (/ var / www /default /) не конечный пункт назначения сертификатов (/var/www/default/.well-known/acme-challenge/), поскольку acmetool сам создает путь к каталогу в каждом предоставленном вами веб-корне.Таким образом, правильная форма команды certbot или letsencrypt для вышеуказанного псевдонима / каталога должна быть такой: 

letsencrypt certonly --webroot -w /var/www/default/ -d example.com -d www.example.com --renew-by-default

или 

certbot certonly --webroot --webroot-path=/var/www/default/ -d example.com

Я очень плохо знаком с конфигурацией Apache, но покапоскольку я искал проблему, это очень популярная проблема для тех, кто хочет использовать LetsEncrypt через сервер Apache.Так что простите, если это простейший вопрос для большинства из вас, ребята.

Наслаждайтесь!

...