Certbot: Как включить ACMEv2 и получение подстановочных сертификатов?

Вы должны использовать вызов DNS-01 . Это означает, что у вас должен быть способ изменять, публиковать и обновлять зону DNS прямо на вашем сервере.

Подскажите, пожалуйста, флаг для этого?

Это не просто флаг, это все доступно в документе. Это некоторые плагины для нескольких DNS-провайдеров, перечисленных там, если ваш нет, вы можете открыть здесь запрос функции, чтобы попросить поддержку для него (например, некоторые уже открыты для таких вещей, как Gandi, поэтому обязательно используйте поиск, прежде чем открывать новый).

Хм, нет, на самом деле вам нужно certbot >= 0.22 , извините за то, что пропустил это в своем первом посте.

ОК .... Как мне это установить? Я должен компилировать из исходников?

Вы можете либо дождаться его публикации в PPA , либо установить через pip или что-то подобное, либо собрать его из исходников.

На вашем месте я бы лучше дождался обновления официального пакета. Это даст вам некоторое время, чтобы взглянуть на правильную настройку задачи DNS, которую вы уже можете попробовать без подстановочного знака, просто чтобы убедиться, что все работает, а затем, когда обновление будет доступно (что не займет много времени), вы будете готовы к получить сертификат подстановочного знака.

Да, вы можете использовать certbot из исходников

root<strong i="6">@cs12</strong>:~# git clone https://github.com/certbot/certbot
...
root<strong i="7">@cs12</strong>:~# DOMAIN=example.com
root<strong i="8">@cs12</strong>:~# cd certbot 
root<strong i="9">@cs12</strong>:~/certbot# ./certbot-auto certonly --manual -d *.$DOMAIN -d $DOMAIN --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory
...
-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.example.com with the following value:

qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

Добавьте запись TXT нажмите Enter. Вы получите еще одну запись. Добавьте и это.

Затем проверьте во втором окне терминала, были ли развернуты записи:

root<strong i="15">@cs12</strong>:~# host -t txt _acme-challenge.example.com
_acme-challenge.example.com descriptive text "qqiR_lsa2AjMfoVR16mH4UDbOxy_E02l0K1CNyz1RdI"
_acme-challenge.example.com descriptive text "oMmMa-fDLlebdUhvhMD5MinJ2EeFpdP0F9lUPTShh4w"

Если все в порядке, вернитесь и нажмите Enter.

Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2018-06-11. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Обновление: ознакомьтесь с полным руководством по Gist с инструкциями по установке, настройке и обновлению сертификатов.

Спасибо за столь подробный ответ @ArchangeGabriel! Мы работаем над обновлением наших пакетов для Ubuntu, надеюсь, они скоро выйдут.

@ohemorange Добро пожаловать! Честно говоря, я опасался, что мы увидим наплыв людей, пытающихся получить сертификаты с подстановочными знаками, не имея представления о том, в чем заключается проблема DNS-01, но, видимо, этого не произошло (по крайней мере, пока).

Хороший @talyguryn , в продолжение @talyguryn

При создании одного сертификата на вершине с подстановочным знаком вы получите __two__ задачи ..

Используя -d "example.com, *.example.com" _дайте мне сертификат на вершине и подстановочный знак на вершине_

Вам будет брошен вызов _twice_, один раз за example.com и еще раз за *.example.com

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

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

документы: https://sinkcup.github.io/letsencrypt-wildcard-certificate

@AubreyHewes , у меня такая же проблема. Я не уверен, как выдать единый сертификат как для example.com и для *.example.com . К сожалению, certbot требует, чтобы я дважды изменил запись TXT. Это приводит к сбою проверки для одного из доменов. Это можно обойти?

@ nathan-alden Вам нужно установить обе записи TXT одновременно. Не удаляйте первый при добавлении второго.

@ nathan-alden
У вас есть две проблемы ... Этот _ кажется_ как будто certbot хочет, чтобы вы снова изменили тот же TXT. Но второе значение предназначено для второго домена, поэтому добавьте новую запись TXT для второго домена.

т.е.
При использовании -d "example.com,*.example.com" первая задача - example.com поэтому добавьте для этого TXT. Продолжить после размножения.
Вторая задача - *.example.com поэтому добавьте для этого TXT. Продолжить после размножения.

У меня был хороший опыт использования докер-версии. В качестве примечания: не забудьте установить TTL для записи TXT примерно на 1 минуту, чтобы вам не приходилось ждать час для распространения второй записи.

docker run -it --name certbot \
  -v <certs>:/etc/letsencrypt \
  -v <logs>:/var/lib/letsencrypt \
  certbot/certbot certonly --manual \ 
  -d *.<domain.com> -d <domain.com> \
  --agree-tos \
  --manual-public-ip-logging-ok \ 
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory

Интересный. Зачем нам нужны dns-01 . Разве вы не можете просто создать сервер на порту 80 (любая форма вызова http ) и проверить, что я владею доменом с подстановочными знаками, создав N случайных поддоменов и подключившись?

@AubreyHewes , я обнаружил, что вам нужен только один запрос / запись в DNS - просто нужно угадать правильный.

У меня есть один сертификат для четырех доменов и их подстановочных знаков. У каждого домена есть только один вызов TXT _acme. Это довольно непоследовательно, поскольку три домена работают с первым вызовом в выводе certbot, и значения кажутся одинаковыми каждый раз, когда я его запускаю.

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

Я использую эту команду:

/usr/bin/certbot --renew-by-default certonly --manual --server https://acme-v02.api.letsencrypt.org/directory --preferred-challenges dns-01 -w /usr/share/nginx/letsencrypt-root/ -d *.domain1.sk -d domain1.sk -d *.domain2.sk -d domain2.sk -d *.domain3.sk -d domain3.sk -d *.domain4.sk -d domain4.sk

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

@robertvalik Невозможно использовать одно и то же значение TXT record для двух разных проверок, включая example.com и *.example.com .

Let's Encrypt позволяет повторно использовать авторизацию в течение некоторого времени, в настоящее время 30 дней. Если ваша учетная запись что-то проверила недавно, она может выдавать больше сертификатов без повторной проверки. Однако из-за ограничений Certbot (# 5342) Certbot просит вас снова установить ту же запись TXT , даже если она больше не будет проверяться.

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

@ francoism90 Домен с подстановочными знаками может понадобиться по нескольким причинам: один может обслуживать несколько статических поддоменов, другой - обслуживать потенциально бесконечные поддомены (например, программное обеспечение как услуга). В последнем случае (в моем случае) в файле DNS уже есть подстановочный знак, и на самом деле любой случайный поддомен должен правильно разрешиться. Мне интересно, можно ли для этого сценария предоставить форму запроса http. Спасибо за ваш тяжелый труд!

Мне удалось сгенерировать сертификат, выполнив

./certbot-auto certonly --manual -d *.example.com -d example.com --agree-tos --manual-public-ip-logging-ok --preferred-challenges dns-01 --server https://acme-v02.api.letsencrypt.org/directory

Теперь мне просто интересно, как мне обновить сертификаты

<> certbot renew
<> certbot-renew
<> certbot-auto renew

Я запутался, я попробовал ./certbot-auto renew так как использовал ту же команду при запросе, но я просто хочу убедиться, что это правильный способ.

Можем ли мы автоматизировать подстановочную сертификацию?

@ ufo911 Конечно. Например, используя плагин Certbot RFC 2136 :

certbot certonly \
  --dns-rfc2136 \
  --dns-rfc2136-credentials ~/.secrets/certbot/rfc2136.ini \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

Или обработчик ручной аутентификации acme-dns :

certbot certonly \
  --debug-challenges \
  --manual \
  --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d example.com \
  -d "*.example.com"

https://certbot.eff.org/docs/using.html
https://community.letsencrypt.org/t/getting-wildcard-certificates-with-certbot/56285

Если вам нужна помощь, вы можете разместить тему на форуме Let's Encrypt .

@mnordhoff
Обязательно ли, чтобы запись DNS TXT оставалась активной при каждом обновлении?

@ ufo911 Конечно, продление - это просто запрос сертификата с повторным использованием предыдущих параметров.

@ArchangeGabriel Stange, он говорит мне, что он говорит мне установить новые TXT-записи:

#!/bin/bash
certbot certonly \
  --manual \
  --agree-tos \
  --manual-public-ip-logging-ok \
  --preferred-challenges dns-01 \
  --server https://acme-v02.api.letsencrypt.org/directory \
  -d domain.tld \
  -d "*.domain.tld"

Это нормально? Почему генерируются новые токены?

Извините, если я не понял, да, для каждого запроса есть новая запись TXT. Потому что это проверка типа "вызов-ответ", и повторное использование вызова было бы очень плохой идеей.

Фактически вы можете удалить запись TXT, как только получите сертификат, но есть новая запись TXT, которую нужно публиковать (и удалять после успешного завершения) каждый раз, когда вы продлеваете.

@ArchangeGabriel Хм, не думаю, что это вариант для меня. Создание новых записей TXT может занять 24 часа, а если что-то пойдет не так, у вас будет много времени простоя.

Вместо этого я воспользуюсь общим способом. :)

Конечно, проблема с DNS - не самая простая. Но для подстановочного знака другой возможности нет, по крайней мере, в настоящее время. Я не знаю, можно ли это заменить, например, отправкой запроса на случайное имя поддомена в пространстве подстановочных знаков (например, если вы попросите *.domain.com , он попытается прочитать ответ на запрос в somerandomstring.domain.com чтобы убедиться, что вы действительно контролируете все пространство *.domain.com ). Таким образом, перенаправления подстановочного знака в DNS будет достаточно.

@ArchangeGabriel Это был бы хороший вариант, но нужна ли в этом случае проверка DNS? Предлагает ли он что-то необходимое для безопасной настройки подстановочных знаков?

Нет, я бы предложил альтернативу DNS-вызову.

Для настройки подстановочного знака вам необходимо подтвердить контроль над всеми поддоменами. Единственный очевидный способ сделать это - подтвердить техническое владение соответствующей зоной DNS.

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

Например, мне интересно, возможен ли этот случай:
- somespecificsub.domain.com указывает на данный IP-адрес;
- * .domain.com и domain.com указывают на другой IP-адрес.

В этом случае вы можете отвечать на запросы для основного домена и любого поддомена, кроме somespecificsub.domain.com. И я думаю, что было бы неправильно давать вам сертификат * .domain.com. Так что, если это возможно, нам потребуются дополнительные настройки. Как постоянная запись TXT, говорящая о том, что ей разрешено выполнять случайную проверку поддомена для ответа на запрос с подстановочными знаками. Таким образом, конфигурация DNS будет простой, и вам будет проще проверять подстановочный знак.

В любом случае, я не знаю, с кем это следует обсуждать, и в какой момент они рассмотрели эту настройку, а также каковы точные необходимые критерии для безопасной доставки подстановочного знака. Думаю, мне следует просто прочитать RFC для этого, но у меня нет на это времени.