Certbot: автономный должен разрешать привязку к альтернативным портам (но не аутентификацию)

Я считаю, что клиент уже имеет нужные вам функции, однако он представлен не очень удобным для пользователя способом, поскольку в основном использовался для тестирования. Клиент имеет следующие флаги:

  --tls-sni-01-port TLS_SNI_01_PORT
                        Port number to perform tls-sni-01 challenge. Boulder
                        in testing mode defaults to 5001. (default: 443)
  --http-01-port HTTP01_PORT
                        Port used in the SimpleHttp challenge. (default: 80)

Эти флаги позволяют указать, для каких портов клиент устанавливает задачи проверки домена. Как правило, --tls-sni-01 должен быть портом, на который вы направляете входящий трафик порта 443, а --http-01-port должен быть портом, на который вы направляете входящий трафик порта 80.

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

  --standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
                        Supported challenges. Preferred in the order they are
                        listed. (default: tls-sni-01,http-01)

Надеюсь, это поможет!

Спасибо, я попробую это завтра.

Если это работает, это действительно должно использоваться в качестве примера. Гораздо проще перезапустить сервер, чтобы включить/отключить передачу прокси через эти порты, чем отключать все для обработки процесса проверки.

22 марта 2016 г., в 15:16, [email protected] написал:

Я считаю, что клиент уже имеет нужные вам функции, однако он представлен не очень удобным для пользователя способом, поскольку в основном использовался для тестирования. Клиент имеет следующие флаги:

--tls-sni-01-порт TLS_SNI_01_PORT
Номер порта для выполнения вызова tls-sni-01. Боулдер
в тестовом режиме по умолчанию 5001. (по умолчанию: 443)
--http-01-порт HTTP01_PORT
Порт, используемый в вызове SimpleHttp. (по умолчанию: 80)
Эти флаги позволяют указать, для каких портов клиент устанавливает задачи проверки домена. Как правило, --tls-sni-01 должен быть портом, на который вы направляете входящий трафик порта 443, а --http-01-port должен быть портом, на который вы направляете входящий трафик порта 80.

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

--standalone-supported-challenges STANDALONE_SUPPORTED_CHALLENGES
Поддерживаемые вызовы. Желательно в порядке их следования
перечислено. (по умолчанию: tls-sni-01,http-01)
Надеюсь, это поможет!

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

@jvanasco большинство людей используют плагин webroot для этого случая использования, но да, пример прокси-пропуска nginx может быть хорошим. Не стесняйтесь делать PR, который добавляет один в документы; это достаточно специализированный вариант использования, поэтому он, вероятно, должен получить новый раздел внизу этого файла:

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst

Однако вы можете сделать ссылку на него из существующего автономного раздела:

https://github.com/letsencrypt/letsencrypt/blob/master/docs/using.rst#standalone

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

Это не работает. @БМВ

/usr/local/bin/certbot-auto certonly --http-01-port 8484 --config-dir /etc/letsencrypt --work-dir /var/lib/letsencrypt --logs-dir /var/log/letsencrypt --standalone --standalone-supported-challenges http-01 --email [email protected] --domains example.com --agree-tos --non-interactive

tcp        0      0 0.0.0.0:8484                0.0.0.0:*                   LISTEN      7270/python2

Я вижу, что аутентификация прошла через порт 80, однако сервер python2 запустился на 8484.

Nginx на порту 80

66.133.109.36 - - [25/Aug/2016:12:41:15 +0100] "GET /.well-known/acme-challenge/xxxxxxxx HTTP/1.1" 200 87 "-" "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)"

РЕДАКТИРОВАТЬ:
Я вижу, что --tls-sni-01-port 5001 --http-01-port 5002 необходимы!

Редактировать:
Я до сих пор не знаю, как заставить автономный сервер раскрутить сервер и аутентифицировать его.

Также возникают проблемы с игнорированием --tls-sni-01-port :

# certbot certonly --noninteractive --email "matt.hanley@****" --domain **** --agree-tos --tls-sni-01-port 40443 --http-01-port 4080 --standalone  
Failed authorization procedure. ****** (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested 2af2853170e5be7e86cdff79d0ca****.febd4f14bb130b15910f30587cf4****.acme.invalid from 185.***.***.***:443. Received certificate containing '*****'

Обратите внимание, что на самом деле запрос перешел к :443 ; У меня уже есть служба HTTPS, работающая на :443 и обслуживающая другой сертификат. Однако это работает с renew .

Также есть проблема с --tls-sni-01-port :

certbot certonly -n -d example.com --agree-tos --email "[email protected]" --standalone --tls-sni-01-port 8443 --http-01-port 8080

Failed to connect to 1.2.3.4:443 for TLS-SNI-01

--http-01-port / --tls-sni-01-port не позволяет вам указать, через какой порт Let's Encrypt будет подключаться к вашему серверу. Он всегда будет использовать 80/443 соответственно. Все эти флаги позволяют вам контролировать, какие порты Certbot прослушивает для плагинов, таких как автономные. Это полезно, например, если вы направляете весь трафик порта 80 на порт 8080.

Да, просто на заметку, вам в основном должен быть доступен порт 80 на общедоступном IP-адресе.

Что-то, чего очень не хватает в документации, также означает, что Let's Encrypt не подходит для меньшинства, которое не может контролировать входящий трафик на 80 (вероятно, Китай / некоторые интернет-провайдеры, корпоративные брандмауэры)

Я прочитал несколько сообщений об этом, похоже, что возможность прослушивания на 80 считается мерой повышения безопасности / доверия, потому что это привилегированный порт на ящике Nix.

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

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

Другой вариант, если вы используете только SSL, — это использовать другой веб-сервер, обслуживающий 80, чтобы он мог гарантировать загрузку сертификата до того, как nginx попытается загрузиться. (Раздражающая установка)

Мои развертывания шеф-повара теперь выполняются следующим образом:

1. Установите самоподписанный сертификат.
2. Загрузка nginx (с самостоятельным сертификатом)
3. Выполнить сертификат
4. Сертификаты Symlink на мое местоположение
5. Перезагрузить nginx

отправлено из моего Айфона

15 сентября 2016 г., в 23:18, Брэд Уоррен, [email protected] , написал:

--http-01-port/--tls-sni-01-port не позволяет вам указать, через какой порт Let's Encrypt будет подключаться к вашему серверу. Он всегда будет использовать 80/443 соответственно. Все эти флаги позволяют вам контролировать, какие порты Certbot прослушивает для плагинов, таких как автономные. Это полезно, например, если вы направляете весь трафик порта 80 на порт 8080.

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

Мой веб-сервер прослушивает только один порт для соединений SSL, и это не порт 443 по умолчанию. Это связано с тем, что веб-сервер находится за службой VPN, которая разрешает переадресацию портов, но не разрешает переадресацию портов на порт 80 или 443.

Я пытаюсь настроить Let's Encrypt на этом сервере, но в журналах я вижу, что клиент acme пытается подключиться к порту 80 (который недоступен) и терпит неудачу.

Я получаю сообщение об ошибке «Не удалось подключиться» со статусом 400.

Значение «addressesResolved» правильное, просто значение «port» равно 80 и что все URL-адреса неверны, потому что для них должен быть указан мой пользовательский порт, например, subdomain.domain. tld:1234 , где 1234 — мой собственный порт.

Есть ли способ заставить его работать с моей настройкой?

От @gsdevme у меня сложилось впечатление, что порт 80 должен быть общедоступным...

_ПОРТ 80 ДОЛЖЕН ИМЕТЬ ПУБЛИЧНО ДОСТУПНЫЙ ДЛЯ СЕРВЕРА ACME ДЛЯ ПРОВЕРКИ._

_ЭТО РЕШЕНИЕ ПРЕДНАЗНАЧЕНО ТОЛЬКО ДЛЯ ВНУТРЕННЕГО ЗАПУСКА СЕРВЕРА НА АЛЬТЕРНАТИВНОМ ПОРТУ И ПЕРЕДАЧИ ПРОКСИРОВАНИЯ С ПОРТА80 НА АЛЬТЕРНАТИВНЫЙ ПОРТ._

_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._
_ЕСЛИ У ВАС НЕТ ДОСТУПНОГО PORT80, ВЫ ДОЛЖНЫ ИСПОЛЬЗОВАТЬ ПРОВЕРКУ DNS._

Спасибо за ответ @jvanasco. Жаль, что я не могу указать пользовательские порты. Проверка DNS невозможна, поскольку у моего поставщика динамических DNS http://freedns.afraid.org/ нет интерфейса для автоматического изменения записей TXT.

@jvanasco Хотя я знаю, что вы совершенно правы в своем ответе, было бы неплохо, если бы мы все немного успокоились, прежде чем отвечать :D

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

Это не настраивается по выбору дизайна

отправлено из моего Айфона

14 февраля 2017 г., в 16:16, [email protected] написал:

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

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

Та же проблема здесь, но для целей докера.

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

• попросить сертификат
• поместите сертификат в общий том с моим веб-сервером

Но это решение будет работать, только если я остановлю контейнер своего веб-сервера, который уже привязан к портам 80 и 443.

Решение :
Иметь возможность изменять порты certbot. Это позволило бы и certbot, и контейнеру веб-сервера работать параллельно.

Использование проверки DNS может решить этот вариант использования.

отправлено из моего Айфона

26 февраля 2017 г., в 23:32, [email protected] написал:

Та же проблема здесь, но для целей докера.

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

попросить сертификат
поместите сертификат в общий том с моим веб-сервером
Но это решение будет работать, только если я остановлю контейнер своего веб-сервера, который уже привязан к портам 80 и 443.

Решение :
Иметь возможность изменять порты certbot. Это позволило бы и certbot, и контейнеру веб-сервера работать параллельно.

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

Это возможно, но этот режим проверки невозможен в автономном режиме :/
(из: https://certbot.eff.org/docs/using.html#plugins)

Похоже, что разумным компромиссом без ущерба для безопасности было бы разрешить обнаружение порта через запись DNS SRV. Letsencrypt может запросить запись, например

_letsencrypt._tcp IN SRV 0 0 8080 10.10.10.10

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

Это также означает, что пользователи могут легко централизовать управление своими сертификатами, если захотят, обратившись к центральному серверу сертификатов.

Как разрешение альтернативных портов ставит под угрозу безопасность?

Эта утилита FOSS может помочь вам автоматизировать прямую и непрямую установку сертификатов ACME на хосты, у которых порт TCP/443 занят или на них не переадресован порт TCP/443:

https://www.actiu.net/sesele/

Где документация о том, как работает SeSeLe, чтобы можно было использовать
порты отличные от 443?.

26 октября 2017 г., 13:21, «Нарсис Гарсия» [email protected] написал:

Эта утилита FOSS может помочь вам автоматизировать прямую и непрямую установку
Сертификаты ACME для хостов с занятым портом TCP/443 или без TCP/443
им переадресован порт:

https://www.actiu.net/sesele/

—
Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/certbot/certbot/issues/2697#issuecomment-339754606 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAOGHuxKLiYjM4-cME-0GBu9Ujoe0NB_ks5swM20gaJpZM4H1uae
.

Пожалуйста, обратитесь к проблеме форума SeSeLe, чтобы обеспечить лучшую координацию документации. (Ответ теперь написан в документации SeSeLe)

Может быть, стоит вернуться к этому вопросу? Решения основной проблемы до сих пор нет. Да, вы можете привязать автономный порт к другому порту, но это бесполезно, потому что athority все равно будет подключаться к 80/443.

Если у вас уже есть сервер, работающий на 80/443, возможно, в производстве, вы иногда просто не можете позволить себе освободить эти порты. Ручное размещение файлов испытаний также может быть проблематичным (серверы, работающие в Docker).

Настоящим решением здесь было бы указать набор портов выше (10 000+), куда уполномоченный попытается подключиться в качестве запасного варианта или что-то в этом роде. Возможно, есть последствия для безопасности, а не эксперт.

Какова мотивация подключения LE только к портам 80/443? Это
официально задокументированное ограничение?

Может ли кто-нибудь указать мне на правильные документы?

30 ноября 2017 г., 6:31, «cen1» [email protected] написал:

Может быть, стоит вернуться к этому вопросу? До сих пор нет решения проблемы
основная проблема. Да, вы можете привязать автономный режим к другому порту, но это
бесполезно, потому что athority все равно будет подключаться к 80/443.

Если у вас уже есть сервер, работающий на 80/443, возможно, в производстве, вы
иногда просто не может позволить себе освободить эти порты. Размещение вручную
файлы вызовов также могут быть проблематичными (серверы, работающие в Docker).

Реальным решением здесь было бы указать набор портов выше (10
000+), где власти попытаются подключиться как запасной вариант или что-то в этом роде.
как это. Возможно, есть последствия для безопасности, а не эксперт.

—
Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/certbot/certbot/issues/2697#issuecomment-348162321 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAOGHqWG9XZyTVDdAbm3t5xQ-AD6Y_OQks5s7pIDgaJpZM4H1uae
.

Какова мотивация подключения LE только к портам 80/443?
Это официально задокументированное ограничение?

Может ли кто-нибудь указать мне на правильные документы?

Это текущее требование форума CA/B, описанное здесь:
https://cabforum.org/2017/09/19/ballot-190-revised-validation-requirements/

Более подробно объясняется здесь: https://community.letsencrypt.org/t/support-for-ports-other-than-80-and-443/3419/100 .

Насколько я понимаю с моим плохим английским, на форуме CA/Browser в сентябре 2017 года обсуждалось возможное добавление портов TCP 25, 115, 22.
Похоже, что предложение было одобрено и должно вступить в силу в ноябре этого года.

Примечание из будущего, ЕСЛИ кто-то придет сюда из Google (например, я):

2018-08-29 13:43:33,495: WARNING:certbot.plugins.standalone: 
The standalone specific supported challenges flag is deprecated. 
Please use the --preferred-challenges flag instead.

Если вы используете nginx, вы можете использовать модуль nginx с certbot certonly --nginx , он подключается к существующему серверу nginx без какой-либо настройки.

Флаг --http-01-port не очень интуитивно понятен, и я не смог найти его в справке по команде, и мне пришлось искать флаг --http-01-port в Google. Было бы неплохо иметь упоминание флага в справке.