3 заметки с тегом

веб-сервер

Бесплатный wildcard SSL-сертификат для поддоменов

Для простых веб-приложений достаточно одного домена (example.com). Однако для сложных систем, с разделением на бэкенд и фронтенд части, с лендингами, микросервисами и т. п. нужны поддомены, например: api.example.com, app.example.com, cdn.example.com.

Вместо того, чтобы выпускать отдельные сертификаты на каждый поддомен, мы можем выпустить один сертификат, покрывающий сразу все кейсы — *.example.com. Такой тип сертификатов называется Wildcard.

Как и в предыдущей статье про выдачу бесплатного SSL-сертификата, мы воспользуемся утилитой Certbot, который поможет нам выпустить и установить бесплатные SSL-сертификаты для наших поддоменов через центр Let’s encrypt.

Предполагаю, что вы уже настроили ваш сервер, чтобы поддомены были доступны по http (80 порт). Если вы не знаете, как это сделать, поищите статью по вашим ОС и веб-серверу на Digitalocean. Например, вот статья про установку и настройку Nginx на Ubuntu 20.04.

Заходим на сайт Certbot’а и выбираем ОС нашего сервиса и веб-сервер. Ниже в примере будет Ubuntu 20.04 и Nginx. Дальше выбираем таб Wildcard.

Предположим, что нам нужны следующие домены: example.com, api.example.com и app.example.com.
Запускаем по инструкции первые 8 шагов для установки самой утилиты:

// Удаляем snap, если он был установлен ранее
$ sudo apt-get remove certbot
// Устанавливаем snap
$ sudo snap install core; sudo snap refresh core
// Устанавливаем certbot
$ sudo snap install --classic certbot
$ sudo ln -s /snap/bin/certbot /usr/bin/certbot
$ sudo snap set certbot trust-plugin-with-root=ok

// Проверяем, что certbot установлен
$ certbot --version
> certbot 1.14.0

Для того, чтобы выпустить сертификаты, мы должны доказать удостоверяющему центру Let’s Encrypt, что мы действительно владеем данными доменами и сабдоменами. Есть два способа это сделать.

  1. Добавить в DNS специальные txt записи, которые попросит нас добавить Let’s Encrypt, после этого он их проверит, и если записи будут обнаружены, это подтвердит факт владения (или по крайней мере доступа к ним). С чужими доменами так сделать не получится.
  2. Webroot. Аналогичный способ, но специальные уникальные строки добавляются в файлы, которые потом должны быть доступны через URL, например: http://api.example.com/.well-known/acme-challenge/JH1kjoemxaS33d. Поскольку такой файл сможет добавить только владелец домена, этого тоже достаточно, чтобы Let’s Encrypt удостоверился в факте нашего владения.

Certbot позволяет автоматизировать каждый из способов. Нам не придётся делать это вручную, что критично для будущей поддержки сертификатов — их нужно будет обновлять раз в два месяца. И если доменов и сабдоменов много, то это быстро станет обузой.

Certbot поддерживает из коробки несколько популярных DNS-регистраторов (те сервисы, где можно купить домен), и тогда можно следовать по инструкции, однако в моём случае регистратором был Godaddy, который не поддерживается. Поэтому я воспользовался вторым способом и он оказался даже проще первого. Кроме того, данный способ надёжнее, так как не зависит, повезёт ли вам с поддержкой вашего регистратора или нет.

Для верификации доменов по webroot нам нужно настроить каждый домен/поддомен, чтобы он отдавал директорию /.well-known/acme-challenge/. В эту папку certbot запишет то, что нужно Let’s Encrypt, чтобы мы прошли проверку, поэтому убедитесь, что certbot имеет туда доступ.

Есть небольшой лайфхак, как упростить работу с этой папкой в конфигах сервера. Для этого мы создадим отдельный файл конфига, который будем подключать для каждого домена/поддомена. Пример для Nginx:

// создаём файл "/etc/nginx/letsencrypt.conf"
location /.well-known/acme-challenge {
    # Вместо `/var/www/acme-challenge` можно указать любую папку.
    # Она может быть недоступна извне, это неважно. Главное, чтобы туда имел доступ ваш текущий юзер.
    alias /var/www/acme-challenge/.well-known/acme-challenge;
}

Подключаем этот файл в конфигах доменов и поддоменов. Допустим, у вас есть файл /etc/nginx/sites-available/api.example.com (с остальными аналогично).

server {
    server_name api.example.com;
    include letsencrypt.conf;
    ...
}

Готово. Теперь домен будет все запросы, начинающиеся на /.well-known/acme-challenge будут направлены в папку /var/www/acme-challenge/.well-known/acme-challenge, общую для всех доменов/поддоменов.

Далее запускаем certbot, чтобы он пообщался с Let’s Encrypt, подтвердил наши домены, выпустил сертификаты и даже настроил наш веб-сервер на их использование.

certbot run -a webroot -i nginx -w /var/www/acme-challenge -d example.com -d api.example.com -d app.example.com

Разберём эти конфиги:

  • -a webroot — это способ аутентификации (подтверждение, что мы владеем доменами)
  • -i nginx — один из доступных способов установки сертификатов. В данном случае это nginx, так как именно этот веб-сервер мы используем. Certbot вам задаст несколько вопросов и после этого обновит конфиги. Делает он это очень умно, так что без разницы как эти конфиги у вас написаны. И даже устанавливает редирект http на https.
  • -w /var/www/acme-challenge — путь до папки, которая будет использоваться для webroot аутентификации. Обратите внимание, что именно эта папка прописана в /etc/nginx/letsencrypt.conf.
  • -d example.com -d api.example.com -d app.example.com — указываем все необходимые поддомены, обязательно первым указываем основной домен (не поддомен), иначе ничего не получится.

Всё, certbot всё сделал сам, даже перезагрузил веб-сервер. Можно зайти через браузер на поддомены и убедиться, что всё работает.


p.s. если браузер выдаёт ошибку, что такой домен не найден, то проверьте, что файрволл настроен на выдачу https трафика. Например, в Ubuntu 20.04 это делается через UFW:

// Проверяем, есть ли HTTPS в активных правилах
$ sudo ufw status
// Смотрим, какие правила могут быть включены
$ sudo ufw app list
// Включаем Nginx https
$ sudo ufw allow 'Nginx HTTPS'
// Проверяем, что правило появилось в активных
$ sudo ufw status

Deployment: настраиваем пользователей

Проблема

Под root-пользователем работать небезопасно, равно как и делать весь проект доступным www-data.
Кроме того, во многих веб-приложениях пользователи имеют возможность загружать свои файлы. И очень часто с такими файлами возникают конфликты, так как пишутся они под www-data:www-data, а деплоим под другим пользователем. Даже если деплоить под root, то скорее всего права на папку перепишутся и www-data потеряет доступ к нужным файлам.

Решение

Создать нового пользователя deploy с правами на коннект к серверу по ssh, доступом только к папке с проектом и возможностью изменять файлы в ./public/uploads и ./var.

Создаём на сервере пользователя deploy из-под root:

ssh root@вашсервер
useradd --create-home -s /bin/bash deploy

Настроим доступ по ssh через ключи

mkdir /home/deploy/.ssh
touch /home/deploy/.ssh/authorized_keys

Вставьте содержимое одного из публичного ключа своего локального пользователя в файл authorized_keys и сохраните. Вывести публичный ключ локально можно командой: cat ~/.ssh/id_rsa.pub (название ключа id_rsa.pub у вас может отличаться).

vim /home/deploy/.ssh/authorized_keys

Меняем права на более строгие

chown -R deploy:deploy /home/deploy
chmod 600 /home/deploy/.ssh/authorized_keys

Определим пользователя нашего веб-сервера (в примере ниже это www-data)

ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\  -f1
> www-data

Добавляем пользователя deploy в группу www-data (группа веб-сервера)

usermod -a -G www-data deploy

Выставляем права на папку проекта

chown -R deploy:deploy /var/www/project
chmod -R 0775 /var/www/project

Проверим, есть ли setfacl в системе setfacl -h и установим, если его нет. Команда для Ubuntu:

sudo apt-get install acl

Выдадим права на папки с кэшем, логами и загруженными пользовательскими файлами

sudo setfacl -dR -m u:www-data:rwX -m u:deploy:rwX /var/www/project/var /var/www/project/public/uploads
sudo setfacl -R -m u:www-data:rwX -m u:deploy:rwX /var/www/project/var /var/www/project/public/uploads

Готово.

Для самого деплоймента я обычно использую Deployer c параметром writable_mode=acl.

 Нет комментариев   11 мес   deploy   deployment   Linux   веб-сервер

Как получить бесплатный SSL-сертификат и установить его на Nginx

Иметь сайт без HTTPS — это небезопасно. Особенно критично для интернет-магазинов и сервисов, где пользователь оставляет свои данные.

HTTPS — это защищённый брат HTTP (см. статью Что такое HTTP), который шифрует все пересылаемые от браузера к серверу и обратно данные. Для такого шифрования необходим SSL-сертификат, который позволяет убедиться пользователю, что он видит страницы именно того сайта, на  который он зашёл. Сертификаты бывают разного вида и стоимости в зависимости от уровня проверки владельца сайта, но при этом суть остаётся та же — шифрование пользовательских данных.

SSL-сертификат нужно получить в центрах сертификации (ЦС). Часто регистраторы доменов и провайдеры хостинга партнёрятся с такими центрами и облегачают задачу выпуска и установки сертификата на ваш сайт.

За выпуск сертификата ЦС берут плату, ведь им нужно по крайней мере удостовериться, что вы действительно владеете доменом, на который запрашиваете сертификат. У них такой бизнес. Можно выпустить и свой самоподписанный сертификат бесплатно, но браузеры не смогут ему доверять (ведь они не смогут уточнить его оригинальность у независимого ЦС) и  будут показывать предупреждение.

Как получить SSL-сертификат бесплатно

К счастью, есть ЦС, который выпускает SSL-сертификаты бесплатно, — это LetsEncrypt. Они это делают во имя благой цели — безопасного интернета во всём мире. Такой сертификат подойдёт для большинства небольших сайтов и сервисов, но среднему и крупном бизнесу — нет. Им нужны сертификаты с частичной или полной проверкой компании.

LetsEncrypt позволяет вам выпустить сертификат множеством способов для разных операционных систем, веб-серверов, языков программирования. Cам центр сертификации крайне рекомендует использовать Certbot.

Пример установки сертификатов с помощью Certbot на Ubuntu

Предположим, у нас есть сайты yoursite.ru и yourblog.ru, работающие по HTTP через Nginx. Добавим для них сертификаты и перейдём на HTTPS.

Заходим на сайт Certbot’a и выбираем Nginx и Ubuntu.

Добавляем ppa для установки certbot на нашем сервере, обновляем зависимости и устанавливаем саму утилиту.

$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository universe
$ sudo add-apt-repository ppa:certbot/certbot

# крайне важно выполнить эту команду, иначе следующая команда выдаст ошибку о незнакомом пакете.
$ sudo apt-get update

# Устанавливаем сам certbot
$ sudo apt-get install certbot python-certbot-nginx

Запускаем certbot и проходим через визард, отвечая на простые вопросы.

$ certbot --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org

Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: yourblog.ru
2: yoursite.ru
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):

Указываем через запятую или пробел номера сайтов из списка, для которых хотим выпустить сертификат, — в нашем случае «1,2» — жмём enter.

Obtaining a new certificate
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/yourblog.ru
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/yoursite.ru

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

Certbot настолько заботлив, что предлагает настроить принудительный редирект HTTP->HTTPS за нас. Соглашаемся, введя «2».

Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/yourblog.ru
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/yoursite.ru

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://yourblog.ru and
https://yoursite.ru

Обновление letsencrypt-сертификата

Нужно иметь в виду, что такой SSL-сертификат действителен только на 30 дней и через месяц его нужно обновить, снова подтвердив свои данные.

Но сюрприз! Certbot уже добавил регулярную задачу в systemd или cron и обновит сертификат сам, нам ничего больше делать не нужно.

—-
Для других систем и веб-серверов установка будет слегка отличаться, поэтому обратитесь к официальному сайту certbot’a.