Я надеюсь использовать Let's Encrypt для нескольких доменов и поддоменов и моей компании. Вместо покупки долгосрочного wild card сертификата, который устанавливается на каждой машине, цель состоит в том, чтобы использовать краткосрочные и конкретные сертификаты. Это необходимо для предотвращения нашей уязвимости, если одна машина будет скомпрометирована.
К сожалению, некоторые серверы не могут иметь прерывания обслуживания (т. е. не имеют возможности HTTP acme challenge). Поэтому последний вариант — DNS challenge. Для этого требуется API-токен для нашего DNS-провайдера, в данном случае Cloudflare.
Однако, если я размещу Global API Token на машине и она будет скомпрометирована, это даст злоумышленнику полный доступ к нашему DNS для всего домена. Это именно то, что я хочу смягчить, не используя wildcard cert.
Cloudflare позволяет вам создавать менее привилегированные токены, однако они не становятся более гранулярными, чем для домена корневого уровня. Опять же, по сути, тот же доступ/проблема, что и wildcard cert.
Кто-нибудь нашел решение этой проблемы?
решение1
Подход, который я использовал в прошлом для этого требования, и который яполагатьодобрено документацией Let's Encrypt, заключается в CNAME-присвоении имени _acme-challengeподдомену для имен, которые вы хотите проверить по именам в одной или нескольких других зонах, которые имеют другие конфигурации контроля доступа.
Например, если вы хотите разрешить какой-либо службе генерировать сертификаты только для bobservice.example.com, вы можете создать отдельную зону для другого домена, скажем bobservice.example, а затем CNAME _acme-challenge.bobservice.comдля _acme-challenge.bobservice.example. Затем токен вызова помещается в запись TXT на _acme-challenge.bobservice.example, LE следует за CNAME, и имя проверяется.
Конечно, другой вариант — полностью отказаться от использования Cloudflare, поскольку в их сервисе отсутствуют полезные функции, такие как ограниченная область действия учетных данных, а также есть крошечная проблема в том, что они предоставляют услуги отбросам Интернета.
решение2
К сожалению, некоторые серверы не могут иметь прерывания обслуживания (т.е. не имеют возможности HTTP acme challenge). Поэтому последний вариант — DNS challenge.
Есть еще один вариант для вашего сценария,плагин webroot. Это позволяет вам указать клиенту Let's Encrypt путь к корневому каталогу вашего сервера, и он разместит файлы HTTP-запросов там. Этот подход вообще не портит работу вашего веб-сервера и не приводит к простоям.
решение3
Мое решение — создать службу, которая живет во внутренней сети, довольно закрыта и хранит глобальный ключ API. Эта служба будет использовать этот ключ для создания/обновления сертификатов для различных поддоменов. Серверы, которые полагаются на сертификаты поддоменов, будут иметь токен для каждого домена, который они могут выпустить для этой внутренней службы, чтобы получить новый или обновленный сертификат.