Да, проверка HTTP-01 работает в сочетании с Cloudflare в режиме «оранжевого облака». Однако она не работает по HTTPS: проверка HTTP-01 возможна только через порт 80, и:
Многие пользователи Cloudflare настраивают автоматическое перенаправление HTTP на HTTPS, и это делает порт 80 на исходном сервере недоступным, что мешает выполнению проверок HTTP-01.
Поэтому, если вы не включаете такие перенаправления, всё будет работать.
Таким образом, строго говоря, это неверно.
Let’s Encrypt завершится ошибкой только в том случае, если Cloudflare настроен на перенаправление трафика порта 80 до его поступления на исходный сервер.
Я согласен, однако, поскольку информационная безопасность сейчас более актуальна, чем когда-либо, и люди начинают активнее работать с продуктами Zero Trust, частью которых является CF Tunnel, мы будем и должны наблюдать рост использования подобных технологий. Именно поэтому я поднял этот вопрос.
Кажется, вы неправильно поняли, как работает проверка HTTP-01 от Let’s Encrypt.
Она ищет токен, который certbot или другой клиент LE размещает, чаще всего, в подпапке .well-known веб-сервера.
Однако проверка не жестко привязана к запуску запроса на порту 80, игнорированию редиректов HTTP-кодов и немедленному сбою, если токен не найден.
Проверка HTTP-01 способна следовать за HTTP-редиректами (301 и 302) и поэтому может читать папку .well-known через порт 443 по протоколу HTTPS.
Именно поэтому это работает для Cloudflare Universal SSL с перенаправлением (и Cloudflare Tunnel): Cloudflare отвечает вместо веб-сервера на порту 80, перенаправляет запрос на порт 443, где Let’s Encrypt может прочитать токен, а центр сертификации выдает сертификат.
Высокоуровневая схема процесса:
Certbot запускает проверку HTTP-01
→ Отправляет POST-запрос с данными сертификата в CA и размещает токен в .well-known
→ CA отправляет GET-запрос для получения токена по FQDN на порту 80
→ CF перенаправляет запрос на порт 443 и защищает его своим сертификатом Universal SSL
→ Запрос пересылается на сам веб-сервер (через CF Tunnel или напрямую)
→ CA может получить токен из .well-known, так как порт 443 способен предоставить токен так же, как это сделали бы HTTP и порт 80
→ CA отправляет POST-запрос с необработанными данными сертификата, и Certbot создает файлы
Я думаю, что понимаю это довольно хорошо. Вы правы, запрос можно перенаправить на HTTPS, но это зависит от настроек Cloudflare и конфигурации веб-сервера, сработает ли это, так как изначально на сервере-источнике не будет действительного сертификата.
Да, их можно перенаправить на другой порт, но проверки HTTP-01 обязаны всегда начинаться на порту 80.
Проверка HTTP-01 может выполняться только на порту 80. Разрешение клиентам указывать произвольные порты сделало бы проверку менее безопасной, поэтому это не допускается стандартом ACME.
Я согласен, я просто указал на вашу неточность: утверждение, что это никогда не сработает, неверно.
То, как вы процитировали моё предложение, довольно коварно, так как это создаёт ложное впечатление о контексте обсуждения и придаёт фразе иной смысл. Вот моё полное предложение:
Ключевая часть моего утверждения — это сочетание «зашито в код так, чтобы запрос всегда начинался с порта 80», «игнорируются любые HTTP-перенаправления» и «непосредственный сбой», поскольку вы написали:
Это создаёт впечатление, что причиной сбоя вызова HTTP-01 является только перенаправление, что неверно. Кроме того, строго говоря, перенаправление не делает порт 80 «недоступным».
Он делает порт 80 исходного сервера недоступным для всего трафика, направленного на это имя хоста.
Мне не нравится текущий тон обсуждения в этой теме, поэтому я отписываюсь от неё.
Моё мнение о Cloudflare в сочетании с Discourse можно сформулировать так: «многие люди, судя по всему, не могут настроить его правильно, поэтому в целом я бы рекомендовал не включать его. Если вы хотите использовать его для защиты от DDoS-атак, то я бы рекомендовал включать его только с очень специфичными настройками».
Это может быть ещё один глупый вопрос, но так как я обслуживаю только финскую аудиторию, я не вижу причин использовать Cloudflare, поэтому знаю о нём только по репутации.
Но если его единственное преимущество — это защита от DDoS-атак, а DDoS в основном означает просто слишком много запросов от:
бесполезных SEO-краулеров
других ботов, созданных скрипт-кидди
то почему бы не использовать Nginx перед Discourse и не блокировать известных агентов пользователей прямо там? В сочетании с Fail2ban это снизило бы нагрузку примерно на 90 % (конечно, статистика Стетсона, но всё равно это много).
Эта дискуссия очень ценна. Для администратора китайского сайта «Flare» может означать возможность для китайских пользователей нормально обмениваться данными с внешним миром. Я проводил тест некоторое время назад. Если не использовать Orange Cloud и обращаться к серверам в других странах из Китая, сетевые задержки будут очень серьезными. Проблема в том, что запуск форума в Китае подвергается строгой цензуре. Даже несмотря на то, что я создавал неполитический форум, я всё равно пострадал. Мы должны исходить из того, что сервер сайта расположен за пределами Китая. Поэтому, если я создам форум с помощью Discourse, мне придется учитывать, можно ли использовать Cloudflare.
