UMGUM.COM (лучше) 

Let‘s Encrypt + GitLab ( Настройки подсистемы получения и автоматического обновления сертификатов "Let's Encrypt" для встроенного в "GitLab" web-сервера "Nginx". )

26 октября 2018

OS: "Linux Debian 8/9 (Jessie/Stretch)".
Application: "Certbot client v.0.28" for "Let`s Encrypt" (on Python), "GitLab".

Основная инструкция по настройке "Let`s Encrypt" в спарке с web-сервером "Nginx" опубликована отдельно. Здесь рассматриваются лишь отличия от неё в плане интеграции со встроенным в комплекс приложений управления репозиториями Git-кода "GitLab" web-сервером "Nginx", управляемым оркестратором "Omnibus".

В комбайне "GitLab" по умолчанию используется поставляемый в качестве компонента встроенный web-сервер "Nginx", не настраиваемый в привычном стиле корректировки текстовых файлов, а полностью управляемый оркестратором "Omnibus" - можно лишь переопределить ряд предустановленных переменных, считывая которые "Omnibus" формирует конфигурацию, которую после передаёт встроенному "Nginx". Всё, что мне потребовалось для решения задачи, почерпнуто в официально документации проекта.


Предварительная настройка встроенного в "GitLab" web-сервера "Nginx".

Считая, что локальная директория для валидационных файлов "Certbot client"-а уже создана в соответствии с основной инструкцией, описываем для используемого в "GitLab" web-сервера "Nginx" конфигурацию простейшего HTTP-сайта с виртуальной ссылкой на зарезервированное ISRG имя "/.well-known/acme-challenge/" и перенаправлением на HTTPS всех запросов, не имеющих отношения к "Let`s Encrypt".

У компонентов "GitLab" своя структура директорий с динамически формируемыми конфигурационными файлами, но мы туда влазить не будем, а создадим своё минимально необходимое окружение:

# mkdir -p /etc/nginx/sites-available
# mkdir -p /etc/nginx/sites-enabled

# vi /etc/nginx/sites-available/gitlab.example.net.conf

# Описание принимающего запросы по HTTP web-сайта как такового
server {
  listen 80;
  server_name gitlab.example.net;

  # Блок конфигурации директории верификации Let`s Encrypt
  location ^~ /.well-known/acme-challenge/ {
    default_type "text/plain";
    root /var/www/letsencrypt;
    break;
  }

  # Блок перехвата необработанного трафика HTTP и перенаправления его в HTTPS
  location / {
    rewrite ^ https://$host$request_uri permanent;
  }
}

Следуя общепринятой идеологии настройки web-серверов создаём символическую ссылку файла описания сайта в директории для разрешённых к использованию конфигураций:

# ln -s /etc/nginx/sites-available/gitlab.example.net.conf /etc/nginx/sites-enabled/gitlab.example.net.conf

В нашем случае для решения задачи интеграции отдельно конфигурируемой подсистемы "Let`s Encrypt" и комбайна "GitLab" проще всего будет подсунуть встроенному web-серверу подготовленный выше конфигурационный файл обслуживающего HTTP-запросы сайта, с настроенным перехватом запросов к интересующим нас ресурсам и перенаправлением всех остальных на HTTPS, с сопутствующим обязательным отключением автоматического редиректа "HTTP->HTTPS" средствами оркестратора "Omnibus":

# vi /etc/gitlab/gitlab.rb

....
# Явно указываем предпочтительный FQDN web-сервиса
# (в рабочей схеме этот параметр уже определён)
external_url "https://gitlab.example.net"

# Разрешаем использование встроенного в "GitLab" web-сервера "Nginx"
# (этот параметр по умолчанию уже определён)
nginx['enable'] = true

# Отключаем автоматический редирект на HTTPS средствами "Omnibus"
nginx['redirect_http_to_https'] = false

# Подставляем конфигурацию обслуживающего HTTP-запросы web-сайта
nginx['custom_nginx_config'] = "include /etc/nginx/sites-enabled/*.conf;"
....

Даём команду оркестратору "GitLab" перечитать конфигурационные файлы и принять изменения (при этом будут перезапущены только те сервисы, в конфигурации которых обнаружены изменения):

# gitlab-ctl reconfigure

....
  * template[/var/opt/gitlab/nginx/conf/nginx.conf] action create
    - update content in file /var/opt/gitlab/nginx/conf/nginx.conf...
    ....
    +  include /etc/nginx/sites-enabled/*.conf;
....
Recipe: gitlab::nginx
  * service[nginx] action restart
    - restart service service[nginx]
....
gitlab Reconfigured!

Сразу есть смысл удостовериться, что встроенный в "GitLab" web-сервер успешно запустился после его перенастройки:

# netstat -apn | grep -i nginx

tcp ... 0 0.0.0.0:80  ... LISTEN 5631/nginx      
tcp ... 0 0.0.0.0:443 ... LISTEN 5631/nginx      
....

В дальнейшем, если изменениям будет подвергаться только файл конфигурации нашего подставного HTTP-сайта, для применения таковых будет достаточно перезапуска сервиса лишь web-сервера:

# gitlab-ctl restart nginx

Применение сертификатов "Let`s Encrypt" в web-сервисе.

Считая, что SSL-сертификаты уже запрошены в соответствии с базовой инструкцией, применяем их в конфигурации "GitLab" примерно следующим образом:

# vi /etc/gitlab/gitlab.rb

....
# Рекомендуемые обобщённые настройки протокола SSL/TLS
nginx['ssl_dhparam'] = "/etc/gitlab/ssl/dhparams.pem"
nginx['ssl_protocols'] = "SSLv3 TLSv1 TLSv1.1 TLSv1.2"
nginx['ssl_ciphers'] = "HIGH:MEDIUM:!LOW:!SSLv2:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4:!aECDH:+SHA1:+MD5:+HIGH:+MEDIUM"
nginx['ssl_prefer_server_ciphers'] = "on"
nginx['ssl_session_cache'] = "shared:SSL:30m"
nginx['ssl_session_timeout'] = "1h"

# Сертификаты Let`s Encrypt
nginx['ssl_certificate'] = "/etc/letsencrypt/live/gitlab.example.net/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/gitlab.example.net/privkey.pem"

# Включаем поддержку HTTPv2
nginx['http2_enabled'] = true

# Указываем встроенному "Nginx" при проксировании информировать низлежащие сервисы о параметрах соединения между ним и клиентами
nginx['proxy_set_headers'] = {
  "X-Forwarded-Proto" => "https",
  "X-Forwarded-Ssl" => "on"
}
....

"GitLab" запускает web-сервер "Nginx" от имени специализированного пользователя "gitlab-www". Я его включаю в группу "www-data", для унификации:

# usermod --append --groups www-data gitlab-www

Даём команду оркестратору "GitLab" перечитать конфигурационные файлы и принять изменения:

# gitlab-ctl reconfigure

Автоматизация продления сертификатов.

Общая идея и способ реализации автоматического продления сертификатов рассматривается в основной инструкции, а здесь лишь приводится специфичная для "GitLab" команда применения обновлённой конфигурации:

# vi /opt/eff.org/cert-renew.sh

#!/bin/bash
....
# Даём указание использующему сертификаты web-сервису "GitLab" перечитать конфигурацию
[ -x "$(command -v gitlab-ctl)" ] && { gitlab-ctl restart nginx; }
....


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )