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

Я уже настроил сервер 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://stackru.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 ответ

Решение

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

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

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 создает путь к каталогу в каждом предоставленном вами webroot. Поэтому правильная форма команды certbot или letsencrypt для вышеупомянутого Alias ​​/Directory должна быть такой:

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. Так что простите, если это элементарный вопрос для большинства из вас, ребята.

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

Источник
Другие вопросы по тегам