Автоматический HTTPS

Caddy — первый и единственный веб-сервер, который автоматически использует HTTPS по умолчанию.

Автоматический HTTPS предоставляет сертификаты TLS для всех ваших сайтов и следит за их продлением. Он также перенаправляет HTTP на HTTPS! Caddy использует безопасные и современные настройки — без простоя, дополнительной конфигурации или отдельного инструментария.

Вот видеоролик (28 секунд), показывающий, как это работает:

Меню:

• Обзор
• Активация
• Эффекты
• Требования к имени хоста
• Локальный HTTPS
• Тестирование
• Вызовы ACME
• TLS по запросу
• Ошибки
• Хранение
• Сертификаты с подстановкой

Обзор

По умолчанию Caddy обслуживает все сайты через HTTPS.

• Caddy обслуживает IP-адреса и локальные/внутренние имена хостов через HTTPS с использованием самоподписанных сертификатов, которые автоматически доверяются локально (если разрешено).
  • Примеры: localhost, 127.0.0.1
• Caddy обслуживает общедоступные имена DNS через HTTPS, используя сертификаты от публичного центра сертификации ACME, такого как Let's Encrypt или ZeroSSL .
  • Примеры: example.com, sub.example.com, *.example.com

Caddy автоматически продлевает все управляемые сертификаты и перенаправляет HTTP (порт по умолчанию 80) на HTTPS (порт по умолчанию 443).

Для локального HTTPS:

• Caddy может запросить пароль для установки уникального корневого сертификата в хранилище доверенных сертификатов. Это происходит только один раз на корень; и вы можете его удалить в любое время.
• Любой клиент, обращающийся к сайту без доверия к корневому сертификату CA Caddy, увидит ошибки безопасности.

Для общедоступных доменных имён:

• Если записи A/AAAA вашего домена указывают на ваш сервер,
• порты 80 и 443 открыты для внешнего доступа,
• Caddy может привязываться к этим портам (или эти порты перенаправляются на Caddy),
• ваш каталог данных доступен для записи и сохраняется,
• и имя вашего домена появляется где-то в соответствующей конфигурации,

то сайты будут автоматически обслуживаться через HTTPS. Вам больше не нужно ничего делать. Всё работает само!

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

Активация

Caddy неявно активирует автоматический HTTPS, когда знает имя домена (т.е. имя хоста) или IP-адрес, который он обслуживает. Есть разные способы сообщить Caddy о вашем домене/IP, в зависимости от того, как вы запускаете или настраиваете Caddy:

• Адрес сайта в файле Caddyfile
• Сопоставитель хостов верхнего уровня в JSON маршрутах
• Флаги командной строки, такие как --domain или --from
• Загрузчик сертификатов automate

Любой из следующих пунктов предотвратит активацию автоматического HTTPS, частично или полностью:

• Явное отключение через JSON или через файл Caddyfile
• Отсутствие имён хостов или IP-адресов в конфигурации
• Прослушивание только на порту HTTP
• Префикс адреса сайта с http:// в файле Caddyfile
• Ручная загрузка сертификатов (если не установлено ignore_loaded_certificates)

Особые случаи:

• Домены, заканчивающиеся на .ts.net, не будут управляться Caddy. Вместо этого Caddy автоматически попытается получить эти сертификаты во время рукопожатия от локально запущенного экземпляра Tailscale . Для этого требуется, чтобы HTTPS был включён в вашей учётной записи Tailscale , и процесс Caddy должен выполняться либо с правами root, либо вы должны настроить tailscaled, чтобы предоставить вашему пользователю Caddy разрешение на загрузку сертификатов.

Эффекты

При активации автоматического HTTPS происходит следующее:

• Сертификаты получают и продлеваются для всех подходящих имён доменов
• HTTP перенаправляется на HTTPS (это использует порт HTTP 80)

Автоматический HTTPS никогда не перезаписывает явную конфигурацию, а только дополняет её.

Если у вас уже есть сервер, прослушивающий порт HTTP, маршруты перенаправления HTTP->HTTPS будут вставлены после ваших маршрутов с сопоставителем хостов, но перед пользовательским маршрутом по умолчанию.

Вы можете настроить или отключить автоматический HTTPS при необходимости; например, вы можете пропустить определённые доменные имена или отключить перенаправления (для файла Caddyfile сделайте это с помощью глобальных опций).

Требования к имени хоста

Все имена хостов (доменные имена) подходят для полностью управляемых сертификатов, если они:

• не пустые
• состоят только из букв, цифр, дефисов, точек и символа подстановки (*)
• не начинаются и не заканчиваются точкой (RFC 1034)

Кроме того, имена хостов подходят для общедоступных сертификатов, если они:

• не являются localhost (включая .localhost, .local и .home.arpa домены верхнего уровня)
• не являются IP-адресом
• имеют только один символ подстановки * в качестве левой метки

Локальный HTTPS

Caddy автоматически использует HTTPS для всех сайтов с указанным хостом (домен, IP или имя хоста), включая внутренние и локальные хосты. Некоторые хосты либо не являются общедоступными (например, 127.0.0.1, localhost), либо обычно не подходят для общедоступных сертификатов (например, IP-адреса — вы можете получить сертификаты для них, но только от некоторых ЦС). Они всё равно обслуживаются через HTTPS, если не отключено.

Чтобы обслуживать непубличные сайты через HTTPS, Caddy генерирует свой собственный центр сертификации (CA) и использует его для подписания сертификатов. Цепочка доверия состоит из корневого и промежуточного сертификатов. Листовые сертификаты подписываются промежуточным сертификатом. Они хранятся в каталоге данных Caddy по адресу pki/authorities/local.

Локальный CA Caddy работает на основе библиотек Smallstep .

Локальный HTTPS не использует ACME и не выполняет проверку DNS. Он работает только на локальном компьютере и доверяется только там, где корневой сертификат CA установлен.

Корень CA

Приватный ключ корня уникально генерируется с использованием криптографически защищённого псевдослучайного источника и сохраняется в хранилище с ограниченными правами. Он загружается в память только для выполнения задач подписания, после чего покидает область видимости для сборки мусора.

Хотя Caddy можно настроить на подписание с помощью корня напрямую (чтобы поддерживать несовместимые клиенты), это отключено по умолчанию, и корневой ключ используется только для подписания промежуточных сертификатов.

В первый раз при использовании корневого ключа Caddy попытается установить его в локальное хранилище доверенных сертификатов системы. Если у него нет разрешений на это, он запросит пароль. Это поведение можно отключить в конфигурации, если это не нужно. Если это не удаётся из-за запуска как непривилегированного пользователя, вы можете запустить caddy trust, чтобы повторить установку как привилегированным пользователем.

После установки корневого CA Caddy вы увидите его в вашем локальном хранилище как "Caddy Local Authority" (если вы не настроили другое имя). Вы можете его удалить в любое время (команда caddy untrust делает это легко).

Обратите внимание, что автоматическая установка сертификата в локальные хранилища доверенных сертификатов предназначена только для удобства и не гарантируется, что она будет работать, особенно если используются контейнеры или если Caddy запускается как непривилегированная системная служба. В конечном счёте, если вы полагаетесь на внутреннюю PKI, администратор системы несёт ответственность за обеспечение того, что корневой CA Caddy правильно добавлен в необходимые хранилища доверия (это вне сферы ответственности веб-сервера).

Промежуточные CA

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

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

Тестирование

Чтобы протестировать или поэкспериментировать с вашей конфигурацией Caddy, убедитесь, что вы измените конечную точку ACME на URL-адрес этапа разработки или тестирования, в противном случае вы, вероятно, столкнётесь с лимитами скорости, которые могут заблокировать ваш доступ к HTTPS до недели, в зависимости от того, какой лимит вы превысили.

Один из стандартных CA Caddy — Let's Encrypt , у которого есть конечная точка этапа разработки , которая не подвержена тем же ограничениям скорости :

https://acme-staging-v02.api.letsencrypt.org/directory

Вызовы ACME

Для получения общедоступного TLS-сертификата требуется проверка от общедоступного, стороннего органа. В наши дни этот процесс проверки автоматизируется с помощью протокола ACME и может быть выполнен одним из трёх способов ("типы вызовов"), описанных ниже.

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

Проверка HTTP

Проверка HTTP выполняет авторитетный DNS-запрос для записи A/AAAA кандидатного имени хоста, а затем запрашивает временный криптографический ресурс по порту 80 с использованием HTTP. Если CA видит ожидаемый ресурс, выписывается сертификат.

Для этой проверки необходимо, чтобы порт 80 был доступен извне. Если Caddy не может прослушивать порт 80, пакеты с порта 80 должны быть перенаправлены на HTTP-порт Caddy с помощью HTTP-порта.

Эта проверка включена по умолчанию и не требует явного конфигурирования.

Проверка TLS-ALPN

Проверка TLS-ALPN выполняет авторитетный DNS-запрос для записи A/AAAA кандидатного имени хоста, а затем запрашивает временный криптографический ресурс по порту 443 с использованием TLS-рукопожатия, содержащего специальные значения ServerName и ALPN. Если CA видит ожидаемый ресурс, выписывается сертификат.

Для этой проверки необходимо, чтобы порт 443 был доступен извне. Если Caddy не может прослушивать порт 443, пакеты с порта 443 должны быть перенаправлены на HTTPS-порт Caddy с помощью HTTPS-порта.

Эта проверка включена по умолчанию и не требует явного конфигурирования.

Проверка DNS

Проверка DNS выполняет авторитетный DNS-запрос для записей TXT кандидатного имени хоста и ищет специальную запись TXT с определенным значением. Если CA видит ожидаемое значение, выписывается сертификат.

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

Поскольку CA ACME следуют стандартам DNS при поиске записей TXT для проверки проверки, вы можете использовать записи CNAME для делегирования ответа на проверку другим зонам DNS. Это можно использовать для делегирования поддомена _acme-challenge в другую зону. Это особенно полезно, если ваш поставщик DNS не предоставляет API или не поддерживается одним из плагинов DNS для Caddy.

Поддержка поставщиков DNS — это совместная работа сообщества. Узнайте, как включить проверку DNS для вашего поставщика на нашей вики.

TLS по требованию

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

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

TLS по требованию полезен, если:

• вы не знаете все имена доменов при запуске или перезагрузке сервера,
• имена доменов могут быть некорректно настроены сразу (записи DNS ещё не заданы),
• вы не контролируете имена доменов (например, это домены клиентов).

При включенном TLS по требованию вам не нужно указывать имена доменов в вашей конфигурации, чтобы получить для них сертификаты. Вместо этого, когда принимается TLS-рукопожатие для имени сервера (SNI), для которого у Caddy ещё нет сертификата, рукопожатие приостанавливается, пока Caddy не получит сертификат для завершения рукопожатия. Ожидание обычно занимает всего несколько секунд, и только первое рукопожатие медленное. Все последующие рукопожатия быстрые, потому что сертификаты кешируются и повторно используются, а обновления происходят в фоновом режиме. Будущие рукопожатия могут инициировать обслуживание сертификата для его продления, но это обслуживание происходит в фоновом режиме, если сертификат ещё не истек.

Использование TLS по требованию

TLS по требованию должен быть как включён, так и ограничен, чтобы предотвратить злоупотребление.

Включение TLS по требованию происходит в политиках автоматизации TLS при использовании JSON-конфигурации или в блоках сайтов с директивой tls при использовании Caddyfile.

Для предотвращения злоупотребления этой функцией необходимо настроить ограничения. Это делается в automation объекте JSON-конфигурации или on_demand_tls глобальном параметре Caddyfile. Ограничения «глобальные» и не настраиваются на сайт или домен. Основное ограничение — конечная точка запроса, на которую Caddy будет отправлять HTTP-запрос, чтобы узнать, разрешено ли ему получить и управлять сертификатом для домена в рукопожатии. Это означает, что вам понадобится какой-то внутренний бэкенд, который, например, может запросить таблицу аккаунтов в вашей базе данных и посмотреть, зарегистрирован ли клиент с этим именем домена.

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

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

См. нашу статью в вики для получения дополнительной информации об эффективном использовании TLS по требованию.

Ошибки

Caddy делает всё возможное, чтобы продолжить работу, если возникнут ошибки с управлением сертификатами.

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

Вот что происходит при возникновении ошибки получения или обновления сертификата:

1. Caddy повторно пытается один раз после небольшой паузы, на случай, если это была случайность
2. Caddy делает небольшую паузу, затем переключается на следующий включённый тип проверки
3. После того, как все включённые типы проверок были испробованы, он пробует следующий настроенный эмитент
   • Let's Encrypt
   • ZeroSSL
4. После того, как все эмитенты были опробованы, он уменьшает интервал повторной попытки экспоненциально
   • Максимум 1 день между попытками
   • До 30 дней

Во время повторных попыток с Let's Encrypt Caddy переключается на их эталонную среду, чтобы избежать проблем с лимитами запросов. Это не идеальный подход, но в целом он полезен.

Проверки ACME занимают не менее нескольких секунд, а внутреннее ограничение скорости помогает смягчить случайные злоупотребления. Caddy использует внутреннее ограничение скорости в дополнение к тому, что вы или CA настраиваете, чтобы вы могли предоставить Caddy миллионы имён доменов, и он постепенно, но максимально быстро, получит сертификаты для всех из них. Внутреннее ограничение скорости Caddy в настоящее время составляет 10 попыток на учётную запись ACME каждые 10 секунд.

Для предотвращения утечки ресурсов Caddy прерывает задачи в процессе (включая транзакции ACME) при изменении конфигурации. Хотя Caddy способен обрабатывать частые перезагрузки конфигурации, будьте внимательны к операционным соображениям, таким как это, и рассмотрите возможность группировки изменений конфигурации, чтобы уменьшить перезагрузки и дать Caddy возможность фактически завершить получение сертификатов в фоновом режиме.

Изменение эмитентов

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

По умолчанию Caddy включает две совместимые с ACME CA: Let's Encrypt и ZeroSSL . Если Caddy не может получить сертификат от Let's Encrypt, он попробует получить сертификат от ZeroSSL; если оба варианта не удались, он уменьшит интервал и повторит попытку позже. В вашей конфигурации вы можете настроить, какие эмитенты использует Caddy для получения сертификатов, либо для всех случаев, либо для конкретных имён.

Хранилище

Caddy будет хранить открытые сертификаты, закрытые ключи и другие активы в настроенном хранилище (или в стандартном, если оно не настроено — см. ссылку для получения подробностей).

Самое главное, что вам нужно знать, используя стандартную конфигурацию, — это то, что папка $HOME должна быть доступна для записи и постоянной. Для облегчения отладки Caddy выводит свои переменные окружения при запуске, если задан флаг --environ.

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

Перед попыткой каких-либо транзакций ACME Caddy проверит настроенное хранилище, чтобы убедиться в его доступности для записи и достаточной ёмкости. Это помогает уменьшить ненужное блокирование.

Сертификаты с подстановкой

Caddy может получать и управлять сертификатами с подстановкой, если он настроен на обслуживание сайта с соответствующим именем с подстановкой. Имя сайта соответствует подстановке, если только его левая метка домена — подстановка. Например, *.example.com подходит, но эти не подходят: sub.*.example.com, foo*.example.com, *bar.example.com и *.*.example.com.

Если вы используете Caddyfile, Caddy рассматривает имена сайтов буквально в отношении имён субъектов сертификата. Другими словами, сайт, определённый как sub.example.com, заставит Caddy управлять сертификатом для sub.example.com, а сайт, определённый как *.example.com, заставит Caddy управлять сертификатом с подстановкой для *.example.com. Вы можете увидеть это на нашей странице Общие схемы Caddyfile. Если вам нужно другое поведение, JSON-конфигурация предоставляет вам более точный контроль над субъектами сертификатов и именами сайтов («совпадения хостов»).

Сертификаты с подстановкой представляют собой широкий спектр полномочий и должны использоваться только тогда, когда у вас так много поддоменов, что управление отдельными сертификатами для них будет чрезмерным для PKI или приведёт к достижению установленных CA ограничений.

Примечание: Let's Encrypt требует проверки DNS для получения сертификатов с подстановкой.