Используете ли вы DNS-авторизацию certbot с несколькими учетными записями API?

Используете ли вы DNS-авторизацию certbot с несколькими учетными записями API?

Я использую клиент EFF certbot ACME для генерации одного сертификата TLS на моем веб-сервере, на котором размещено несколько доменов с использованием альтернативных имен субъектов (SAN). До сих пор все домены размещались в определенной команде Digital Ocean, и у меня есть настроенный certbot с плагином Digital Ocean DNS и персональным токеном доступа, созданным для этой команды, для генерации сертификата с несколькими доменами (включая подстановочные домены).

Теперь клиент хочет, чтобы я также обслуживал домен, над которым он хочет сохранить полный контроль, поэтому мы создали новую команду Digital Ocean, и моей учетной записи, где был создан токен доступа DO, был предоставлен доступ. К сожалению, я также обнаружил, что токен доступа создается для команды и не может использоваться с другой командой.

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

Если нет, какие другие альтернативы вы могли бы предложить для реализации этого варианта использования?

решение1

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

Я написал ручной скрипт-перехватчик, который поддерживает проверку доменов в нескольких командах/пользователях Digital Ocean, предполагая, что у вас есть персональный токен доступа для каждого.Скрипт доступен здесь: https://gist.github.com/guss77/01f095623a1d2fd00869784554d3e1a5.

Чтобы использовать его, убедитесь, что у вас doctlгде-то установлен инструмент командной строки Digital Ocean (и настройте его в скрипте), а также настройте в скрипте ваши персональные токены доступа (скрипту также нужны digнесколько распространенных инструментов оболочки POSIX, которые, как я ожидаю, можно найти везде, хотя они могут не работать должным образом за пределами Linux).

Тогда вместо использования одного из --dns*плагинов используйте:

--preferred-challenges=dns --manual \
--manual-auth-hook /path/to/certbot-hook.sh \
--manual-cleanup-hook /path/to/certbot-hook.sh

При попытке аутентификации certbot вызовет этот скрипт для создания записей DNS для каждого проверяемого домена. Для этого скрипт будет использовать инструмент doctlпосле сканирования списка доступных доменов с использованием каждого персонального токена доступа и выбора правильной «зоны», в которой следует создать запись.

Однако у меня иногда возникают проблемы с этим подходом, особенно со временем распространения DNS — certbot поддерживает настраиваемые тайм-ауты ожидания распространения DNS для плагинов DNS, но не для ручного режима, и нет хорошего способа имитировать это иным образом.

решение2

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

В соответствии сcertbot-dns-digitaloceanдокументация плагинаучетные данные указаны в INI-файле:

--dns-digitalocean-credentials INI-файл учетных данных DigitalOcean. (Обязательно)

С ini-файлом, содержащим что-то вроде:

dns_digitalocean_token = 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff

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

То есть, что-то вроде

certbot certonly \
  --dns-digitalocean \
  --dns-digitalocean-credentials ~/.secrets/certbot/digitalocean-foo.ini \
  -d domain1.example

и

certbot certonly \
  --dns-digitalocean \
  --dns-digitalocean-credentials ~/.secrets/certbot/digitalocean-bar.ini \
  -d domain2.example

будут использоваться учетные данные из двух отдельных файлов.

Связанный контент