Останнє оновлення: | Переглянути всю документацію
Let’s Encrypt передбачає ліміт частот, щоб забезпечити справедливе використання найбільшою кількістю людей. Ми вважаємо, що ці ліміти частот є достатньо високі для того, щоб працювати за замовчуванням для багатьох людей. Також, ми розробили їх так, щоб оновити сертифікати і ніколи не перевищувати ліміт частот, тому великі організації можуть поступово збільшувати кількість сертифікатів, які можуть видаватись без затвердження Let’s Encrypt.
Якщо Ви клієнт, який активно розробляє та тестує Let’s Encrypt, просимо використовувати наш простір для тестувань замість виробництва API. Якщо Ви працюєте з інтеграцією Let’s Encrypt, як постачальник, або з великим сайтом, будь ласка, перегляньте наш посібник з інтеграції.
Основне обмеження - кількість сертифікатів на зареєстрований домен(50 на тиждень). Як правило, зареєстрований домен є частиною домену, який Ви придбали з Вашого реєстратора доменних імен. Наприклад, в імені www.example.com, зареєстрованим доменом є example.com. У new.blog.example.co.uk, зареєстрваним доменом є example.co.uk. Ми використовуємо Список публічних суфіксів, щоб розрахувати зареєстрований домен. Перевищення сертифікатів на зареєстрований домен повідомляється через помилкове повідомлення забагато виданих серттифікатів, можливо з додатковими деталями.
Ви можете створити максимум 300 ** нових замовлень** на обліковий запис за 3 години. Нове замовлення створюється щоразу, коли ви надсилаєте запит щодо сертифіката від ЦС Boulder, це означає, що одне нове замовлення генерується в кожному запиті на сертифікат. Перевищення ліміту нових замовлень доповідається повідомленням про помилку забагато нещодавніх нових замовлень.
Ви можете об’єднати декілька імен хостів в один сертифікат, з лімітом до 100 назв на сертифікат. З міркувань продуктивності та надійності, краще використовувати менше імен на сертифікат коли це можливо. Сертифікат з декількома іменами часто називають SAN або іноді UCC-сертифікатом.
Поновлення розглядаються окремо: вони не враховують ваші сертифікати на зареєстрований домен з лімітом, але підлягають дублікатам сертифікатів (/docs/duplicate-certificate-limit) з лімітом 5 на тиждень. Про перевищення ліміту дублікатів сертифікатів буде повідомлено повідомленням про помилку вже видано забагато сертифікатів для точного переліку доменів.
Сертифікат розглядається як оновлення (чи дублікат) попереднього сертифіката, якщо він містить такий же набір імен хостів, ігноруючи капіталізацію та порядок імен хостів. Наприклад, якщо ви запросили сертифікат для імен [www.example.com, example.com], то ви можете запросити ще 4 сертифікати для [www.example.com, example.com] упродовж тижня. Якщо ви змінили набір імен хостів, додавши [blog.example.com], ви можете запросити додаткові сертифікати.
Обробка поновлення ігнорує відкритий ключ і запитувані розширення. Видача сертифіката може вважатися поновленням, навіть якщо ви використовуєте новий ключ.
** Відкликання сертифікатів не скидає ліміт частот**, оскільки ресурси, використані для видачі цих сертифікатів, вже були використані.
There is a!!crwdBlockTags_34_sgaTkcolBdwrc! limit of 5 failures per account, per hostname, per hour. Цей ліміт є вищим на нашому середовищі для тестування, тому ви можете використовувати його для налагодження проблем з підключенням. Перевищення ліміту помилок при перевірці повідомляється повідомленням про помилку
багато невдалих авторизацій за останній час.
Символи “new-nonce”, “new-account”, “new-order” і “revoke-cert” кінцевих точок у ППІ мають **Всі запити **обмеження 20 на секунду. Кінцева точка “/directory” та каталог “/acme” & підкаталоги мають обмеження в 40 запитів на секунду.
Ми маємо ще два обмеження, з якими Ви навряд чи зіткнетеся.
Ви можете створити максимум 10 облікових записів на IP адресу ** за 3 години. Ви можете створити максимум 500 ** облікових записів на діапазон IP в межах IPv6/48 за 3 години. Досягнення ліміту облікових записів трапляється дуже рідко, і ми рекомендуємо великим інтеграторам надавати перевагу дизайну використовуючи один обліковий запис для багатьох клієнтів. Перевищення цих обмежень супроводжується повідомленням про помилку забагато реєстрацій на цей IP або забагато реєстрацій для цього діапазону IP.
На вашому обліковому записі може бути максимум 300 очікуючих авторизацій. Перевищення цього обмеження трапляється рідко, і найчастіше за розробки клієнтів ACME (Середовища автоматичного управління сертифікатами). Як правило, це означає, що ваш клієнт створює авторизації, але не виконує їх. Будь ласка, використовуйте наше середовище для тестувань, якщо Ви розробляєте середовище автоматичного управління сертифікатами клієнта. Перевищення ліміту авторизацій доповідається повідомлення про помилку забагато нещодавніх невдалих авторизацій.
Зміни
Якщо Ви перевищили ліміт, ми не маємо способу, щоб тимчасово скинути його. Вам потрібно буде почекати поки закінчиться термін дії ліміту протягом тижня. Ми використовуємо ковзання віконця, тому якщо Ви випустили 25 сертифікатів у понеділок і ще 25 сертифікатів у п’ятницю, то Ви зможете випускати їх знову в понеділок. Ви можете отримати список сертифікатів, які випущені для Вашого зареєстрованого домену за допомогою searching on crt.sh, який використовує публічні центри сертифікаціїлоги.
Якщо Ви великий хост-провайдер або організація, що працює над інтеграцією Let’s Encrypt, ми маємо форму ліміту яку можна використати, щоб запросити вищий ліміт частот. Обробка запиту займає декілька тижнів, тому ця форма не підходить Вам, якщо Вам просто потрібно скинути ліміт скоріше, ніж він скинеться сам.
Очищення очікуючих авторизацій
Якщо Ви маєте велику кількість очікуваних авторизацій і отримуєте Помилку обмеження кількості очікуваних авторизацій, то Ви маєте змогу спробувати запустити перевірку тих авторизованих об’єктів, вивівши підписані JWS POST до однієї з перешкод, як описано в специфікації середовища автоматичного управління сертифікатами. Очікувані об’єкти авторизації представлені URL-адресою форми https://середовища автоматичного управління сертифікатами-v02.ппі.letsencrypt.org/середовища автоматичного управління сертифікатами/authz/XYZ, та мають з’явитись у журналах Вашого клієнта. Зауважте, що не має значення, чи буде перевірка успішною чи ні. Або винесе авторизацію поза станом “очікування”. Якщо Ви не маєте журналів, які містять відповідні URL-адреси авторизації, то Вам потрібно зачекати до закінчення дії обмеження. Як описано вище, тут є рухомі вікна, тому це може зайняти менше, ніж тиждень, залежно від вашої схеми видачі.
Зауважте, що велика кількість очікуваних авторизацій, зазвичай, є результатом помилки клієнта. Якщо Ви перевищуєте обмеження ліміту, то варто двічі перевіряти код Вашого клієнта.