Выпуск ssl-сертификата на OpenWRT

Статья написана по причине, что настройка Let’s encrypt для выдачи сертификата для сайта имеет несколько особенностей при использовании OpenWRT прошивки и менеджера пакетов opkg, в отличие от стандартнго certbot. Этот достаточно извращенный вариант может понадобиться, если вы решили захостить свой блог на домашнем роутере. В моем случае это Keenetic, белый ip от провайдера прилагается. Инструкция актуальна на июль 2024г.

Установка пакетов

Пропустим включение и настройку OpenWRT на роутере, это было сделано ранее. Устанавливаем два пакета, второй понадобится для запроса сертификата Let’s encrypt по 443 порту.

opkg update
opkg install uacme uacme-ualpn

Проверка по http-01

Стандартный подход предполагает для проверки прав на домен выкладывание текстового файла с определенным именем и токеном внутри по заданному пути сайта. Проверка проходит строго по протоколу http (порт 80), и, если вы не успели настроить свой keenetic слушать только 443 порт или готовы временно его открыть, то такой вариант более чем подходит.

Примечание.
По умолчанию админка keenetic висит на 80 и 443 порту, отдельными командами это можно перенастроить, чтобы ваш порт 0.0.0.0:443 был задействован под сайт. А админку оставить слушать 80 порт внутренней сети.

Потребуется всего несколько команд:

uacme -v -c /opt/etc/ssl/uacme new

Пoдготовливает окружение и генерирует приватный ключ. А команда

uacme -v -c /opt/etc/ssl/uacme issue www.your.domain.com

запускает процедуру выдачи сертифката, где -c /opt/etc/ssl/uacme каталог, в котором будут размещаться все сертификаты. Не забудьте поменять www.your.domain.com на ваш домен в строке выше.

В процессе работы команды вы столкнетесь примерно с таким выводом и ожиданием:

uacme: challenge=http-01 ident=www.your.domain.com token=kZjqYgAss_sl4XXDfFq-jeQV1_lqsE76v2BoCGegFk4
key_auth=kZjqYgAss_sl4XXDfFq-jeQV1_lqsE76v2BoCGegFk4.2evcXalKLhAybRuxxE-HkSUihdzQ7ZDAKA9EZYrTXwU

Что означает, что вам необходимо открыть рядом вторую консоль и создать в каталоге .well-known/acme-challenge/ файл с именем token и внутрь положить строку key_auth. Путь .well-known/acme-challenge/ создается относительно root директории сайта. Для nginx это параметр root в location /. В моем случае этот раздел в nginx.conf выглядит так:

location / {
            root   /opt/share/nginx/html;
            index  index.html;
        }

А значит перейдем в корень, создадим каталог (если он еще не создан), и в нем нужный файл.

cd /opt/share/nginx/html
mkdir -p .well-known/acme-challenge/
cd .well-known/acme-challenge/
echo "kZjqYgAss_sl4XXDfFq-jeQV1_lqsE76v2BoCGegFk4.2evcXalKLhAybRuxxE-HkSUihdzQ7ZDAKA9EZYrTXwU" >  kZjqYgAss_sl4XXDfFq-jeQV1_lqsE76v2BoCGegFk4

После этого вернемся в первую консоль и подтвердим готовность к проверке (y). Если все сделано верно, сетевой доступ по 80 порту вашим провайдером по умолчанию не закрыт, и роутер сконфигурирован верно, то в каталоге /opt/etc/ssl/uacme будут созданы сертификат и приватный ключ к нему.

/opt/etc/ssl/uacme/www.your.domain.com/cert.pem
/opt/etc/ssl/uacme/private/www.your.domain.com/key.pem

Эти файлы можно уже прописать в nginx.conf и выполнить релоад (или рестарт) сервиса

    ssl_certificate         /opt/etc/ssl/uacme/www.your.domain.com/cert.pem;
    ssl_certificate_key     /opt/etc/ssl/uacme/private/www.your.domain.com/key.pem;

Проверка по https

Если с 80 портом по тем или иным причинам у вас есть сложности, как в моем случае, то можно использовать челендж tls-alpn-01 с ssl на борту. Для этого понадобится второй установленный пакет uacme-ualpn.

Проверим куда был установлен пакет

# opkg files uacme-ualpn
Package uacme-ualpn (1.7.4-1) is installed on root and has the following files:
/opt/share/uacme/ualpn.sh
/opt/sbin/ualpn

Технически, пакет позволяет произвести получение сертифката (и его дальнейшее обновление) без прерывания работы вашего сайта. Для этого перенастраивается nginx на прослушивание порта на локальном интерфейсе, с помощью демона ualpn поднимается небольшой веб-сервер, который слушает 443 порт, проксирует запросы к вашему nginx, а сам в момент челенджа отдает нужную информацию Let’s encrypt. Такой вариант показался для меня излишне громоздким, поэтому я выбрал более простой, с остановкой nginx, получением сертификата и возобновлением работы. Сама процедура занимает несколько секунд, и если такой даунтайм вас устраивает, то можете поступить также.\

Набор команд с комментариями:

/opt/etc/init.d/S80nginx stop # Остановить nginx
ualpn -v -d -u nobody:nobody -c 127.0.0.1@4443 -S 666 # Запустить демона и перенаправить трафик на несуществующий 4443 порт
uacme -v -c /opt/etc/ssl/uacme -h /opt/share/uacme/ualpn.sh issue www.your.domain.com # Запустить процесс выдачи
ualpn -t # Остановить демона
/opt/etc/init.d/S80nginx start # Запустить nginx

Примечание.
ualpn не работает без ключа -с, поэтому что-то написать в него надо.

Процедура uacme -v -c /opt/etc/ssl/uacme -h /opt/share/uacme/ualpn.sh issue проходит автоматически, подкладывать какие-либо файлы вручную уже не требуется. С точки зрения автоматизации этот вариант даже проще. Аргумент для ключа -h мы нашли в выводе opkg files uacme-ualpn.\

Итоговый результат тот же - в каталоге /opt/etc/ssl/uacme будут созданы сертификат и приватный ключ к нему.

Полезные ссылки

Официальные репо использованных пакетов с документацией:

• http-01 - https://github.com/ndilieto/uacme?tab=readme-ov-file#uacme
• tls-alpn-01 - https://github.com/ndilieto/uacme?tab=readme-ov-file#tls-alpn-01-challenge-support

Теория:

• Виды проверок Let’s encrypt - https://letsencrypt.org/ru/docs/challenge-types/