Последнее обновление: 8 авг. 2016 г. | Вся документация

Документ будет полезен хостинг-провайдерам, интеграторам и разработчикам клиентского ПО для Let’s Encrypt.

Планирование изменений

И Let’s Encrypt, и технология Web PKI продолжают развиваться. Нужно быть готовыми к необходимым обновлениям сервисов, которые использует Let’s Encrypt. Особое внимание уделяйте регулярному обновлению исходного кода ACME-клиентов.

Нами запланированы следующие изменения:

• корневой и промежуточный сертификаты, на основании которых выпускаются сертификаты
• алгоритм хэширования для подписи сертификатов
• типы ключей и проверок ключей, для подписи сертификатов
• и сам протокол 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 справа вверху. Рекомендуется хостинг-провайдерам.

Убедитесь, что указан верный адрес электронной почты для ACME-аккаунта. Мы используем этот адрес для отправки уведомлений об истечении срока действия выпущенных сертификатов, а также для взаимодействия с вами в случае специфичных проблем.

Кто такой “Подписчик”

В нашем Соглашении, под термином “Подписчик” мы понимаем любого владельца закрытого ключа для сертификата. Если вы - хостинг-провадер, то подписчиком являетесь вы, а не ваши клиенты. Если вы разрабатываете клиентское ПО, которое пользователь разворачивает и настраивает самостоятельно, то подписчиком будет пользователь, и т.д.

Адрес электронной почты, указываемый при создании аккаунта Let’s Encrypt (он же “регистрация”) должен принадлежать Подписчику. Мы используем этот адрес для отправки предупреждений об истечении срока действия сертификатов, и уведомлений об изменении нашей политики конфиденциальности. Если вы - хостинг-провайдер, эти уведомления должны приходить к вам, а не к вашим клиентам. Идеально было бы настроить список рассылки, чтобы несколько сотрудников могли получать от нас уведомления в ваше отстутствие.

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

Один аккаунт или несколько?

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

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

Мультидоменные сертификаты (SAN)

Наша политика выпуска сертификатов ограничивает число доменных имён для одного сертификата - не более 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-validation/XYZ на validation-server.example.com/XYZ для любого XYZ. Это перенесёт ответственность за выдачу сертификатов на сервер валидации, так что позаботьтесь о его безопасности.

Центральные серверы валидации

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

Реализация сшивания OCSP (OCSP Stapling)

Многие браузеры проверяют сертификат Let’s Encrypt с помощью OCSP, когда загружают сайт, что вызывает [проблему производительности и безопасности](https://blog.cloudflare.com/ocsp-stapling-how-cloudflare-just-made-ssl-30/). Это проблема производительности и конфиденциальности. В идеале, подключение к вашему сайту не должно ожидать результата дополнительного подключения к Let’s Encrypt. Кроме того, в запросах OCSP содержится информация о сайтах, которые посещают пользователи. Мы придерживаемся нашей политики конфиденциальности, и не сохраняем данные пользователей из OCSP-запросов, мы в принципе не нуждаемся в получении этих данных. Кроме того, расходы на трафик по обслуживанию OCSP-запросов для всех сайтов с сертификатом Let’s Encrypt составили бы значительную долю наших инфраструктурных издержек.

Настроив “OCSP-сшивание” на ваших web-серверах, вы улучшите производительность ваших сайтов, обеспечите конфиденциальность для ваших пользователей, и поможете Let’s Encrypt эффективнее обслуживать как можно больше клиентов.

Настройка брандмауера

Для работы Let’s Encrypt разрешите исходящий трафик для порта 443 на машинах с запущенным ACME-клиентом. Мы не публикуем IP-адреса наших ACME-сервисов, и, как правило, изменяем их без уведомления.

Для проверки http-01, разрешите входящий трафик для порта 80. Мы не публикуем IP-адреса для выполнения проверки, и. как правило, изменяем их без уведомления.

Обратите внимание: мы рекомендуем всегда настраивать HTTP-доступ до вашего web-сервера, с последующим редиректом на HTTPS. Для пользователей это будет лучше, чем сброc HTTP-соединения, при том же уровне безопасности.

Для всех проверок, разрешите входящий трафик на порт 53 (TCP и UDP) для ваших DNS-серверов.

Поддерживаемые алгоритмы шифрования

Let’s Encrypt принимает RSA-ключи длиной от 2048 до 4096 бит включительно, а также ECDSA ключи типа P-256 и P-384. Это верно и для ключей аккаунтов пользователей, и для ключей шифрования сертификатов, но использование ключей аккаунта для шифрования сертификата невозможно. Вы не можете повторно использовать ключ учетной записи в качестве ключа сертификата.

Мы рекомендуем использовать конфигурацию с двумя сертификатами, по-умолчанию предлагая RSA-сертификаты. ECDSA-сертификаты используются гораздо реже, и только для ACME-клиентов, обеспечивающих их поддержку.

HTTPS по-умолчанию

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

Поясняем: существующие web-сайты, как правило, включают в себя дополнительные HTTP-ресурсы (скрипты, файлы стилей, изображения). Если эти сайты автоматически переключить на их HTTPS-версии, то браузеры могут заблокировать доступ к HTTP-ресурсам по причине смешанного контента (Mixed Content Blocking). Это может повлиять на работоспособность сайта. В то же время, разработчик нового сайта, скорее всего сразу организует доступ к ресурсами по HTTPS, т.к. недоступность доступа по HTTP будет замечена в процессе разработки.

Мы рекомендуем настраивать заголовок ответа сервера HTTP Strict-Transport-Security (HSTS) с параметром max-age, равным 60 дней по-умолчанию. Вместе с тем, необходимо помнить, что если клиент перенесёт свой сайт к хостинг-провайдеру без настроенного доступа по HTTPS, закэшированная браузерами пользователей настройка HSTS сделает сайт недоступным для них. Проблемы с заголовком HSTS считаются серьёзной угрозой безопасности. Пользователи обычно игнорируют предупреждения браузера о несовпадении введённого имени домена с именем домена в сертификате, или о просроченном сертификате, и нажимают кнопку “Продолжить”. В случае с заголовком HSTS, обойти предупреждение и получить доступ к сайту не удастся.

Когда обновлять сертификат

Мы рекомендуем настраивать автоматическое обновление сертификатов в последней трети их жизни. Для сертификатов Let’s Encrypt срок действия по-умолчанию 90 дней, таким образом, обновление необходимо выполнить спустя 60 дней после выпуска сертификата.

Если вы управляете сертификатами для более чем 10 000 доменных имён, мы рекомендуем выполнять обновление небольшими партиями, а не все сразу. Это снижает ваши риски: если сервисы Let’s Encrypt по какой-либо причине будут недоступны, или возникли проблемы в вашей инфраструктурой обновления - ущерб будет причинён небольшой части сертификатов, а не всему количеству. Кроме того, обновление по частям поможет лучше планировать загрузку оборудования.

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

Если вы настраиваете специальный скрипт обновления, то убедитесь, что его запуск выполняется в произвольно выбираемый момент времени, а не в конкретный. Это гарантирует, что на серверах Let’s Encrypt не будет серьёзных всплесков трафика. Т.к. нам необходимо обеспечить запас мощности для противодействия таким всплескам, их снижение поможет уменьшить наши издержки.

Повтор попыток при ошибках обновления

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

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

О всех ошибках обновления следует извещать ответственного администратора, для своевременного решения возникших проблем.