Lua-resty-auto-ssl: Подстановочные сертификаты

Я не сопровождаю репозиторий, но должен сказать, что это не так просто добавить. Подстановочные сертификаты LE потребуют проверки DNS, и прямо сейчас lua-resty-auto-ssl использует проверку http.

Было бы неплохо иметь проверку DNS, даже без учета подстановочных знаков. Несколько мыслей:

• нам нужно дождаться обезвоживания, чтобы сначала получить поддержку ACMEv2: обезвоженный # 420
• dehydrated уже поддерживает вызов (ACMEv1) dns-01 . Задача dns-01 в текущем черновике ACMEv2 мне кажется идентичной или почти идентичной.
• крючок deploy_challenge dehydrated предоставляет домен и токен для записи в запись TXT.
• поскольку мы не знаем, как пользователи управляют своими записями DNS, эта часть должна быть общей.
  
  
  
  1. поддержка популярных DNS API. Мы должны как минимум добавить инфраструктуру для поддержки «стандартных» API, таких как PowerDNS, CloudFlare или даже nsupdate. В этом случае в наших настройках нужен только какой-то токен аутентификации.
  
  
  2. должны пользователи будут нуждаться в специальном решении, чтобы установить эти рекорды, например, общаться с проприетарным API или даже вызывать скрипты грязной оболочки. Мы должны предоставить общий хук для таких случаев:
     
     -- Define a function to store the validation tokens for DNS verification -- by let's encrypt in your DNS setup. auto_ssl:set("deploy_dns_challenge", function(domain, token) -- talk to your DNS-API to create a new TXT record _acme-challenge.$domain with value $token end)
  
  
• уровень хранения в настоящее время предполагает, что он может использовать полный домен в качестве ключа для получения сертификата. Это больше не будет соответствовать действительности. Моя первая идея состоит в том, чтобы хранить подстановочные знаки как parentdomain.com:wildcard:latest и заставить уровень хранения проверять этот ключ, если конкретный сертификат не найден.

Вопросы:

1. как узнать, генерировать ли обычный сертификат или сертификат с подстановочным знаком? новая определяемая пользователем функция is_wildcard_domain ? Новое возвращаемое значение для существующего allow_domain ?
2. Поддерживаем ли мы проверку DNS (для подстановочных знаков) и HTTP (для обычных сертификатов) одновременно или только DNS для обоих? Обратите внимание, что HTTP может быть намного быстрее, поскольку мы контролируем все движущиеся части.

К вашему сведению: теперь доступна промежуточная конечная точка ACMEv2 . :)

Задача dns-01 в текущем черновике ACMEv2 мне кажется идентичной или почти идентичной.

Вы правы :-) Ничего не изменилось в вызове DNS-01 между V1 и V2 API.

К вашему сведению: по крайней мере, разрабатываемая версия dehydrated теперь поддерживает ACMEv2, а также подстановочные сертификаты. Если кто-то хочет начать работать над этим, это ваш шанс ;)

Я думаю, что resty-auto-ssl, выполняющий проверку DNS, полностью выходит за рамки.
Тем не менее, у нас должна быть возможность заставить resty-auto-ssl откатиться на «внеполосный» настроенный подстановочный сертификат.
Например, я собираюсь настроить свой сервис с помощью bind9 и certbot для создания подстановочного сертификата для домена. Прямо сейчас я не думаю, что могу сказать resty-auto-ssl использовать этот подстановочный сертификат вместо того, чтобы пытаться его сгенерировать.

РЕДАКТИРОВАТЬ: ну, это не то, что выходит за рамки. Я не знал, что обезвоженный можно настроить с помощью ручных сценариев для подключения к пользовательскому API DNS...

Есть ли способ сохранить созданный вручную сертификат LE с подстановочными знаками в Redis, чтобы его мог использовать resty-auto-ssl?

Насколько я понял из кода, это невозможно. Мы могли бы легко добавить следующие проверки в интерфейс хранилища для каждого sub.domain.tld :

• sub.domain.tld:latest — текущий
• *.domain.tld:latest
• *.sub.domain.tld:latest

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

Изменить: я был бы рад поцарапать реализацию вышеизложенного.

@akalipetis вы пытались увидеть, если установка

ssl_options.fullchain_der
ssl_options.privkey_der

будет работать в allow_domain ?
Если это возможно, вы можете сделать запрос redis в allow_domain и установить их.

Для справки, я только что столкнулся с этой проблемой, я использую lua-resty-auto-ssl для создания сертификатов для пользовательских страниц состояния домена в моей службе мониторинга, и большинство людей будут использовать мои собственные домены, такие как xxxx.status.updown.io , для которых это намного эффективнее. использовать подстановочный сертификат.

Я достиг этого, используя лямбду allow_domain , чтобы пропустить генерацию сертификата для *status.updown.io :

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

А затем предоставил подстановочный знак в качестве резервного сертификата по умолчанию:

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

Я сгенерировал сертификат вручную, используя вызов DNS с помощью:

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

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

Это хороший обходной путь, который применим ко многим случаям использования.
Однако имейте в виду, что вызов DNS стал очень простым благодаря https://github.com/AnalogJ/lexicon !
Он хорошо работает и поддерживает множество провайдеров. Я даже добавил один из них, и процесс до смешного прост.

@kapouer спасибо за совет о lexicon , буду иметь в виду, если захочу автоматизировать;)

Для справки, я только что столкнулся с этой проблемой, я использую lua-resty-auto-ssl для создания сертификатов для пользовательских страниц состояния домена в моей службе мониторинга, и большинство людей будут использовать мои собственные домены, такие как xxxx.status.updown.io , для которых это намного эффективнее. использовать подстановочный сертификат.

Я достиг этого, используя лямбду allow_domain , чтобы пропустить генерацию сертификата для *status.updown.io :

auto_ssl:set("allow_domain", function(domain)
  return not ngx.re.match(domain, "status.updown.io$", "ijo")
end)

А затем предоставил подстановочный знак в качестве резервного сертификата по умолчанию:

ssl_certificate /etc/letsencrypt/live/status.updown.io/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.updown.io/privkey.pem;

Я сгенерировал сертификат вручную, используя вызов DNS с помощью:

sudo certbot certonly --manual -d *.status.updown.io --agree-tos --no-bootstrap --manual-public-ip-logging-ok

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

Я также выполняю такую ​​же проверку домена для нашего приложения. Если хост портала пользователя содержит один из наших «собственных» доменов, мы просто возвращаемся к использованию сертификатов с подстановочными знаками из статического ЦС. Но мне нравится ваша идея по-прежнему использовать LE и генерировать подстановочные знаки вручную.

Я собираюсь проверить это.

Обновлять
Хорошо, это решение, которое действительно делает то, что я хочу. Плагин CloudFlare. Документы довольно хорошие. У меня заработало за час-два.

https://certbot-dns-cloudflare.readthedocs.io/en/stable/

@jarthod есть ли другой обходной путь для автоматизации этого? На самом деле не забывать обновлять подстановочный знак каждые 3 месяца.

@jarthod есть ли другой обходной путь для автоматизации этого? На самом деле не забывать обновлять подстановочный знак каждые 3 месяца.

Не на моей стороне, я все еще использую это и обновляю руководство каждые 3 месяца. Запоминание не является проблемой для меня, поскольку я использую свой сервис (updown.io) для мониторинга конечной точки, и он предупреждает меня, когда срок действия сертификата истекает.

Я тоже пользователь вашего сервиса. В любом случае, я пошел дальше и получил традиционный SSL-сертификат с подстановочным знаком на 1 год.

Теперь у вашего сервиса есть работа, чтобы напомнить мне в следующем году 😄

03 октября 2020 г., в 22:30, Адриан Рей-Джартон, [email protected] , написал:

В
@jarthod есть ли другой обходной путь для автоматизации этого? На самом деле не забывать обновлять подстановочный знак каждые 3 месяца.

Не на моей стороне, я все еще использую это и обновляю руководство каждые 3 месяца. Запоминание не является проблемой для меня, поскольку я использую свой сервис (updown.io) для мониторинга конечной точки, и он предупреждает меня, когда срок действия сертификата истекает.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отмените подписку.