Останнє оновлення: 8 серп. 2016 р. | Переглянути всю документацію

Цей документ містить корисні поради, якщо ви є хостинговим провайдером або великим веб-сайтом, інтегруючим Let’s Encrypt, або ви пишете клієнтське програмне забезпечення для Let’s Encrypt.

План перетворень

І Let’s Encrypt, і Web PKI будуть продовжувати розвиватися з плином часу. Ви повинні переконатися, що у вас є можливість легко оновлювати всі сервіси, які використовують Let’s Encrypt. Якщо ви також працюєте з клієнтами, які довіряють сертифікатам Let’s Encrypt, особливо переконайтеся, що ці клієнти отримують регулярні оновлення.

У майбутньому ці речі, ймовірно, зміняться:

• кореневі і проміжні сертифікати, з яких ми видаємо
• хеш-алгоритми, які ми використовуємо при підписанні сертифікатів
• типи ключів і ключової сили перевірок, для яких ми готові підписати сертифікати кінцевого підприємства
• та протокол ACME(Середовище автоматичного управління сертифікатами)

Ми завжди прагнемо повідомляти якомога швидше про такі зміни, хоча у разі виявлення серйозного порушення безпеки будь-якого компонента, можливо, нам доведеться внести зміни в дуже короткий термін або негайно. Зокрема, для проміжних змін, не вказуйте посередника, який буде використовуватися, натомість краще скористайтеся заголовком Посилання: rel = "вгору" з протоколу ACME, оскільки посередники можуть відрізнятися.

Так само, ми, швидше за все, змінимо URL-адресу умов обслуговування (ToS) під час її оновлення. Щоб уникнути жорсткого кодування URL-адреси ToS, натомість опирайтеся на заголовок Посилання: rel="terms-of-service" для визначення, яку URL-адресу ToS використовувати.

Вас також може зацікавити розробка способу оновлювати налаштування TLS, оскільки нові атаки знаходяться в пакетах шифрів або версіях протоколів.

Отримання оновленнь

Підпишіться на нашу групу Оголошення API, щоб отримувати невеликі оновлення про важливі зміни, такі як описані вище. Це корисно не тільки для розробників, а й для хостинг-провайдерів.

Для отримання більших за обсягом оновлень про технічне обслуговування та перебої, відвідайте нашу сторінку статусу і натисніть “Підписатися” у верхньому правому куті. Це найбільш корисно для хостинг-провайдерів.

Також переконайтеся, що ви використовуєте дійсну адресу електронної пошти для облікового запису ACME. На цю адресу ми надсилатимемо вам повідомлення про закінчення терміну дії та повідомлення про будь-які проблеми, характерні для вашого облікового запису.

Хто є передплатником

Наша CPS та Угода підписника вказує, що Абонент - це той, хто володіє приватним ключем для отримання сертифіката. Для хостинг-провайдерів це постачальник, а не його клієнт. У разі, якщо ви розробляєте програму, яку люди реалізують самі, то вони і є абонентами.

Контактна адреса електронної пошти, надана під час створення облікового запису (та ж реєстрація), має посилатися на абонента. Ми надішлемо електронний лист на цю адресу, щоб попередити про закінчення терміну дії сертифікатів та повідомити про зміни в нашій політиці конфіденційності. Якщо ви хостинг-провайдер, то ці сповіщення мають надходити вам, а не клієнту. Найкраще створити список розсилки або псевдонім електронної пошти, щоб більше людей могли відповісти на повідомлення, якщо ви підете у відпустку.

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

Один обліковий запис чи більше?

У ACME можна створити один обліковий запис і використовувати його для всіх авторизацій та видач або створити один обліковий запис для кожного клієнта. Така гнучкість може бути корисною. Наприклад, деякі хостинг-провайдери можуть захотіти використовувати окремий обліковий запис для кожного клієнта та зберігати ключі облікового запису в різних контекстах, так щоб у випадку загрози не дозволити видати ключі усіх клієнтів.

Однак для більшості великих хостинг-провайдерів ми рекомендуємо використовувати один обліковий запис і добре охороняти відповідний ключ. Це полегшує ідентифікацію сертифікатів, що належать тому самому суб’єкту, також простіше оновлювати контактну інформацію та при необхідності спрощувати коригування обмежень тарифів. Ми не зможемо ефективно регулювати ліміти тарифів, якщо використовується багато різних облікових записів.

Багатодоменні сертифікати SAN (Альтернативна назва сервера)

Наша політика видачі дозволяє до 100 імен на сертифікат. Від вас залежить, чи використовувати окремий сертифікат для кожного імені хосту, або об’єднати багато імен у невеликій кількості сертифікатів.

Розподіл сертифікатів за іменем хосту означає, що для додавання та видалення доменних імен на логічному рівні під час їх створення або виходу з ладу потрібно менше рухомих частин. Окремі сертифікати сприяють мінімізації розміру сертифіката, що може прискорити рукостискання HTTPS у мережах з низькою пропускною здатністю.

З іншого боку, використання великих сертифікатів з багатьма іменами хостів дозволяє керувати меншою кількістю сертифікатів в загальному. Якщо вам потрібно підтримувати старіші клієнти, як-от Windows XP, які не підтримують вказівку імені сервера TLS (SNI), вам знадобиться унікальна IP-адреса для кожного сертифіката, тому використання додаткових імен у кожному сертифікаті зменшує кількість необхідних IP-адрес.

Для більшості інсталяцій обидва варіанти забезпечують однакову безпеку.

Зберігання та повторне використання сертифікатів і ключів

Основна перевага Let’s Encrypt полягає в тому, що система дозволяє автоматично видавати як частину процесу створення нового веб-сайту. Однак, якщо ваша інфраструктура може неодноразово створювати нові інтерфейси для того самого веб-сайту, ці інтерфейси повинні спочатку спробувати використати сертифікат і приватний ключ із довготривалого сховища та видати новий лише тоді, коли сертифікат недоступний або всі наявні сертифікати закінчилися.

Це допомагає Let’s Encrypt ефективно надавати послуги якомога більшій кількості людей. Для вас це гарантує, що ви зможете реалізувати свій веб-сайт у будь-який момент, незалежно від стану Let’s Encrypt.

Наприклад, багато сайтів починають використовувати Docker для надання нових екземплярів інтерфейсу за потреби. Якщо ви налаштували свої контейнери Docker на видачу сертифіката під час запуску, не зберігаючи при цьому свої облікові дані та ключі стабільно, ваш обліковий запис, імовірно, зіткнеться з перевищенням ліміту, якщо одночасно буде запущено занадто багато екземплярів. У гіршому випадку, якщо вам доведеться знищити та відтворити всі свої екземпляри одночасно, жоден із ваших екземплярів не буде затверджений, а ваш сайт не працюватиме протягом кількох днів, доки не закінчиться ліміт. Однак, ця проблема не є унікальною для обмежень кількості. У вас виникне та ж проблема, коли знадобиться завантажити інтерфейси, а служба Let’s Encrypt буде недоступною з якоїсь причини.

Слід зауважити, що деякі теорії інсталяції стверджують, що ключі шифрування ніколи не повинні залишати фізичну машину, на якій вони були створені. Ця модель може чудово працювати з Let’s Encrypt, якщо ви переконаєтеся, що ці машини та їхні дані зберігаються на довгострокову перспективу, а ви ретельно контролюєте ліміти.

Вибір типу задачі

Якщо ви вибрали завдання ACME http-01, вам потрібно буде надати відповідь на виклик кожному з ваших інтерфейсів, перш ніж сповістити 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 Stapling(Онлайн -протокол стану сертифікату)

Багато браузерів будуть отримувати OCSP з Let’s Encrypt під час завантаження вашого сайту. Це проблема продуктивності та конфіденційності. Теоретично підключення до вашого сайту не повинні чекати вторинного підключення до Let’s Encrypt. Запити OCSP також повідомляють Let’s Encrypt, які сайти відвідують люди. Ми маємо гарну політику конфіденційності і не фіксуємо індивідуальні деталі із запитів OCSP, але ми вважаємо за краще не приймати ці дані в першу чергу. До того ж, ми передбачаємо, що наші видатки на пропускну здатність для обслуговування OCSP кожного разу під час першого відвідування браузером сайту Let’s Encrypt, будуть значною частиною наших витрат на інфраструктуру.

Увімкнення OCSP Stapling допоможе вам покращити продуктивність свого веб-сайту, забезпечити кращий захист конфіденційності для своїх користувачів і допомогти Let’s Encrypt ефективно обслуговувати якомога більше людей.

Налаштування брандмауера

Щоб використовувати Let’s Encrypt, вам потрібно дозволити вихідний трафік порту 443 машин, які керують вашим клієнтом ACME. Ми не публікуємо IP-адреси служби ACME, і вони будуть змінені без попереднього повідомлення.

Для завдання “http-01” ACME вам потрібно дозволити вхідний трафік порту 80. Ми не публікуємо IP-адреси, з яких ми виконуємо перевірку, а тому вони змінюватимуться без попередження.

Примітка: Ми рекомендуємо завжди дозволяти звичайний HTTP-доступ до вашого веб-серверу із переадресуванням на HTTPS. Цей режим завжди забезпечує кращу роботу користувача, ніж сервер, який відмовляється або перериває підключення через порт 80, і забезпечує той самий рівень безпеки.

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

Підтримування основних алгоритмів

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

Ми рекомендуємо використовувати конфігурацію подвійного ключа, яка пропонує сертифікацію RSA за замовчуванням, і (набагато меншу) сертифікацію ECDSA для клієнтів, які вказують, що вони її підтримують.

HTTPS за умовчанням

Для хостинг-провайдерів ми рекомендуємо автоматично видавати сертифікати та налаштувати HTTPS для всіх імен хостів, якими ви керуєте, і запропонувати налаштування, яке може змінити користувач, щоб переадресувати URL-адреси HTTP на їхні HTTPS еквіваленти. Ми рекомендуємо це налаштування для наявних облікових записів вимкнути за замовчуванням, тоді як для нових облікових записів цей параметр увімкнено за замовчуванням.

Обґрунтування: Наявні веб-сайти, ймовірно, містять деякі підресурси HTTP (скрипти, CSS та зображення). Якщо ці сайти автоматично перенаправляються на їхні версії HTTPS, браузери блокуватимуть деякі з цих підресурсів через блокування змішаного вмісту. Це може порушити функціональність сайту. Однак, якщо це новий сайт, який уже перенаправляється на HTTPS, то, швидше за все, засновник сайту включить підресурси лише до HTTPS, тому що якщо він спробує включити ресурси в HTTP, то відразу помітить, що це не працює.

Ми рекомендуємо дозволити клієнтам встановлювати HTTP Strict-Transport-Security (HSTS) із максимальною тривалістю за замовчуванням шістдесят днів. Однак це налаштування має супроводжуватися попередженням про те, що якщо клієнту доведеться перейти до хостинг-провайдера, який не пропонує HTTPS, налаштування HSTS у браузерах зробить його сайт недоступним. Крім того, і замовник, і хостинг-провайдер повинні знати, що заголовок HSTS може перетворити помилки сертифіката на складні збої. Наприклад, хоча люди зазвичай можуть пропускати попередження браузера про невідповідність імені або закінчення терміну дії сертифіката, браузери не дозволяють пропускати попередження про роботу імені хоста з активним заголовком HSTS.

Коли поновлювати

Ми рекомендуємо автоматично поновлювати сертифікати, коли залишиться ще третина їхнього загального терміну служби. Для поточних сертифікатів Let’s Encrypt, які дійсні протягом 90 днів, це означає поновлення за 30 днів до закінчення терміну дії.

Якщо вам потрібно надати більше 10 000 імен хостів, ми також рекомендуємо автоматизувати оновлення невеликими тиражами, а не групування оновлень на великі шматки. Така поведінка зменшує ризик: якщо служба Let’s Encrypt неактивна, поки вам потрібно поновити її, або є тимчасовий збій у ваших системах оновлення, це буде впливати лише на деякі з ваших сертифікатів, а не на всі. Крім того, це робить наше планування потужностей простішим.

Можливо, ви віддаєте перевагу видаванню великої кількості сертифікатів для всіх ваших доменів, щоб швидко розпочати роботу, що є нормальним явищем. Потім ви можете просто вказати дати поновлення за допомогою одноразового процесу поновлення деяких сертифікатів за день до звичайної дати поновлення, деяких за два дні і так далі.

Якщо ви пропонуєте клієнтське програмне забезпечення, яке автоматично налаштовує періодичний пакет завдань, переконайтеся, що воно запускається у випадкову секунду протягом дня, а не в той самий час. Це гарантує, що великі навантаження не будуть довільно перенаправлені на Let’s Encrypt на початку години чи хвилини. Оскільки Let’s Encrypt має забезпечити здатність задовольняти пікові навантаження, зменшення раптових навантажень може допомогти нам заощадити витрати.

Повторне виправлення помилок

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

Резервні копії при повторній спробі означають, що ваше програмне забезпечення для випуску має відстежувати невдачі, а також успіхи, та перевіряти, чи не було збою під час останньої спроби перед повторною спробою. Немає сенсу робити спроби видачі сотні разів на годину, оскільки повторні збої зазвичай є послідовними.

Усі помилки слід передати відповідальному керівництву, щоб перевірити, чи є якісь конкретні несправності, які потребують вирішення.