Документ будет полезен хостинг-провайдерам, интеграторам и разработчикам клиентского ПО для Let’s Encrypt.
И Let’s Encrypt, и технология Web PKI продолжают развиваться. Нужно быть готовыми к необходимым обновлениям сервисов, которые использует Let’s Encrypt. Особое внимание уделяйте регулярному обновлению исходного кода ACME-клиентов.
Нами запланированы следующие изменения:
Аналогично, мы меняем URL ссылки на условия использования сервиса (terms of service, ToS) сразу после их обновления. Избегайте явного указания URL для ToS в исходном коде ACME-клиентов, вместо этого используйте содержимое заголовка Link: rel="terms-of-service" из ответа от серверов Let’s Encrypt.
Аналогичным образом, мы можем изменить URL условий предоставления услуг (ToS) по мере его обновления. Рекомендуем использовать содержимое заголовка Link: rel="terms-of-service" из ответа серверов Let’s Encrypt.
Также потребуется поддерживать в актуальном состоянии TLS-конфигурацию, для противодействия вновь найденным уязвимостям в наборах шифров или версиях TLS-протокола.
Для получения кратких уведомлений о важных изменениях (таких, как описано выше), подпишитесь на группу рассылки API Announcements. Рекомендуется как разработчикам клиентского ПО, так и хостинг-провайдерам.
Для получения развёрнутой информации о сервисе, посетите нашу страницу текущего состояния, и нажмите кнопку Subscribe справа вверху. Рекомендуется хостинг-провайдерам.
Наши CP/CPS и Соглашение с абонентом указывают, что абонентом является лицо, владеющее закрытым ключом сертификата. Если вы - хостинг-провадер, то подписчиком являетесь вы, а не ваши клиенты. Если вы разрабатываете клиентское ПО, которое пользователь разворачивает и настраивает самостоятельно, то подписчиком будет пользователь, и т.д.
Суть этого в том, что если вы являетесь хостинг-провайдером, вам не нужно получать согласие клиентов на наше Соглашение с абонентом. Вам достаточно выпустить сертификаты для доменов под вашим управлением, и тут же начать их использовать.
Согласно протоколу ACME, для авторизации и выпуска сертификатов возможно использование как одного общего аккаунта для нескольких клиентов, так и индивидуальных аккаунтов для каждого клиента в отдельности. Это может быть полезным, например, для хостинг-провайдеров. Создание индивидуальных аккаунтов для клиентов, с последующим их раздельным хранением, поможет в ситуации, когда один или несколько аккаунтов скомпрометированы, но остальные аккаунты в безопасности.
Тем не менее, для большинства хостинг-провайдеров мы рекомендуем использовать один общий аккаунт для всех клиентов, с хорошо охраняемым закрытым ключом для него. Это упрощает идентификацию сертификатов, принадлежащих одному лицу, и упрощает корректировку ограничений скорости при необходимости. Мы не сможем эффективно корректировать ограничения в случае использования индивидуальных аккаунтов для ваших клиентов.
Мы разрешаем до 100 имён на один сертификат в зависимости от выбранного профиля сертификата. Использовать ли вам отдельный сертификат для каждого доменного имени, или сгруппировать доменные имена для нескольких сертификатов - мы оставляем на ваше усмотрение.
Выпуск уникальных сертификатов на каждое доменное имя упрощает добавление или удаление доменов, по мере необходимости. Кроме того, отдельные сертификаты имеют минимальный размер, что ускоряет этап “рукопожатия” между браузером клиента и web-сервером в сетях с низкой пропускной способностью. Ознакомьтесь с нашими ограничениями скорости, чтобы убедиться, что вы можете получить столько сертификатов, сколько вам нужно.
С другой стороны, если вы используете множество интерфейсов для сайтов, имеет смысл поддерживать небольшое количество серверов для выпуска сертификатов. Если вам нужно поддерживать старые клиенты, такие как Windows XP, которые не поддерживают TLS Server Name Indication (SNI), вам понадобится уникальный IP адрес для каждого сертификата, так что добавление большего количества имен на каждый сертификат уменьшает количество IP адресов, которые вам нужны.
В общем случае, оба варианта обеспечивают одну и ту же безопасность.
Особая ценность Let’s Encrypt - автоматический выпуск сертификата для нового сайта. Однако, если ваша инфраструктура предполагает создание новых интерфейсов для одного и того же сайта, целесообразнее использовать сертификат и закрытый ключ из долговременнного хранилища. Новый сертификат стоит выпускать в случае, когда имеющиеся сертификаты закончились, или истёк срок их действия.
Такой подход поможет Let’s Encrypt качественно предоставлять свои услуги как можно большему количеству клиентов. Вы же всегда сможете запустить свой новый сайт в любое удобное вам время, независимо от состояния сервисов Let’s Encrypt.
К примеру, всё чаще web-мастера используют Docker для создания новых инстансов для сайтов. Если вы настроите контейнеры Docker на выпуск сертификатов в момент старта, вместо использования сертификатов и ключей из долговременного хранилища, то, скорее всего, вы превысите ограничения на использование ресурсов Let’s Encrypt. В худшем случае, если вам придётся уничтожить и заново создать все ваши экземпляры одновременно, вы можете оказаться в ситуации, когда ни один из ваших экземпляров не сможет получить сертификат, и ваш сайт будет недоступен в течение нескольких дней до истечения ограничения скорости. Однако этот тип проблемы не является уникальным для ограничения скорости. Та же проблема возникнет, если по каким-либо причинам сервисы Let’s Encrypt будут недоступны.
Некоторые подходы к развёртыванию сайтов проповедуют хранение закрытых ключей строго на тех компьютерах, на которых они были созданы. Эта модель также совместима с Let’s Encrypt до тех пор, пока вы обеспечиваете длительное время работы ваших машин без перезагрузки, консистентность данных в хранилище, и отслеживаете момент наступления ограничений.
Если вы используете проверку http-01 ACME, вам необходимо обеспечить формирование ответа от всех интерфейсов перед уведомлением Let’s Encrypt о готовности пройти проверку. Если таких интерфейсов у вас много, задача будет непростой. В этом случае, разумнее выбрать проверку dns-01. Разумеется, если у вас несколько географически разнесённых DNS серверов, необходимо убедиться, что TXT-запись есть на каждом из них.
Кроме того, при использовании проверки dns-01 необходимо удалить старые TXT-записи, чтобы ответ на запрос Let’s Encrypt не оказался слишком большим.
Если же вы настаиваете на проверке http-01, возможно, вам пригодятся HTTP-редиректы. Вы можете настроить каждый из ваших фронтендов на перенаправление /.well-known/acme-challenge/XYZ на validation-server.example.com/XYZ для всех XYZ. Это делегирует ответственность за выдачу сертификатов validation-server, поэтому этот сервер следует хорошо защитить.
Учитывая вышесказанное, если вы используете множество интерфейсов для сайтов, имеет смысл поддерживать небольшое количество серверов для выпуска сертификатов. Так будет проще организовать редирект для проверки http-01, и реализовать долговременное хранение ключей и сертификатов.
Для использования Let’s Encrypt вам необходимо разрешить исходящий трафик на порт 443 с машин, на которых работает ваш ACME клиент. Мы не публикуем диапазоны IP-адресов для нашего ACME-сервиса, и они могут изменяться без предварительного уведомления.
Для проверки http-01, разрешите входящий трафик для порта 80. Мы не публикуем диапазоны IP-адресов, с которых мы выполняем проверку, и они могут изменяться без предварительного уведомления.
Примечание: мы рекомендуем всегда разрешать обычный HTTP-доступ к вашему веб-серверу с перенаправлением на HTTPS. Это обеспечивает лучшее взаимодействие с пользователем, чем веб-сервер, который отклоняет или блокирует соединения на порту 80, и обеспечивает тот же уровень безопасности.
Для всех проверочных заданий вам необходимо разрешить входящий трафик на порт 53 (TCP и UDP) к вашим авторитативным DNS-серверам.
Let’s Encrypt принимает RSA-ключи длиной от 2048 до 4096 бит включительно, а также ECDSA ключи типа P-256 и P-384. Это верно и для ключей аккаунтов пользователей, и для ключей шифрования сертификатов, но использование ключей аккаунта для шифрования сертификата невозможно. Вы не можете повторно использовать ключ учетной записи в качестве ключа сертификата.
Мы рекомендуем использовать конфигурацию с двумя сертификатами, по-умолчанию предлагая RSA-сертификаты. ECDSA-сертификаты используются гораздо реже, и только для ACME-клиентов, обеспечивающих их поддержку.
Для хостинг-провайдеров мы рекомендуем автоматически выдавать сертификаты и настраивать HTTPS для всех имён хостов, которые вы контролируете, а также предлагать настраиваемую пользователем опцию для перенаправления HTTP-URL-адресов на их HTTPS-эквиваленты. Мы рекомендуем, чтобы для существующих аккаунтов эта опция была отключена по умолчанию, а для новых аккаунтов — включена по умолчанию.
Обоснование: существующие веб-сайты, скорее всего, содержат некоторые HTTP-подресурсы (скрипты, CSS и изображения). Если эти сайты будут автоматически перенаправляться на их HTTPS-версии, браузеры будут блокировать некоторые из этих подресурсов из-за блокировки смешанного содержимого. Это может повлиять на работоспособность сайта. Однако тот, кто создаёт новый сайт и обнаруживает, что он перенаправляется на HTTPS, скорее всего, будет включать только HTTPS-подресурсы, потому что если они попытаются включить HTTP-подресурс, они сразу заметят, что он не работает.
Мы рекомендуем разрешить клиентам устанавливать заголовок HTTP Strict-Transport-Security (HSTS) со значением max-age по умолчанию шестьдесят дней. Однако эта настройка должна сопровождаться предупреждением о том, что если клиенту потребуется перейти к хостинг-провайдеру, который не поддерживает HTTPS, кэшированная настройка HSTS в браузерах сделает его сайт недоступным. Кроме того, как клиент, так и хостинг-провайдер должны знать, что заголовок HSTS превращает ошибки сертификатов в жёсткие сбои. Например, хотя люди обычно могут обойти предупреждение браузера о несоответствии имени или истёкшем сертификате, браузеры не позволяют обойти такое предупреждение для имён хостов с активным заголовком HSTS.
Мы рекомендуем проверять информацию о продлении ACME для каждого сертификата как минимум дважды в день. Конечная точка ARI будет рекомендовать, когда продлевать сертификат.
В качестве резервного механизма для ARI мы рекомендуем автоматически продлевать сертификаты, когда останется треть от их общего срока действия. Для сертификатов со сроком действия менее 10 дней мы рекомендуем продлевать их на середине общего срока действия. Для текущих 90-дневных сертификатов Let’s Encrypt это означает продление за 30 дней до истечения срока действия.
Если вы выдаёте сертификаты для более чем 10,000 имён хостов, мы также рекомендуем автоматическое продление небольшими партиями, а не группировку продлений в большие блоки. Это снижает риск: если у Let’s Encrypt произойдёт сбой в момент, когда вам нужно продлить сертификаты, или возникнет временный сбой в ваших системах продления, это затронет только несколько ваших сертификатов, а не все сразу. Это также упрощает наше планирование мощностей.
Возможно, вы захотите массово выпустить сертификаты для всех ваших доменов, чтобы быстро начать работу, — это нормально. Затем вы можете распределить время продления, выполнив однократный процесс продления некоторых сертификатов на 1 день раньше обычного срока, некоторых — на 2 дня раньше и так далее.
Если вы предлагаете клиентское программное обеспечение, которое автоматически настраивает периодическую пакетную задачу, убедитесь, что она выполняется в случайную секунду дня, а не всегда в одно и то же время. Это гарантирует, что Let’s Encrypt не будет получать произвольные всплески трафика в начале часа или минуты. Поскольку Let’s Encrypt необходимо выделять мощности для пиковых нагрузок, снижение всплесков трафика помогает нам сдерживать расходы.
Ошибки обновления не стоит считать фатальными. Вам следует реализовать корректную логику повторных попыток в ваших службах выдачи сертификатов, используя шаблон экспоненциальной задержки, с максимумом одна попытка в день на один сертификат. Например, разумный график повторных попыток может быть таким: 1-я попытка через одну минуту, 2-я через десять минут, 3-я через 100 минут, 4-я и последующие через один день. У вас, разумеется, должен быть способ для администраторов запрашивать досрочные повторные попытки для отдельных доменов или глобально.
Задержки при повторных попытках означают, что ваше программное обеспечение для выдачи сертификатов должно отслеживать как сбои, так и успешные операции, а также проверять наличие недавних сбоев перед попыткой новой выдачи. Нет смысла пытаться выполнить выдачу сотни раз в час, поскольку повторяющиеся сбои, скорее всего, носят постоянный характер.
Все ошибки должны отправляться ответственному администратору, чтобы можно было определить, требуют ли исправления конкретные проблемы.