В связи с возросшей важностью поддержки современными сайтами протокола https использование LetsEncrypt становится практически обязательным. Я для данных целей всегда пользовался стандартным рекомендованным скриптом — certbot-ом, который вполне исправно работал (и работает). Но вот недавно открыл для себя альтернативный клиент acme.sh и остался им крайне доволен о чём и хочу поведать.

Итак собственно мотивом побудившим меня вообще взглянуть в сторону альтернативных клиентов стал очередной виток докеризации одного из проектов. Я давно хотел завернуть в контейнер nginx-ы на серверах проекта и единственное, что мешало это как раз проблема с certbot — не было ясности как это сделать «правильно». И вот я наконец созрел и полез изучать тему. Ну и в ходе поисков пересматривал различные варианты на hub.docker.com — впитывал так сказать опыт других людей. В одном из вариантов обнаружил жирное сообщение, что типа «к чорту всё это — я теперь использую acme.sh». Ну и перейдя по ссылке я решил попробовать этот волшебный скрипт.

Плюсы

Скрипт написан на чистом bash-е. Собственно и оригинальный certbot со своим python-ом не особо напрягал, но в принципе чем меньше зависимостей, тем мне нравится больше.

Поддерживает валидацию через DNS, причём автоматически. Для меня это просто открытие!!! Правда в ручном режиме это реальный геморрой, но скрипт поддерживает целую кучу API различных провайдеров, включая используемый мной повсеместно Yandex-овский pdd.yandex.ru. Т.е. больше не нужно заводить на вебсервере специальную папку, добавлять специальный правила или как вариант останавливать веб-сервер, чтоб certbot отработал автономно. Скрипт сам проверяет ваши права на домен добавляя специальную TXT запись в вашу зону (если есть API у вашего провайдера) и генерирует нужные сертификаты.

Поддержка docker-а «из коробки». Есть уже готовый контейнер от авторов скрипта — бери и пользуйся, что я собственно и сделал.

Минусы

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

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

Сразу оговорюсь — я пользуюсь этим скриптом через докер контейнер — хотя при запуске отличия минимальны. Второй момент — я использую DNS от Яндекса. Соответственно примеры будут именно в этом контексте.

Ключ для API DNS Яндекса

Создать ключ можно по этой ссылке — https://pddimp.yandex.ru/api2/admin/get_token
Там надо просто ввести свой домен и капчу и сервис выдаст вам токен. Проще не придумаешь.

Для использования ключа его нужно поместить в переменную окружения PDD_Token. Просто для скрипта это очевидно export PDD_Token=<ваш токен>, а для докера передаём в контейнер с ключом e — как-то так docker run -e PDD_Token=<ваш токен> --rm neilpang/acme.sh

Запуск

$ docker run -v /etc/acme:/acme.sh -e PDD_Token=<токен> --rm neilpang/acme.sh \
  --issue -d webhive.ru \
  --dns dns_yandex \
  --accountemail "roman.tataurov@yandex.ru" \
  --standalone
[Wed May 16 21:22:24 UTC 2018] Registering account
[Wed May 16 21:22:26 UTC 2018] Registered
[Wed May 16 21:22:26 UTC 2018] ACCOUNT_THUMBPRINT='........................'
[Wed May 16 21:22:26 UTC 2018] Creating domain key
[Wed May 16 21:22:26 UTC 2018] The domain key is here: /acme.sh/webhive.ru/webhive.ru.key
[Wed May 16 21:22:26 UTC 2018] Single domain='webhive.ru'
[Wed May 16 21:22:26 UTC 2018] Getting domain auth token for each domain
[Wed May 16 21:22:26 UTC 2018] Getting webroot for domain='webhive.ru'
[Wed May 16 21:22:26 UTC 2018] Getting new-authz for domain='webhive.ru'
[Wed May 16 21:22:27 UTC 2018] The new-authz request is ok.
[Wed May 16 21:22:27 UTC 2018] Found domain api file: /root/.acme.sh/dnsapi/dns_yandex.sh
[Wed May 16 21:22:27 UTC 2018] Sleep 120 seconds for the txt records to take effect
[Wed May 16 21:24:27 UTC 2018] Verifying:webhive.ru
[Wed May 16 21:24:30 UTC 2018] Success
[Wed May 16 21:24:30 UTC 2018] Removing DNS records.
[Wed May 16 21:24:32 UTC 2018] Verify finished, start to sign.
[Wed May 16 21:24:33 UTC 2018] Cert success.
-----BEGIN CERTIFICATE-----
 ... skip ...
-----END CERTIFICATE-----
[Wed May 16 21:24:33 UTC 2018] Your cert is in  /acme.sh/webhive.ru/webhive.ru.cer
[Wed May 16 21:24:33 UTC 2018] Your cert key is in  /acme.sh/webhive.ru/webhive.ru.key
[Wed May 16 21:24:33 UTC 2018] The intermediate CA cert is in  /acme.sh/webhive.ru/ca.cer
[Wed May 16 21:24:33 UTC 2018] And the full chain certs is there:  /acme.sh/webhive.ru/fullchain.cer

Сохраняться всё будет в /etc/acme т. к. именно эту папку я указал докеру для маппинга docker run -v /etc/acme:/acme.sh

Как видно из вывода скрипт добавил проверочную запись в зону, подождал 120 секунд — прочитал запись из DNS и таким образом убедился, что домен принадлежит вам.

В принципе если у вашего провайдера DNS нет API, то можно добавлять проверочную запись вручную, но это придётся делать при каждом обновлении ключей (примерно раз в 2 месяца). Поэтому если нет возможности использовать API, то этот способ вам не подойдёт.

Если же API для вашего провайдера просто не поддерживается (пока) скриптом, то можно просто написать его самому — там надо-то реализовать 2 функции на bash. Если вы не в силах такого сделать, то странно, что вы вообще читаете эту статью.

Ну собственно с запуском всё — скрипт генерирует ключи — ну, а как их использовать уже выходит за рамки статьи.

Какие ещё плюшки есть у скрипта?

Оно умеет добавлять себя в cron для автоматического обновления сертификатов по таймеру.

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

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

Импорт существующих данных

Такой возможности нет. Как пишет сам автор — «нафига это нужно — просто сгенерируйте новый сертификат и всё, а старый выбросьте». И в сущности он прав — этот тот случай когда нет смысл городить что-то там где оно не нужно.

Итого

Имеем отличнейшую альтернативу стандартному certbot-у с кучей полезных функций.