Максим Кузнецов: заметки с тегом инфраструктура

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

Максим Кузнецов — Sun, 02 May 2021 18:05:26 +0300

Для простых веб-приложений достаточно одного домена (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, что мы действительно владеем данными доменами и сабдоменами. Есть два способа это сделать.

Добавить в DNS специальные txt записи, которые попросит нас добавить Let’s Encrypt, после этого он их проверит, и если записи будут обнаружены, это подтвердит факт владения (или по крайней мере доступа к ним). С чужими доменами так сделать не получится.
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

Как настроить php-cs-fixer и phpstan на локалке

Максим Кузнецов — Tue, 01 Dec 2020 17:34:55 +0300

Проблема 1

При совместной разработке (от 2х человек) code style становится критичным. Если каждый будет писать в своём стиле, вскоре проект превратится в бардак, где по разному стилю можно будет оценивать возраст кода будто по кольцам на деревьях.

На собеседованиях я часто слышу от кандидатов, что мы пользуемся проверками, встроенными в IDE. Но это полрешения, так как такие проверки носят рекомендательный, а не обязательный характер. Очень легко не заметить предложение по правке от IDE. А кроме того, приходится синхронизировать настройки IDE между всей командой. А что делать, если у кого-то другой редактор? Результат непредсказуем, а значит и ненадёжен.

Проблема 2

Чем больше кодовая база проекта, тем проще допустить ошибку или опечатку. Вручную проверка кода перед каждым коммитом возможна, но требует много времени и большой внимательности. Результат опять непредсказуем и ненадёжен.

Решение

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

Такие инструменты уже есть — code style и статические анализаторы кода.

Единый стиль кода

Поскольку я специализируюсь на Symfony, то для код-стайла выбираю PHP-CS-Fixer. Он написан при участии создателя Symfony и имеет из коробки поддержку рекомендованного сообществом Symfony Code Standards. Есть ещё PHPCodeSniffer, но он умеет только обнаруживать ошибки, но не исправляет их автоматически, поэтому я рекомендую именно PHP-CS-Fixer.

Совет: обязательно изучите и следуйте code style и рекомендациям вашего фреймворка. С большой вероятностью в будущих проектах вам встретится именно общепринятый в сообществе фреймворка code style, поэтому будет проще вписаться в новую команду, если вы придёте к этому стилю как можно раньше. К тому же, уже принятый в сообществе стиль поможет избежать ненужных холиваров внутри команды.

Устанавливаем через composer и настраиваем PHPCSFixer в Symfony-проекте:

cd /ваш/проект
composer req --dev friendsofphp/php-cs-fixer
# Если используете docker-compose, то устанавливайте в нём
docker-compose exec web composer req --dev friendsofphp/php-cs-fixer

Создаём в корне проекта файл .php_cs:

<?php

$finder = PhpCsFixer\Finder::create()
    ->in([
        __DIR__ . '/src',
        __DIR__ . '/tests'
    ])
;

return PhpCsFixer\Config::create()
    ->setRules([
        '@Symfony' => true,
        'array_syntax' => ['syntax' => 'short'],
        'concat_space' => ['spacing' => 'one'],
        'increment_style' => ['style' => 'post'],
        'no_extra_blank_lines' => ['tokens' => [
            'extra',
            'parenthesis_brace_block',
            'square_brace_block',
            'throw',
            'use',
        ]],
        'no_superfluous_phpdoc_tags' => false,
        'phpdoc_align' => false,
        'phpdoc_annotation_without_dot' => false,
        'trailing_comma_in_multiline_array' => false,
        'yoda_style' => false
    ])
    ->setFinder($finder)
;

Теперь вы можете запустить проверку всего проекта (или конкретного пути) с помощью команды

# только поиск ошибок
./vendor/bin/php-cs-fixer  fix --dry-run --diff ./
# поиск ошибок и их автоматический фикс
./vendor/bin/php-cs-fixer fix ./

Ошибки и качество кода

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

Самые популярные статичиские анализаторы кода:

Я покажу, как настроить и внедрить PHPStan, а вы можете добавить в проект все три по аналогии. Устанавливаем через composer сам PHPStan и несколько полезных плагинов — PHPUnit, Symfony, Doctrine.

cd /ваш/проект
composer req --dev phpstan/phpstan phpstan/phpstan-doctrine phpstan/phpstan-phpunit phpstan/phpstan-symfony

Должен создаться в корне проекта файл .phpstan.neon.dist, редактируем его:

includes:
    - vendor/phpstan/phpstan-doctrine/extension.neon
    - vendor/phpstan/phpstan-phpunit/extension.neon
    - vendor/phpstan/phpstan-phpunit/rules.neon
    - vendor/phpstan/phpstan-symfony/extension.neon
parameters:
    reportUnmatchedIgnoredErrors: false     #to avoid throwing of errors ... if no errors matching the ignored one is raised
    scanFiles:  #we need this for some twig based functions
        - '%rootDir%/../../../vendor/twig/twig/src/Extension/CoreExtension.php'
    bootstrapFiles:
        - '%rootDir%/../../../vendor/bin/.phpunit/phpunit-X.X.X/vendor/autoload.php'
    ignoreErrors:
        - message: '/^Service "[^"]+" is private.$/'
          path: '%rootDir%/../../../tests/'
    level: 0 
    symfony:
        container_xml_path: '%rootDir%/../../../var/cache/development/App_KernelDevelopmentDebugContainer.xml'

Внимательно пройдитесь по этим настройкам и укажите корректные пути. Особое внимание:

bootstrapFiles — включает путь до текущего phpunit. Если его не используете, то можете закоментить.
level — уровень строгости проверок от 0 до 8. 0 — самый слабый уровень, подходит для первого внедрения.

Теперь вы можете запустить проверку всего проекта (или конкретного пути) с помощью команды

./vendor/bin/phpstan analyse src tests

Советы по внедрению

Несколько советов по внедреню PHP-CS-Fixer в существующий проект с большой командой.

Выберите одного ответственного, кто запустит скрипты и пофиксит весь проект у себя на локалке, а потом создаст ПР / смерджит в develop или master.
Лучшее время — первое утро нового спринта. Обычно после спринта все ветки смёрджены, и это позволит залить все найденные правки в основную ветку проекта без конфликтов.
В статических анализаторах используйте для начала минимальный уровень строгости проверок. У каждого анализатора для этого своя школа, читайте документацию.
Первый фикс — самый критичный момент, так как правок может быть очень много. Все последующие фиксы обычно не создают ощутимых конфликтов и гит их смёрдживает самостоятельно.

Чтобы не запоминать длинные пути до скриптов, мы добавим несколько задач (tasks) в composer.json:

{
    "require": { ... },
    "require-dev": { ... },
    ...
    "scripts": {
        ...
        "csfix": "./vendor/bin/php-cs-fixer fix",
        "csfix-validate" : "./vendor/bin/php-cs-fixer fix --dry-run --diff",
        "phpstan": "./vendor/bin/phpstan analyse src tests",
        "code-quality": [
            "@phpcsfixer-validate",
            "@phpstan"
        ]

Теперь мы можем запускать проверки в упрощённом формате:

composer csfix
composer phpstan
composer code-quality

Обязательный запуск проверок перед коммитом

Внедрение этих инструментов позволяет удостовериться, что код соответствует принятому в команде стилю и не имеет очевидных опечаток и синтаксических ошибок. Однако это ещё не решает проблему забывчивости программистов и необязательности проверок.

Воспользуемся Git-хуками (git hooks) — это скрипты, которые мы можем попросить git выполнить при возникновении какого-то события: момент перед созданием коммита, момент после создания коммита, момент добавления сообщения в коммит и т. п.

Полный список git-хуков вы можете увидеть у себя в репозитории:

$ ls -al .git/hooks
-rwxr-xr-x   1 mk  staff   478 Jul 13 13:04 applypatch-msg.sample
-rwxr-xr-x   1 mk  staff   896 Jul 13 13:04 commit-msg.sample
-rwxr-xr-x   1 mk  staff  3327 Jul 13 13:04 fsmonitor-watchman.sample
-rwxr-xr-x   1 mk  staff   189 Jul 13 13:04 post-update.sample
-rwxr-xr-x   1 mk  staff   424 Jul 13 13:04 pre-applypatch.sample
-rwxr-xr-x   1 mk  staff   382 Dec  1 14:46 pre-commit
-rwxr-xr-x   1 mk  staff  1638 Jul 13 13:04 pre-commit.sample
-rwxr-xr-x   1 mk  staff   416 Jul 13 13:04 pre-merge-commit.sample
-rwxr-xr-x   1 mk  staff  1348 Jul 13 13:04 pre-push.sample
-rwxr-xr-x   1 mk  staff  4898 Jul 13 13:04 pre-rebase.sample
-rwxr-xr-x   1 mk  staff   544 Jul 13 13:04 pre-receive.sample
-rwxr-xr-x   1 mk  staff  1492 Jul 13 13:04 prepare-commit-msg.sample
-rwxr-xr-x   1 mk  staff  3610 Jul 13 13:04 update.sample

Создадим скрипт, который будет запускать проверки каждый раз перед попыткой создать коммит.

vim .git/hooks/pre-commit

Добавляем внутрь файла:

#!/bin/sh
export PATH=/usr/local/bin:$PATH
# Если вы используете docker-compose (рекомендуется), то добавьте
export COMPOSE_INTERACTIVE_NO_CLI=1

if [ -t 1 ]; then
    # If we're in a terminal, redirect stdout and stderr to /dev/tty and
    # read stdin from /dev/tty. Allow interactive mode for CaptainHook.
    exec >/dev/tty 2>/dev/tty </dev/tty
fi

errors=0

composer code-quality
# или, если вы используете docker-compose (рекомендуется), то
docker-compose exec -T web php bin/composer code-quality

if [ "$?" -ne 0 ]; then
    errors=1
fi

if [ "$errors" -eq 1 ]; then
    echo "Errors detected!"
    exit 1
fi

Теперь можете попробовать сделать ошибку в .php файле и создать коммит. Git должен ругнуться:

Устанавливаем git-hook автоматически

Финальный шаг — добавить git-hook в .git/hooks/ папку при запуске composer. Тогда ни один разработчик не сможет пропустить запуск проверок по невнимательности. Для этого добавим в composer.json такую строку:

{
    ...,
    "scripts": {
        "post-autoload-dump": "mkdir -p .git/hooks && cp config/pre-commit .git/hooks/pre-commit",
        ...
    }
}

Итог

Мы добавили в проект PHPCsFixer для код-стайла и PHPStan для поиска ошибок и опечаток.
Запускаем их при каждой попытке создать коммит.
И всё это начинает работать автоматически после первого же composer install.

Как подружить docker, localhost и HTTPS

Максим Кузнецов — Tue, 26 May 2020 22:29:08 +0300

Когда разрабатываешь веб-сервис, который крутится на проде по HTTPS, есть большой соблазн не запариваться и работать локально по HTTP. Потому что так проще, да и в целом же всё работает плюс-минус одинаково. Если сервис простой, то скорее всего никаких проблем не всплывёт, но если сервис не монолитный и зависит от внешних сервисов или сам предоставляет АПИ клиентам, то проблемы с CORS неизбежны. И обычно эти проблемы обнаруживаются слишком поздно — либо на стейджинге, либо даже после релиза на продакшен.

Браузер начинает ругаться, что запросы с HTTPS на HTTP или наоборот не безопасны, сторонние сервисы перестают отвечать, так как по HTTP работали только тестовые стенды, с которыми вы и работали.

Решение простое — нужно не лениться и максимально приблизить локальную среду к боевой. Благо это задача из серии один раз сделал и используешь для всех последующих проектов.

Docker на продакшене

Если у вас продакшен без Docker, то вам поможет статья — Как получить бесплатный SSL-сертификат и установить его на Nginx.

В этой статье я рассматриваю только локальную сборку через docker-compose, потому что на продакшене, как ни странно, это немного проще. Достаточно выполнить понятную инструкцию по настройке Certbot и/или добавить соответствующий докер-образ с Docker Hub.

Docker на localhost

См. как запустить сайт через docker-compose на примере докеризации Эгеи.

На локалхосте Certbot не подойдёт, так как ему нужно реально существующее доменное имя и доступный через интернет сайт. Поэтому прописать локальный адрес в /etc/hosts не поможет. Решение — выпустить свой самоподписанный сертификат. Да, он не будет приниматься никем, кроме нашей системы, но для локальной разработки этого и не нужно.

Создаём доменное имя

Во-первых, создадим локально доменное имя, чтобы оно было похожим на боевое, а не обычный и скучный localhost. Например, docker.loc для основного сайта и api.docker.loc для API:

$ sudo vim /etc/hosts
127.0.0.1       localhost
127.0.0.1       docker.loc
127.0.0.1       api.docker.loc
...

Если для вашего сервиса необходимо несколько доменов, то пропишите их ниже по аналогии.

Выпускаем свой SSL-сертификат

Для реальных сайтов SSL-сертификаты выдаются специальными сертификационными центрами за деньги. За это они потом могут подтвердить верность домена по запросу любого браузера. Мы же выпустим свой сертификат и сами его подтвердим.

SSL-сертификат создаётся одной командой и состоит из двух частей: публичного сертификата и секретного ключа.

openssl req -x509 -out docker.loc.crt -keyout docker.loc.key \
  -newkey rsa:2048 -nodes -sha256 \
  -subj '/CN=docker.loc' -extensions EXT -config <( \
   printf "[dn]\nCN=docker.loc\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:docker.loc\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")

Файлы docker.loc.crt и docker.loc.key будут сохранены в той папке, откуда вы запускаете команду.

Добавляем сертификаты в ОС

Ниже пример, как это сделать на Mac OS X.

Найдите сертификат docker.loc.crt в Finder (или можно в нужной папке консоли ввести «open .»)
Дважды кликните по нему, появится окно.

Введите пароль администратора
Теперь нужно найти этот сертификат в Keychain Access и выбрать Trust Always

Добавляем сертификаты в docker-compose сборку

Сертификаты нужно положить в контейнер с веб-сервером. Я приведу пример для Nginx и сборки по типу https://github.com/pluseg/e2-docker.

Расположение сертификатов и конфигов

В этой сборке папки из app/docker/nginx монтируются прямо в nginx-контейнер. Поэтому удобно расположить файлы так:

<project root>
- app
--- docker
----- nginx
------- conf.d
--------- docker.loc.conf
------- ssl
--------- docker.loc.crt
--------- docker.loc.key

Пример docker.loc.conf (проект на PHP + Symfony)

# лучше с php соединять через socket
upstream php-upstream { server web:9000; }

# Редиректим HTTP на HTTPS
server {
       listen         80;
       listen    [::]:80;
       server_name    docker.loc;
       return         301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    root /var/www/html/docs;

    server_name            docker.loc;
    ssl_certificate          /etc/nginx/ssl/docker.loc.crt;
    ssl_certificate_key   /etc/nginx/ssl/docker.loc.key;
    ssl_protocols           TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;

    location / {
    	try_files $uri /index.php$is_args$args;
    }

    location ~ ^/(index|app|app_dev|config)\.php(/|$) {
        fastcgi_pass php-upstream;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        fastcgi_param DOCUMENT_ROOT $realpath_root;
        fastcgi_read_timeout 300;
    }

    error_log /var/log/nginx/docker.loc-error.log;
    access_log /var/log/nginx/docker.loc-access.log;
}

Пример docker-compose.yml

Добавляем 443 порт и несколько volume с конфигами и сертификатами.

version: '3.2'
services:
    ...
    nginx:
        image: nginx:latest
        ports:
            - 80:80
            - 443:443
        volumes:
            - ./app/docker/nginx/conf.d:/etc/nginx/conf.d
            - ./app/docker/nginx/ssl:/etc/nginx/ssl
            - ./:/var/www/html
            - ./var/logs/nginx:/var/log/nginx
        command: /bin/bash -c "exec nginx -g 'daemon off;'"

Запускаем и проверяем

docker-compose up -d --build

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

Максим Кузнецов — Fri, 10 Apr 2020 08:39:24 +0300

Иметь сайт без 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.