Let's Encrypt расширяет бету: переводим клиентские домены на бесплатные сертификаты

В сентябре мы впервые попали в закрытую бету Let's Encrypt и потрогали certbot на своих хостах. В декабре завернули это в Ansible-роль и раскатали на managed-хосты. Казалось бы - отчитались, закрыли тему. Но Let's Encrypt продолжает расширять бету, приглашения приходят новым доменам, и в январе мы получили ещё одно - уже под клиентский проект.

Это другая история. Свои хосты - это эксперимент с понятными рисками. Клиентский домен - это уже ответственность, и подход другой.

Контекст: что изменилось с сентября

Let's Encrypt с осени 2015-го работает стабильнее. ACME-протокол не менялся кардинально, certbot (который до декабря звался letsencrypt-auto) оброс нормальной документацией и начал выходить релизами с changelog-ом вместо «коммит в master». Это важно: когда инструмент меняется тихо и без версий, ты никогда не знаешь, что именно сломалось после обновления.

Команда Let's Encrypt говорит о переходе в публичный доступ в первом полугодии 2016-го. Пока - только закрытая бета с приглашениями для конкретных доменов. Инвайт приходит на email, указанный при регистрации, и действует на один или несколько доменов - не на весь аккаунт.

Что за проект

Managed-сопровождение клиента с несколькими публичными доменами - корпоративный сайт плюс пара поддоменов для API и документации. До этого момента - платный сертификат от коммерческого CA, Comodo, продление раз в год, ручной процесс. Клиент платил несколько тысяч рублей в год и не считал это проблемой - пока мы не объяснили, что автоматизация за ноль рублей уже работает и уже прошла обкатку.

Согласовали с клиентом тестирование на тех самых доменах. Получили инвайт, зарегистрировали заявку через letsencrypt.org - письмо пришло через несколько дней.

Выпуск сертификатов

Схема та же что и раньше: certonly --webroot, nginx слушает на 80-м и отдаёт .well-known/acme-challenge/ из специальной директории. Никакого standalone-режима, никакого останова nginx - просто файл в нужном месте.

certbot certonly --webroot \
  -w /var/www/letsencrypt-challenge \
  -d example-client.ru \
  -d www.example-client.ru \
  -d api.example-client.ru \
  --email ops@adg.ru \
  --agree-tos \
  --non-interactive

Три домена, один запуск, одно письмо от Let's Encrypt с подтверждением. Сертификаты легли в /etc/letsencrypt/live/example-client.ru/. Nginx получил новые пути, получил reload - проверили через браузер и openssl s_client.

ssllabs.com дал A. Платный Comodo на этом же хосте раньше давал B из-за несвежей конфигурации SSL. Let's Encrypt тут ни при чём - просто заодно привели конфиг в порядок.

Автопролонгация

Добавили в cron на хосте:

0 4 * * 3 certbot renew --quiet && systemctl reload nginx

Среда, 4 утра. --quiet - молчит если всё хорошо, пишет только если что-то не так. После обновления - reload nginx. Сертификат 90-дневный, certbot обновляет когда остаётся меньше 30 дней - то есть реально будет продлевать примерно раз в два месяца.

Мониторинг на дату истечения - через Zabbix, внешняя проверка сертификата с порогом 25 дней. Это важно: cron может тихо сломаться, certbot может не обновить по какой-то причине (rate limit Let's Encrypt, проблема с DNS), а сайт продолжит работать ещё 30 дней, пока не упадёт. Алерт за 25 дней даёт время разобраться без паники.

Что пока осторожно

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

Rate limits. Let's Encrypt ограничивает количество сертификатов на домен - 5 штук в 7 дней. Для нормального использования этого хватает с запасом, но если что-то пошло не так и нужно перевыпускать несколько раз - упрёшься в лимит. На продакшн-доменах это неприятно.

Зависимость от внешней инфраструктуры. Certbot ходит в сеть и разговаривает с серверами Let's Encrypt при каждом обновлении. Платный сертификат после выпуска - самодостаточный файл, живёт год без внешних зависимостей. Здесь - нужен доступ к CA при каждом продлении. Если CA лежит в момент когда cron попытался обновить - сертификат не обновится. 30-дневный буфер должен перекрыть любые временные проблемы на стороне Let's Encrypt, но это надо держать в голове.

Closed beta - это ещё не GA. Инфраструктура расширяется, команда работает, но статус «бета» означает что гарантий по SLA пока нет. Для клиентских доменов это риск, который нужно называть прямо и получать явное согласие.

Клиент согласился. Запустили. Следим.

Что по итогу

Сертификаты выпущены, cron настроен, мониторинг добавлен. Платный сертификат будет отзван по истечении - переплачивать за год вперёд смысла нет. Экономия клиента - несколько тысяч рублей в год, выгода для нас - один ручной процесс меньше в обслуживании.

Если Let's Encrypt выйдет в публичный доступ в этом году без серьёзных инцидентов в бете, следующий разговор с клиентами о «давайте продлим Comodo» будет коротким.