Lets encrypt wildcard сертификат инструкция

Мы уже рассказывали, как получить бесплатный SSL-сертификат от сервиса Let’s Encrypt. Сегодня они анонсировали поддержку бесплатных Wildcard сертификатов — событие, которого все давно ждали.

Wildcard SSL-сертификат отличается от обычного тем, что выдаётся не на одно доменное имя (например, ifmo.su), а сразу на группу поддоменов (*.ifmo.su). В эту группу входят example.ifmo.su, bot.ifmo.su и даже thisisdummydomain.ifmo.su, то есть на неограниченное количество вариантов.

Такие сертификаты существенно упрощают жизнь администратору. Теперь не нужно отдельно получать и обновлять сертификат для каждого поддомена — достаточно проделать всю процедуру один раз.

Подготовка

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

Подключитесь по SSH к вашему серверу и выполните следующие команды:

curl https://get.acme.sh | sh

Вы увидите сообщение об успехе, а в вашей домашней директории появится папка .acme.sh

Получение сертификата

Перейдите в директорию .acme.sh и выполните следующую команду, заменив в ней адрес домена ifmo.su на ваш. 

cd .acme.sh
./acme.sh --issue -d *.ifmo.su --dns

Acme.sh соединится с сервисом Let’s Encrypt по протоколу ACMEv2 для получения заявки на сертификат. Вы увидите следующий результат.

В этом сообщении вам говорят, что необходимо создать в панели управления доменом TXT-запись для домена _acme-challenge.ifmo.su со значением Q1b4d3J9BwRqQ-Z3qlu6soL4YuF9BG1Y212QI3ie3K4.

Установка DNS-записей

Теперь вам нужно найти панель управления DNS-записями у вашего хостинг-провайдера и добавить туда требуемую запись.

Например, панель управления DNS нашего хостинга выглядит следующим образом:

После того, как вы добавите TXT-запись, выполните следующую команду

./acme.sh -d *.ifmo.su --renew

Сервис Let’s Encrypt проверит TXT-запись и убедится, что вы действительно владелец домена. Результат не заставит себя ждать.

На экране будет указано, где расположены файлы сертификата. В нашем случае, это директория /root/.acme.sh/*.ifmo.su

Сертификат для основного домена

Важно отметить, что SSL-сертификат мы получили на все домены в зоне *.ifmo.su. Однако, на сам ifmo.su нужно выписывать отдельный сертификат. Для этого достаточно выполнить команду и повторить все операции.

./acme.sh --issue -d ifmo.su --dns

Можно было при регистрации Wildcard-сертификата указать сразу несколько доменов.

./acme.sh --issue -d *.ifmo.su -d ifmo.su --dns

Обратите внимание, что для подключения поддоменов, вы должны использовать верификацию через DNS и создавать TXT-записи.

Обычные же сертификаты на один домен можно получить другими более простыми способами. Подробнее читайте в нашей предыдущей статье и в официальной документации.

Другие клиенты

Существуют и другие утилиты, поддерживающие работу с Let’s Encrypt. Например, с помощью certbot можно получить сертификат схожим образом:

./certbot-auto certonly --manual -d *.ifmo.su --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

На данный момент certbot поддерживает Wildcard сертификаты только в версии 0.22. Поэтому, необходимо устанавливать его напрямую из Git репозитория.

Проверяем в действии

Для примера создадим простейший Nginx-конфиг для всех доменов *.ifmo.su

server {
listen 80;
listen 443 ssl;
ssl_certificate /etc/ssl/ifmo.su.cer;
ssl_certificate_key /etc/ssl/ifmo.su.key;

}

В данном примере мы скопировали ключи из /root/.acme.sh/*.ifmo.su/*.ifmo.su.cer в /etc/ssl/ifmo.su.cer и /root/.acme.sh/*.ifmo.su/*.ifmo.su.key в /etc/ssl/ifmo.su.key.

После этого вы сможете перейти на любой поддомен вашего сайта по протоколу HTTPS.

Подведём итоги 

С помощью сервиса Let’s Encrypt и утилит acme.sh или certbot можно легко и быстро получить бесплатный Wildcard SSL-сертификат для всех своих доменов и их поддоменов. Сертификат будет действителен в течение трёх месяцев, однако, его не составит труда обновить, действуя по нашей инструкции.

В последнее время забота о безопасности и приватности пользователей набирает обороты. Когда проектировался интернет и протокол HTTP, о таких понятиях не думали. Поэтому весь трафик, передаваемый между веб-сервером и пользователем по протоколу HTTP, может быть просмотрен кем угодно, кто находится на пути этого трафика, например провайдером или хакерами.

Поэтому был придуман протокол HTTPS, который позволяет шифровать трафик и таим образом обезопасить его от перехвата. Для шифрования используются SSL-сертификаты. Раньше эти сертификаты стояли денег, но благодаря компании Let’s Encrypt теперь любой веб-сайт может установить SSL-сертификат и настроить шифрование абсолютно бесплатно. В этой статье мы рассмотрим, как получить сертификат Let’s Encrypt с помощью официального клиента Certbot.

Вообще, нам не обязательно использовать именно Certbot, мы могли бы создать сертификат в OpenSSL, а затем просто подписать его с помощью ACME API от Let’s Encrypt. Но к этому API надо выполнять запросы в формате JSON, что очень неудобно делать из командной строки, поэтому лучше использовать один из клиентов. Например Certbot. К тому же, большинство клиентов ACME уже включают автоматическую генерацию сертификата в OpenSSL.

1. Синтаксис и команды Certbot

Прежде чем перейти к работе, давайте рассмотрим синтаксис утилиты Certbot и её команды. Они выглядят достаточно просто:

certbot команда опции -d домен

Команды используются для того, чтобы сообщить утилите, что именно надо сделать. Вот основные из них:

• run — используется по умолчанию, если никакая команда не указана, получает и устанавливает сертификат;
• certonly — только получает или обновляет сертификат, но не устанавливает его;
• renew — обновляет сертификат;
• enhance — добавляет настройки безопасности для существующих сертификатов;
• certificates — отображает установленные сертификаты;
• revoke — отзывает сертификат;
• delete — удаляет сертификат;
• register — создает ACME-аккаунт;

Как видите, команд не так много, и теперь вы в них точно не запутаетесь, а теперь разберём основные опции:

• -d — указывает домен или список доменов, разделённых запятыми, для которых надо получить сертификаты;
• —apache — использовать плагин apache для установки сертификата;
• —nginx — использовать плагин nginx;
• —standalone — запускать собственный веб-сервер для аутентификации при получении сертификата;
• —preferred-challenges — позволяет выбрать способ аутентификации, по умолчанию http, но можно выбрать dns;
• —server — позволяет указать адрес ACME-сервера, нужно для WildCard-сертификатов, поскольку они поддерживаются только второй версией ACME;
• —webroot — поместить файлы аутентификации в папку веб-сервера;
• -w — указывает папку веб-сервера, куда надо поместить файлы аутентификации;
• —manual — создание сертификата в ручном режиме;
• -n — запустить утилиту в не интерактивном режиме;
• —dry-run — тестовый запуск без сохранения изменений на диск.

Теперь мы готовы к тому, чтобы перейти к работе с утилитой. Сначала установим её.

2. Установка Certbot

Сначала необходимо установить утилиту Certbot. Это официальный клиент, и он есть в репозиториях большинства дистрибутивов. Установка Certbot в Ubuntu выполняется из PPA:

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

Если вы знаете, для какой платформы будут генерироваться сертификаты, то можно установить отдельные расширения для них, они позволяют автоматически редактировать конфигурацию. Например, вы можете установить модуль для apache или nginx:

sudo apt install python-certbot-apache
sudo apt install python-certbot-nginx

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

3. Создание сертификата без установки

Если вам нужен сертификат для веб-сервера, который не поддерживается программой, вам придётся устанавливать его вручную. Получить такой сертификат можно с помощью команды certonly:

sudo certbot certonly --webroot -w /var/www/test.losst.pro -d test.losst.pro -d www.test.losst.pro

Эта команда получает сертификат для доменов test.losst.pro и www.test.losst.pro. Файлы для подтверждения аутентификации будут размещены в каталоге /var/www/example/. Также вы можете использовать встроенный веб-сервер для аутентификации:

sudo certbot certonly --standalone -d test.losst.pro -d www.test.losst.pro

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

Затем вам предложат подтвердить, что вы прочитали правила использования сервиса, ответьте А:

Далее вас спросят, хотите ли вы сделать ваш Email публичным:

Только после этого начнётся получение сертификата. Если всё прошло успешно, то ваш сертификат будет сохранён в /etc/letsencrypt/live/имя_домена/, оттуда вы уже можете использовать их в своих приложениях. Если же возникли ошибки, то утилита сообщит об этом.

4. Создание сертификата для Nginx

Вам не обязательно вручную устанавливать сертификаты, вы можете использовать один из доступных плагинов для автоматического обновления конфигурации. Например, рассмотрим использование плагина для Nginx:

sudo certbot run --nginx

Дополнительные параметры задавать не надо, потому что утилита сама прочитает конфигурацию и выведет список доступных доменов:

Введите цифру нужного домена или несколько цифр, разделённых запятой. Утилита сама установит всё, что нужно, а затем спросит вас, нужно ли перенаправлять http-трафик на https:

Затем утилита выдаст ту же информацию, что и в предыдущем варианте:

5. Обновление сертификата Let’s Encrypt

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

sudo certbot certonly -d test.losst.pro -d www.test.losst.pro

Если срок службы сертификата ещё не вышел и обновление не требуется, утилита спросит вас, действительно ли это надо сделать.

Если вы хотите обновлять сертификат в не интерактивном режиме, например с помощью скрипта, то нужно использовать опцию -n, также при использовании этой опции надо передать плагин, который будет использоваться для аутентификации:

sudo certbot certonly --nginx -n -d test.losst.pro -d www.test.losst.pro

Теперь можно добавить эту команду в планировщик cron, например раз в неделю:

crontab -e

0 0 * * 0 /usr/bin/certbot certonly --nginx -n -d test.losst.pro -d www.test.losst.pro

Если вы хотите обновить сертификаты для всех доменов одной командной в не интерактивном режиме, достаточно выполнить команду:

sudo certbot renew

6. Получение Wildcard сертификата Let’s Encrypt

Let’s Encrypt Wildcard-сертификаты появились относительно недавно. Они позволяют использовать один сертификат для всех поддоменов определённого домена, например *.test.losst.pro. Но и работает это всё сложнее — вам надо будет подтвердить, что этот домен принадлежит именно вам. Для этого надо добавить TXT-запись к зоне домена.

Вы можете сделать это вручную или же использовать dns-плагин для Certbot, чтобы добавить её автоматически. Правда, плагин поддерживается только для популярных сервисов, таких, как DigitalOcean, Linode, Cloudflare и так далее. В этой статье рассмотрим ручной вариант. Команда для генерации сертификата будет выглядеть вот так:

sudo certbot certonly --agree-tos -d test.losst.pro -d *.test.losst.pro --preferred-challenges dns --manual --server https://acme-v02.api.letsencrypt.org/directory

Вам надо будет разрешить публикацию вашего IP-адреса, а потом добавить TXT-запись с нужным именем и значением к вашей доменной зоне. В моем случае это  _acme-challenge.test.losst.pro со специальным хэшем:

Нужная TXT-запись в службе dmains.webmoney.ru выглядит вот так:

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

Выводы

В этой статье мы рассмотрели, как получить сертификат Let’s Encrypt с помощью клиента Certbot. Если у вас есть полный доступ к вашему серверу, то сделать это достаточно просто. Поэтому бесплатный сертификат Let’s Encrypt может получить каждый. На losst.pro тоже используются SSL-сертификаты от этого удостоверяющего центра, только создаются они с помощью автоматического скрипта панели управления Vesta. А для чего вы используете Let’s Encrypt? Напишите в комментариях!

Предисловие

Добро пожаловать, уважаемые читатели!
В одном из своих циклов статей, я реализовывал возможность обращаться к различным сервисам через поддомены.
В последней статье про Plex один из читателей поинтересовался, а почему не завести все запросы с http(80) и https(443) на единый nginx?

Собственно, «а почему нет?» и я решил изменить подход, прикрутив SSL на https(443). Браузеры нынче очень не любят непонятные сертификаты для https. Меня это раздражало в Proxmox, он работает на https по умолчанию, но сертификаты не доверенные.
Вот тот самый цикл статей:

1. Домашний Сервер: Часть 1 – Предисловие, аппаратная и софтовая начинка
2. Домашний Сервер: Часть 2 – Установка системы виртуализации Proxmox
3. Домашний Сервер: Часть 3 – Внутренний DNS сервис на BIND9 или свои доменные имена в локальной сети
4. Домашний Сервер: Часть 4 – Настройка Transmission daemon в контейнере LXC Proxmox-VE
5. Домашний Сервер: Часть 5 – Установка и настройка Plex Media Server в контейнере LXC Proxmox-VE

Подготовка

Для того, чтобы все завести на один Nginx, я решил запустить отдельный LXC контейнер.
Ставим необходимое в контейнере. (Как поставить LXC контейнер, можно найти в цикле статей)

apt install nginx git -y

Клонируем файлы клиента Certbot

git clone https://github.com/certbot/certbot /opt/letsencrypt
ln -s /opt/letsencrypt/certbot-auto /usr/bin/certbot

Тут я хочу остановится подробнее.
Я поставил себе задачу, чтобы можно было через поддомены открывать свои сервисы, как в локальной сети, так и из интернета.
Для этого необходимо будет перенаправить 80 и 443 порты на данный контейнер. Но об этом чуть позже.
Let’s Encrypt обычно требует, чтобы ваш IP адрес на который назначен домен или поддомен был доступен из вне, но т.к. у меня вся сеть закрыта Firewall-ом роутера возникают сложности. Можно было бы найти IP адреса сервисов Let’s Encrypt, но это не благодарное занятие.
Помочь в этой ситуации может Wildcard сертификат.

Let’s Encrypt реализовал возможность получения Wildcard сертификата в марте 2018 года (14 марта 2018)
Я буду получать сертификат для поддомена первого уровня, а все сервисы повешу на поддомены второго уровня и мне не придется получать сертификаты для каждого сервиса по отдельности.
У меня есть хостинг и управление доменом я веду на нем. Чтобы была возможность заходить на поддомены сервисов, вам необходим основной домен доступный из интернета.

Для домена на своем хостинге нужно создать основной поддомен, для примера я возьму такой:
home.gregory-gost.ru

Запускаем certbot для получения сертификата.

certbot certonly --agree-tos -d home.gregory-gost.ru -d *.home.gregory-gost.ru --preferred-challenges dns --manual --server https://acme-v02.api.letsencrypt.org/directory --manual-public-ip-logging-ok

Please deploy a DNS TXT record under the name
_acme-challenge.home.gregory-gost.ru with the following value:

fgfgDFDFuReJBUTYbYO71os_BKdfJDJFdfhfHDHFDFJHFD

Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

Certbot будет выдавать такие сообщения. У меня было два таких.
Нужно занести обе TXT записи в DNS настройки основного домена. Также добавить/заменить А запись, своим статическим IP роутера, в поддоменах.

Сертификаты будут лежать по пути
/etc/letsencrypt/live/home.gregory-gost.ru/

Далее создаем поддомены второго уровня для сервисов: plex.home.gregory-gost.ru и т.д.

В Cron появится файл автоматической проверки и продления сертификата.
Проверим это правило:

cat /etc/cron.d/certbot

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
#
# Important Note!  This cronjob will NOT be executed if you are
# running systemd as your init system.  If you are running systemd,
# the cronjob.timer function takes precedence over this cronjob.  For
# more details, see the systemd.timer manpage, or use systemctl show
# certbot.timer.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(43200))' && certbot -q renew

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

Файл конфигурации лежит по пути: /etc/letsencrypt/renewal/home.gregory-gost.ru.conf
Для того, чтобы выполнить какую-либо команду ДО или ПОСЛЕ обновления сертификатов у Certbot есть специальные ключи

• —pre-hook — выполнять команду перед запуском certboot
• —post-hook — выполнять команду после запуска certboot
• —renew-hook — выполнять команду только после успешного продления сертификата

Самым удобным в этом случае выглядит ключ —renew-hook, он позволяет перезапускать службы только после успешного продления сертификата, а не просто дважды в день, как у ключа —post-hook
Добавим команду перезапуска в файл конфигурации, в раздел [renewalparams]:

nano /etc/letsencrypt/renewal/home.gregory-gost.ru.conf

# renew_before_expiry = 30 days
version = 0.28.0
archive_dir = /etc/letsencrypt/archive/home.gregory-gost.ru
cert = /etc/letsencrypt/live/home.gregory-gost.ru/cert.pem
privkey = /etc/letsencrypt/live/home.gregory-gost.ru/privkey.pem
chain = /etc/letsencrypt/live/home.gregory-gost.ru/chain.pem
fullchain = /etc/letsencrypt/live/home.gregory-gost.ru/fullchain.pem

# Options used in the renewal process
[renewalparams]
authenticator = manual
account = 9471dfdhjdhghg1a8c1a2a07fde01
pref_challs = dns-01,
manual_public_ip_logging_ok = True
server = https://acme-v02.api.letsencrypt.org/directory
renew-hook = service nginx restart

Делаем проверку на продление сертификата проще.
Удаляем или комментируем строки в файле /etc/cron.d/certbot и копируем файл в /etc/cron.weekly

cp /etc/cron.d/certbot /etc/cron.weekly/
chmod +x /etc/cron.weekly/certbot

nano /etc/cron.weekly/certbot

#!/bin/bash
/usr/bin/certbot -q renew

certbot certonly --agree-tos -d home.gregory-gost.ru -d *.home.gregory-gost.ru --preferred-challenges dns --manual --server https://acme-v02.api.letsencrypt.org/directory --manual-public-ip-logging-ok

Далее настраиваем nginx.

Файлы конфигурации nginx

nano /etc/nginx/snippets/letsencrypt.conf

location ^~ /.well-known/acme-challenge/ {
        allow all;
        root /var/lib/letsencrypt/;
        default_type "text/plain";
        try_files $uri =404;
}

error_log               /var/log/nginx/error.log crit;
pid                     /var/run/nginx.pid;
worker_rlimit_nofile    8192;
timer_resolution        100ms;
include                 /etc/nginx/modules-enabled/*.conf;

events {
        multi_accept    on;
        accept_mutex    off;
        use             epoll;
}

http {
        include         /etc/nginx/mime.types;
        include         /etc/nginx/fastcgi.conf;
        default_type    application/octet-stream;

        sendfile        on;
        tcp_nopush      on;
        tcp_nodelay     on;

        #ssl_session_cache      shared:SSL:10m;
        #ssl_session_timeout    10m;

        include         /etc/nginx/conf.d/*.conf;

}

upstream home.gregory-gost.ru  {
        server 192.168.88.6:8006;
}

server {
        listen 80;
        server_name home.gregory-gost.ru;

        include snippets/letsencrypt.conf;
        return 301 https://$host$request_uri;
}

server {
        listen 443 ssl;
        server_name home.gregory-gost.ru;

        include snippets/letsencrypt.conf;

        ssl_certificate /etc/letsencrypt/live/home.gregory-gost.ru/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/home.gregory-gost.ru/privkey.pem;

        proxy_redirect off;
        location / {
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade"; 
                proxy_pass https://home.gregory-gost.ru;
                proxy_buffering off;
                client_max_body_size 0;
                proxy_connect_timeout  3600s;
                proxy_read_timeout  3600s;
                proxy_send_timeout  3600s;
                send_timeout  3600s;
        }
}

upstream torrent.home.gregory-gost.ru {
        server          192.168.88.9:9091;
        keepalive       32;
}

server {
        listen 80;
        server_name torrent.home.gregory-gost.ru;

        include snippets/letsencrypt.conf;
        return 301 https://$host$request_uri;
}

server {
        listen 443 ssl;
        server_name torrent.home.gregory-gost.ru;

        include snippets/letsencrypt.conf;

        ssl_certificate /etc/letsencrypt/live/home.gregory-gost.ru/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/home.gregory-gost.ru/privkey.pem;

        send_timeout    100m;

        gzip            on;
        gzip_vary       on;
        gzip_min_length 1000;
        gzip_proxied    any;
        gzip_types      text/plain text/css text/xml application/xml text/javascript application/x-javascript image/svg+xml;
        gzip_disable "MSIE [1-6]\.";

        client_max_body_size 100M;

        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        proxy_redirect off;
        proxy_buffering off;

        location / {
                #rewrite ^/$ http://$http_host;
                proxy_pass http://torrent.home.gregory-gost.ru;
        }

}

upstream plex.home.gregory-gost.ru {
        server          192.168.88.8:32400;
        keepalive       32;
}

server {
    listen 80;
    server_name plex.home.gregory-gost.ru;

    include snippets/letsencrypt.conf;
    return 301 https://$host$request_uri;
}

server {
        listen          443 ssl;
        server_name     plex.home.gregory-gost.ru;

        #access_log  /var/log/nginx/plex.home.gregory-gost.ru.access.log;
        error_log  /var/log/nginx/plex.home.gregory-gost.ru.error.log;

        send_timeout    100m;

        gzip            on;
        gzip_vary       on;
        gzip_min_length 1000;
        gzip_proxied    any;
        gzip_types      text/plain text/css text/xml application/xml text/javascript application/x-javascript image/svg+xml;
        gzip_disable "MSIE [1-6]\.";

        client_max_body_size 100M;

        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        proxy_redirect off;
        proxy_buffering off;

        include snippets/letsencrypt.conf;

        ssl_certificate /etc/letsencrypt/live/home.gregory-gost.ru/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/home.gregory-gost.ru/privkey.pem;

        location / {
                if ($http_x_plex_device_name = '') {
                        rewrite ^/$ https://$http_host/web/index.html;
                }
                proxy_pass https://plex.home.gregory-gost.ru;
        }

}

upstream openhab.home.gregory-gost.ru {
        server 192.168.88.10:8080;
        keepalive 32;
}

server {
        listen 80;
        server_name openhab.home.gregory-gost.ru;

        include snippets/letsencrypt.conf;
        return 301 https://$host$request_uri;
}

server {
        listen 443 ssl;
        server_name openhab.home.gregory-gost.ru;

        include snippets/letsencrypt.conf;

        ssl_certificate /etc/letsencrypt/live/home.gregory-gost.ru/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/home.gregory-gost.ru/privkey.pem;

        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_redirect off;
                proxy_set_header Host $http_host;
                proxy_pass http://openhab.home.gregory-gost.ru;
        }
}

Другие сервисы по аналогии.

Перенастройка локальных доменных зон

Само собой необходимо изменить основной IP адрес для доменных зон в bind9
Открываю зону прямого просмотра и редактирую

nano /etc/bind/zone/db.gregory-gost.ru

;
; Zone Front view
;
$TTL 3600
@               IN      SOA     gregory-gost.ru.        email.gregory-gost.ru. (
        2019122702      ; Serial
                1d      ; Refresh
                1h      ; Retry
                1w      ; Expire
                2h      ; Negative Cache TTL
)

@               IN      NS      ns1.example.ru.
www             IN      CNAME   gregory-gost.ru.

@               IN      NS      ns.gregory-gost.ru.
ns              IN      A       192.168.88.7

home                    IN      A       192.168.88.14
plex.home               IN      A       192.168.88.14
torrent.home            IN      A       192.168.88.14
openhab.home            IN      A       192.168.88.14

Окрываю зону обратного просмотра и также редактирую

nano /etc/bind/zone/db.gregory-gost.ru.inverse

;
; Zones invert view
;
$TTL 3600
@               IN      SOA     gregory-gost.ru.  email.gregory-gost.ru. (
        2019122702      ; Serial
                1d      ; Refresh
                1h      ; Retry
                1w      ; Expire
                2h      ; Negative Cache TTL
)

@               IN      NS      ns1.example.ru.
@               IN      NS      ns.gregory-gost.ru.
7               IN      PTR     ns.gregory-gost.ru.

14              IN      PTR     home.gregory-gost.ru.
14              IN      PTR     plex.home.gregory-gost.ru.
14              IN      PTR     torrent.home.gregory-gost.ru.
14              IN      PTR     openhab.home.gregory-gost.ru.

На примере роутера MikroTik приведу правила перенаправления 80 и 443 порта:

/ip firewall nat
add action=dst-nat chain=dstnat comment="HTTP(S) to LXC" dst-port=80 in-interface-list=Internet protocol=tcp src-address-list="Access IP" to-addresses=192.168.88.14 to-ports=80
add action=dst-nat chain=dstnat dst-port=443 in-interface-list=Internet protocol=tcp src-address-list="Access IP" to-addresses=192.168.88.14 to-ports=443

Соответственно src-address-list=»Access IP» это список разрешенных адресов прошедших PortKnocking.

На этом можно закончить, все должно работать.
У меня точно работает 🙂

Как это работает?

Немного расскажу, как это работает с точки зрения обычного пользователя. Т.е. тут не будет каких-то объемных технических подробностей по работе DNS или Nginx.
Опишу два примера, один это запрос с устройства из локальной сети, а второй это запрос с устройства откуда-то из интернета.
Запрашивать буду доменное имя:
— plex.home.gregory-gost.ru

Давайте посмотрим, что происходит в первом случае:

1. Мы на локальном устройстве с IP адресом 192.168.88.40 пытаемся открыть в браузере WEB интерфейс Plex Media Server
2. Т.к. мы запросили доменное имя, то необходимо распознать это имя в IP адрес. В локальной сети всем устройствам выдаются DNS адреса 192.168.88.7 и 192.168.88.1
   Это означает, что первый DNS запрос попадет на IP 192.168.88.7 на котором у нас в свою очередь работает DNS сервер BIND9
3. BIND9 получив такой запрос проводит сверку по спискам доступа ACL, далее проверяет есть ли такая запись в его базе.
   Если записи нет, отправляет запрос дальше. Например может отправить на роутер с IP адресом 192.168.88.1 согласно спискам ACL, а роутер отправит его провайдеру(если роутер получает от провайдера DNS) и т.д. пока доменное имя не преобразуется в IP адрес
   Нам повезло, имя home.gregory-gost.ru есть в базе BIND9 и вот, что там написано:

   cat /etc/bind/zone/db.gregory-gost.ru
   plex.home   IN   A   192.168.88.14

   cat /etc/bind/zone/db.gregory-gost.ru.inverse
   14   IN   PTR   plex.home.gregory-gost.ru.

4. Как мы видим DNS сервер преобразует имя и направляет нас на IP адрес: 192.168.88.14
5. IP 192.168.88.14 в свою очередь привязан к LXC контейнеру на котором установлен Nginx.
   Nginx слушает стандартные WEB порты 80 и 443. Наш запрос приходит на 80 порт т.к. мы указали http: и не указывали принудительно https:
6. Создаваемые для Nginx файлы конфигураций работают на одном порту, но отвечают за различные сервисы.
   Nginx решает, какой из файлов «серверов» должен обработать запрос с помощью сравнения заголовка Host в запросе, оно же «доменное имя», которое мы запросили.
   Пример запроса браузера Opera. Вы можете найти заголовок Host самостоятельно:

   GET / HTTP/1.1
   Host: plex.home.gregory-gost.ru
   Connection: keep-alive
   Upgrade-Insecure-Requests: 1
   User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36 OPR/65.0.3467.78
   Sec-Fetch-User: ?1
   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
   Sec-Fetch-Site: none
   Sec-Fetch-Mode: navigate
   Accept-Encoding: gzip, deflate, br
   Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7

   Заголовки(Headers): https://ru.wikipedia.org/wiki/Список_заголовков_HTTP

7. В конфигурационных файлах Nginx указаны непосредственные IP адреса и порты служб, которые могут работать совершенно в разных контейнерах, устройствах, виртуальных средах и т.д.
   Например в этом файле nginx указан IP адрес и порт на котором работает Plex Media Server

   cat /etc/nginx/conf.d/plex.conf

   upstream plex.pve.gregory-gost.ru {
           server          192.168.88.8:32400;
           keepalive       32;
   }

   location / {
                   if ($http_x_plex_device_name = '') {
                           rewrite ^/$ https://$http_host/web/index.html;
                   }
                   proxy_pass https://plex.pve.gregory-gost.ru;
           }

   А это непосредственное перенаправление на страницу https://192.168.88.8:32400/web/index.html

8. В результате, в окне браузера под адресом plex.home.gregory-gost.ru мы видим тоже самое, что увидели бы при прямом заходе на https://192.168.88.8:32400/web/index.html
   Единственное, мы через Nginx дополнительно подключили сертификат SSL, поэтому мы можем спокойно использовать https: вместо простого http:

Давайте посмотрим, что происходит во втором случае:

1. Мы на каком-то устройстве с динамическим рандомным IP адресом пытаемся открыть в браузере WEB интерфейс Plex Media Server, например сидя в кафе или у друзей.
2. Т.к. мы запросили доменное имя, то необходимо, все также, распознать это имя в IP адрес. Только делать это будет уже сервис, где мы проводили регистрацию домена, по другому это еще называется «парковка» домена.
   Чтобы запрос корректно обрабатывался в панели администрирования необходимо добавить все необходимые поддомены по аналогии с локальной реализацией.
   Отличием будет, удобное добавление через панель управления сервиса и необходимость указывать статический IP адрес, выданный нашему роутеру провайдером.
   Например у меня домен обслуживает хостинг провайдер, у которого также обслуживается сам сайт и есть удобная панель управления. У разных хостеров и регистраторов разные панели управления!

   

   

   

3. При вводе доменного имени, запрос так или иначе попадет к нашему хостеру и его DNS служба перенаправит нас на указанный, в «A» записи, IP адрес и порт.(стандартно — http: 80 и https: 443)
4. Т.к. мы указываем в «А» записи, статический IP адрес нашего роутера, то запрос попадет на роутер. Тут-то и необходимо правило перенаправления 80 и 443 порта.
   Но перенаправлять мы будем уже не на BIND9, а сразу на LXC контейнер с Nginx с адресом 192.168.88.14. BIND9 в этом случае не требуется т.к. запрос идет извне нашей локальной среды.
5. Далее обработка идет по аналогии с первым случаем.

Надеюсь мне удалось объяснить принцип взаимодействия с доменными именами, как из локальной сети, так и из глобальной интернет среды.

Заключение

Вот таким не хитрым способом можно уйти от использования IP адресов для своих сервисов в локальной домашней или офисной сети. Заходить по одному домену, как из внешних сетей, так и внутри локальной сети.
На последок, одно важное замечание!

Благодарю за ваше время!
Всего хорошего на просторах Интернета 😉

UPD 05.01.2020:
Добавлен блок «Как это работает?» для более лучшего понимания процесса запрос-ответ.

Получение бесплатного SSL сертификата Let’s Encrypt

Обновлено: 27.11.2023
Опубликовано: 22.05.2017

Тематические термины: Let’s Encrypt, CentOS, Ubuntu

Процесс в данной статье описан на примере систем Linux CentOS, Ubuntu (Debian) и Windows. Настройка выполняется в несколько шагов.

Условия получения бесплатного сертификата от Let’s Encrypt

Прежде чем начать, необходимо знать о некоторых нюансах получения сертификата Let’s Encrypt:

• При запросе выполняется проверка домена. Для этого необходимо:
  1. либо создать TXT-запись в DNS.
  2. либо поднять веб-сервер, далее в его корне создается каталог .well-known, а в нем файл с произвольным названием. После корневой центр отправляет запрос серверу на загрузку данного файла и, в случае успеха, выдает сертификаты для указанного доменного имени.
• SSL-сертификат выдается на 90 дней, поэтому необходимо по расписанию запускать команду на автоматическое продление ключа. Когда проходит 60 дней после начала использования нового сертификата, центр Let’s Encrypt может выдать новый.
• Если выполнять запрос для домена 3 уровня и выше, он должен пройти DNS проверку на всех уровнях. Например, домен layer3.layer2.com должен отвечать на запросы как для layer3.layer2.com, так и для layer2.com.

Проверка домена

Как было сказано выше, для получения бесплатного сертификата, Let’s Encrypt должен удостовериться, что мы являемся владельцем домена. Свое право на его владение мы можем подтвердить, создав специальную TXT-запись или настроив веб-сервис, который будет отвечать на запросы.

Настройка веб-сервера

Данный способ немного сложнее для Linux (для Windows все настройки делает утилита автоматически), но позволяет без проблем настроить автоматическое продление.

Запрашивать сертификат Let’s Encrypt проще всего с веб-сервера, на котором запущен сайт для домена. Возможен альтернативный вариант с монтирование сетевой папки, но его рассматривать не будем.

Linux NGINX

Пример простого конфигурационного файла для NGINX:

server {
    listen       80;
    server_name  dmosk.ru;
    root   /usr/share/nginx/html;
}

* где dmosk.ru — домен, для которого работает сайт и для которого мы будем запрашивать сертификат; /usr/share/nginx/html — путь по умолчанию для nginx.

Если сервер уже используется для сайта, в секцию server добавляем:

location ~ /.well-known {
    root /usr/share/nginx/html;
    allow all;
}

* данными строчками мы говорим, что для всех запросов после /.well-known необходимо отдавать скрипты из каталога /usr/share/nginx/html; allow all предоставляет доступ всем.

При необходимости выполнять проверку и использовать rewrite/return, добавляем что-то подобное:

    …
    location ~ /.well-known {
        root /usr/share/nginx/html;
        allow all;
    }
    if ($uri !~ /.well-known){
        return 301 https://$host$request_uri;
    }

После проверяем конфигурацию и перезапускаем nginx:

nginx -t && nginx -s reload

Linux Apache

Создаем общий конфигурационный файл, в котором пропишем алиас.

а) для CentOS:

vi /etc/httpd/conf.d/lets.conf

б) для Ubuntu / Debian:

vi /etc/apache2/conf-enabled/lets.conf

Со следующим содержимым:

Alias /.well-known/acme-challenge/ /var/www/html/.well-known/acme-challenge/

* в данном примере, запросы для страниц /.well-known/acme-challenge всех сайтов мы переводим в каталог /var/www/html/.well-known/acme-challenge.

Проверяем корректность конфигурационного файла:

apachectl configtest

И перезапускаем apache:

systemctl restart httpd || systemctl restart apache2

Windows

IIS должен отвечать на http-запрос до доменному имени, для которого мы планируем получить сертификат. Также в его настройках мы должны сделать привязку узла, для которого хотим получить сертификат к конкретному сайту. Для этого в консоли управления IIS раскрываем сайты и выбираем нужный нам (в данном примере, он всего один):

В меню справа кликаем по Привязки:

Изменяем привязку для имеющийся записи и, при необходимости, добавляем еще:

Применяем настройки и закрываем консоль управления IIS.

С помощью записи в DNS

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

У нас должна быть возможность управления записями в DNS. На данном этапе достаточно просто зайти в панель управления DNS и перейти к этапу получения сертификата (ниже по тексту). Если домен новый и был только-что делегирован на DNS, возможно, придется подождать, пока он не станет доступен для всех серверов DNS в глобальной сети.

Установка утилиты для получения сертификата

Certbot для Linux

1) Rocky Linux:

dnf install epel-release

dnf install certbot

2) на CentOS 8:

dnf —enablerepo=powertools install certbot

3) на CentOS 7:

yum install certbot

4) на Ubuntu 16.04 и выше, а также Debian:

apt update

apt install certbot

5) Универсальный через python-pip:

Пакет certbot является приложением python и для его установки нужно использовать модуль pip. Сам модуль также нужно поставить. В зависимости от дистрибутива Linux наша команда будет отличаться.

а) Для систем на базе DEB:

apt install python3-pip

б) Для систем на базе RPM:

yum install python3-pip

После установки пакета нам доступен модуль pip. Используем его для установки certbot.

Начнем с обновления самого модуля:

python3 -m pip install —upgrade pip

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

python3 -m pip install certbot

6) Astra Linux:

Для астры не нашел репозитория установки certbot, но есть решение хоть и не красивое, но рабочее.

Загружаем deb-файлы для debian 10:

wget http://ftp.de.debian.org/debian/pool/main/p/python-certbot/certbot_0.31.0-1+deb10u1_all.deb

wget http://ftp.de.debian.org/debian/pool/main/p/python-certbot/python3-certbot_0.31.0-1+deb10u1_all.deb

Пробуем установить python3-certbot:

dpkg -i python3-certbot_0.31.0-1+deb10u1_all.deb

Если мы получим ошибку зависимостей, например:

dpkg: зависимости пакетов не позволяют настроить пакет python3-certbot:
 python3-certbot зависит от python3-acme (>= 0.29.0~), однако:
  Пакет python3-acme не установлен.
 python3-certbot зависит от python3-configargparse (>= 0.10.0), однако:
  Пакет python3-configargparse не установлен.
 python3-certbot зависит от python3-josepy, однако…

… выполняем команду:

apt install -f

Также мы можем посмотреть список зависимостей командой:

dpkg -I python3-certbot_0.31.0-1+deb10u1_all.deb

Будет выполнена установка зависимостей. После устанавливаем скачанные пакеты:

dpkg -i python3-certbot_0.31.0-1+deb10u1_all.deb

dpkg -i certbot_0.31.0-1+deb10u1_all.deb

7) на CentOS 6 или Ubuntu 14.04 / 12.04:

Создадим каталог, в котором будет храниться утилита и переходим в него:

mkdir /opt/certbot

cd /opt/certbot

Загружаем утилиту и разрешаем ее запуск:

wget https://raw.githubusercontent.com/certbot/certbot/7f0fa18c570942238a7de73ed99945c3710408b4/letsencrypt-auto-source/letsencrypt-auto -O /opt/certbot/letsencrypt-auto

chmod a+x ./letsencrypt-auto

Для удобства, делаем симлинк:

ln -s /opt/certbot/letsencrypt-auto /usr/local/sbin/certbot

Запустим команду:

certbot

При первом запуске certbot он автоматически предложит доустановить необходимые зависимости — соглашаемся.

LetsEncrypt-Win-Simple для Windows

На сайте GitHub скачиваем win-acme pluggable для нужной разрядности операционной системы:

Раcпаковываем скачанный архив в любую папку.

Первое получение сертификата

Linux

1. Если мы подтверждаем право на домен при помощи веб-сервера, выполняем команду с таким синтаксисом:

certbot certonly —webroot —agree-tos —email <почта администратора домена> —webroot-path <путь до каталога с файлами проверки> -d <домен 1> -d <домен 2> -d …

* где:

• certonly — запрос нового сертификата;
• webroot — проверка будет выполняться на основе запроса к корню сайта;
• agree-tos — даем согласие на лицензионное соглашение;
• email — почтовый адрес администратора домена;
• webroot-path — каталог в системе Linux, который является корневым для сайта;
• d — перечисление доменов, для которых запрашиваем сертификат.

а) Пример запроса при использовании веб-сервера NGINX:

certbot certonly —webroot —agree-tos —email postmaster@dmosk.ru —webroot-path /usr/share/nginx/html/ -d dmosk.ru -d www.dmosk.ru

б) Пример запроса при использовании веб-сервера Apache:

certbot certonly —webroot —agree-tos —email postmaster@dmosk.ru —webroot-path /var/www/html/ -d dmosk.ru -d www.dmosk.ru

После успешного выполнения команды, сертификаты будут созданы в каталоге /etc/letsencrypt/archive/dmosk.ru, а также симлинки на них в каталоге /etc/letsencrypt/live/dmosk.ru. При настройке приложений, стоит указывать пути до симлинков, так как при обновлении файлы в первом каталоге будут меняться, во втором — нет. Публичный ключ будет с именем cert.pem, а приватный — privkey.pem.

2. При подтверждении права на домен с TXT-записью:

certbot certonly —manual —agree-tos —email postmaster@dmosk.ru —preferred-challenges=dns -d dmosk.ru -d www.dmosk.ru

* где:

• certonly — запрос нового сертификата;
• manual — проверка домена вручную.
• preferred-challenges — указывает метод проверки домена.
• agree-tos — даем согласие на лицензионное соглашение;
• email — почтовый адрес администратора домена;
• d — перечисление доменов, для которых запрашиваем сертификат.

На запрос подтверждения отвечаем Y — система выдаст что-то на подобие:

* Данное сообщение говорит, что мы должны создать TXT-запись _acme-challenge.dmosk.ru со значением W2SC9b88y2j2oUjhxVgS7Bphph9g5PqhkBq9KiWkLTm.

Создаем соответствующую запись в панели управления DNS, и в консоли сервера нажимаем Enter для продолжения. Если, как в данном примере, мы запрашиваем сертификат для нескольких узлов, повторяем действия.

Windows

Открываем командную строку от администратора и переходим в распакованный каталог. Например, если архив распакован на диск C, выполняем:

cd C:\win-acme.v2.1.6.773.x64.pluggable

* где 2.1.6.773.x64 — моя версия утилиты.

Запускаем wacs:

wacs.exe

Если запускаем в Powershel, то так:

.\wacs.exe

Утилита формирует бинарный сертификат для Windows, но если мы хотим получить файлы в формате pem, вводим:

wacs.exe —store pemfiles —pemfilespath C:\Certificates

* где pemfilespath — путь до каталога, в котором должны оказаться файлы сертификата.

Откроется меню с выбором действия — вводим N, чтобы создать новый сертификат:

Обратите внимание, что в зависимости от версии win-acme, некоторые пункты могут отличаться. Внимательно просмотрите варианты.

Выбираем сайт в IIS, который отвечает на запросы нашего домена (в нашем случае, это единственный Default Web Site, то есть 1):

Если для сайта создано несколько привязок, выбираем 3, чтобы создать сертификаты для всех:

Вводим email адрес и подтверждаем корректность данных:

Утилита создаст необходимый каталог для проверки домена, запросит проверку, получит сертификат, добавит привязку к сайту по 443 порту с добавлением полученного сертификата и создаст в планировщике задание на автоматическое продление сертификата.

Автоматическое продление

Утилита certbot позволяет выполнить обновление сертификата в автоматическом режиме. В зависимости от операционной системы, инструменты различаются.

Linux

Смотрим полный путь до скрипта certbot:

which certbot

Открываем на редактирование cron и добавляем следующее:

crontab -e

Если система вернет ошибку crontab: command not found, устанавливаем пакет cron и запускаем сервис.

а) Для deb-систем:

apt install cron

systemctl start cron

systemctl enable cron

б) Для rpm-систем:

yum install cronie

systemctl start crond

systemctl enable crond

Прописываем строки в зависимости от нашей системы Linux.

а) для Ubuntu / Debian / Rocky Linux:

0 0 * * 1,4 /usr/bin/certbot renew —noninteractive

б) для CentOS:

0 0 * * 1,4 /bin/certbot renew —noninteractive

* в данном примере проверка и продление сертификата будет выполняться по понедельникам и четвергам (1,4) в 00:00. /usr/bin/certbot или /bin/certbot — путь, который мне выдала команда which certbot.

Команда certbot renew проверяет для всех наших сертификатов срок окончания, и если осталось менее 30 дней, запрашивает новый, сохраняет его в каталоге /etc/letsencrypt/archive/<домен> и обновляет симлинк.

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

systemctl reload nginx

Однако, нам нужно, чтобы это происходило автоматически. Для этого открываем файл:

vi /etc/letsencrypt/cli.ini

И добавляем строку:

…
deploy-hook = systemctl reload nginx

Windows

Настройка задания на автоматическое продление создается при получении сертификата. Проверить задание можно в планировщике заданий Windows:

Wildcard

С марта 2018 года появилась возможность получить бесплатный сертификат на все поддомены, например, mail.dmosk.ru, test.dmosk.ru, admin.dmosk.ru (*.dmosk.ru).

Особенности получения Wildcard от Let’s Encrypt:

1. Подтвердить право использования доменом можно только с помощью DNS — таким образом, затрудняется процесс автоматического продления. Нужно использовать плагины, которые позволяют автоматически создавать нужную запись на DNS, но они доступны далеко не для всех поставщиков услуг DNS. В противном случае, обновлять Wildcard нужно вручную.
   Также, некоторые панели управления хостингом, например ISP Manager с версии 5 могут управлять процессом получения Wildcard от Let’s Encrypt с возможностью автоматического продления (но необходимо, чтобы домен обслуживался на данном хостинге).
2. Время действия сертификата также ограничено 3 месяцами.

Certbot

Необходимо, чтобы версия утилиты certbot была 0.22.0 и выше. Проверить текущую версию можно командой:

certbot —version

… если версия ниже, обновляем ее командами:

а) для CentOS / Red Hat:

yum update certbot

б) для Ubuntu / Debian: 

apt update

apt install —only-upgrade certbot

Процесс получения

Процесс очень похож на процесс получения сертификата с подтверждением домена в DNS.

Вводим команду:

certbot certonly —manual —agree-tos —email master@dmosk.ru —server https://acme-v02.api.letsencrypt.org/directory —preferred-challenges=dns -d dmosk.ru -d *.dmosk.ru

* обратим внимание на 2 детали: 1) мы добавили опцию server, чтобы указать, на каком сервере Let’s Encrypt должна проходить проверка DNS; 2) мы получаем сертификат как для *.dmosk.ru, так и самого dmosk.ru, так как первое не включает второго.

… система попросит создать TXT-запись в DNS, который обслуживает наш домен:

* в данном примере система попросила создать TXT-запись _acme-challenge.dmosk.ru со значением DN8ovKFJ0leLQV9ofZ81mYKxojwIaed5g6f0bXZCYiI.

Заходим в панель управления DNS и создаем нужную запись. Если у нас свой сервер DNS, например, bind, то строка будет такой:

; TXT
_acme-challenge IN      TXT     DN8ovKFJ0leLQV9ofZ81mYKxojwIaed5g6f0bXZCYiI

Не торопимся нажимать Enter — после настройки DNS нужно немного времени (пару минут), чтобы настройка применилась. Проверить появление записи можно командой с рабочего компьютера:

nslookup -type=txt _acme-challenge.dmosk.ru 8.8.8.8

Как только видим, что настройки применились, нажимаем Enter — если это наш первый запрос Wildcard для данного домена, то система нас попросит создать еще одну запись — повторяем процедуру, создав в DNS вторую запись TXT.

Если все сделали правильно, то увидим:

… сертификат получен.

Полезные команды

Рассмотрим некоторые полезные команды утилиты certbot для работы с сертификатами Let’s Encrypt.

1. Показать группы сертификатов:

certbot certificates

2. Удалить сертификат:

certbot delete dmosk.ru

После получения сертификата мы не сможем экспортировать его с закрытым ключом. Мы можем изменить поведение, открыв файл settings.json в распакованном каталоге win-acme. Находим параметр PrivateKeyExportable и задаем ему значение:

«PrivateKeyExportable»: true,

После обновляем сертификат:

.\wacs.exe —renew —force

Или без обновления сертификата мы можем найти файл .pfx в каталоге: %programdata%\win-acme\$baseuri$\certificates.

Пароль для pfx можно найти в интерактивном меню wacs:

Manage Renewals > Show details

Сертификат Let’s Encrypt для почтового сервера MS Exchange

В комплекте установленного нами LetsEncrypt-Win-Simple для Windows идет скрипт ImportExchange.v2.ps1. Он нужен для импорта сертификата в конфигурацию почтового сервера MS Exchange.

Для начала создадим каталог, куда будет выгружен сертификат. В моем примере я воспользуюсь путем C:\SSL.

Допустим, что адрес подключения к серверу будет exchange.dmosk.ru. Тогда получить сертификат и импортировать его в Exchange можно командой:

wacs.exe —source manual —host exchange.dmosk.ru,autodiscover.dmosk.ru —store centralssl,certificatestore —certificatestore My —acl-fullcontrol «network service,administrators» —centralsslstore «C:\SSL» —installation iis,script  —installationsiteid 1 —script «./Scripts/ImportExchange.v2.ps1» —scriptparameters «‘{CertThumbprint}’ ‘IIS,SMTP,IMAP’ 1 ‘{CacheFile}’ ‘{CachePassword}’ ‘{CertFriendlyName}'»

* данная команда запросит сертификат для узлов exchange.dmosk.ru и autodiscover.dmosk.ru, сохранит нужные файлы в каталоге C:\SSL и импортирует полученные ключи в Microsoft Exchange Server.

Если мы запускаем команду в оболочке PowerShel, клманда должна начинаться с:

.\wacs.exe …

После успешного выполнения команды, заходим в консоль управления сервером, переходим на вкладку управления сертификатами. В списке мы должны увидеть полученную последовательность от Let’s Encrypt. Кликаем по ней и назначаем сертификат для нужных служб Exchange (как правило, SMTP, IIS).

Возможные ошибки

Рассмотрим некоторые ошибки, с которыми мы можем столкнуться.

Missing command line flag or config entry for this setting

Ошибка появляется при попытке обновить сертификат для одного или нескольких доменов.

Причина: при обновлении сертификата, утилита certbot ищет настройки в конфигурационном файле /etc/letsencrypt/renewal/<имя домена>.conf. Если в данном файле не будет определена конфигурация для webroot_map, мы получим данную ошибку.

Решение:

Открываем конфигурационный файл для домена, например:

vi /etc/letsencrypt/renewal/dmoks.ru.conf

Находим опцию webroot_map (как правило, в самом низу). Либо она будет пустой, либо указывать на неправильный путь. Исправляем это:

dmoks.ru = /usr/share/nginx/html

* мы указываем домен и каталог, в котором будет создаваться проверочный файл.

Пробуем обновить сертификат.

ACMEv1 is deprecated and you can no longer get certificates from this endpoint

Ошибка появляется при попытке запросить или обновить сертификат. Полный текст ошибки:

Attempting to renew cert (xxx) from /etc/letsencrypt/renewal/xxx.conf produced an unexpected error: urn:acme:error:serverInternal :: The server experienced an internal error :: ACMEv1 is deprecated and you can no longer get certificates from this endpoint. Please use the ACMEv2 endpoint, you may need to update your ACME client software to do so. Visit https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430/27 for more information.. Skipping.

Причина: утилита на компьютере устарела. Она пытается использовать API-портал ACMEv1, который больше не поддерживается.

Решение: обновляем утилиту certbot.

а) Для Ubuntu/Debian:

apt update

apt —only-upgrade install certbot

б) Для Rocky Linux/CentOS:

yum update certbot

Читайте также

Другие полезные материалы:

1. Примеры редиректов в NGINX.

2. Настройка Apache + SSL для работы сайта по HTTPS.