最終更新日: | すべてのドキュメントを読む
注意: このページが翻訳された後、英語バージョンのページがアップデートされています。 () 英語で表示する
Let’s Encrypt は、できるだけ多くの人がフェアにサービスを利用できるように、レート制限を設けています。デフォルトの設定で使用する大部分の人にとって、設けている制限は十分高いものになっていると考えています。また、証明書の更新時には、レート制限にほぼ必ず引っかからないようにレート制限を設計しています。そのため、大規模な組織でも、Let’s Encrypt の介入なしに、発行する証明書の数を徐々に増やしていくことができるようになっています。
もしあなたが Let’s Encrypt クライアントの開発やテストを活発に行なっている場合には、本番 API を使用する代わりに、私たちが用意したステージング環境を利用するようにしてください。もしあなたがプロバイダや大規模なウェブサイトとのインテグレーションの作業を行おうとしている場合には、Let’s Encrypt のインテグレーションガイドに目を通してください。
主なレート制限としては、登録ドメインごとの証明書数 (1週間に50個まで) があります。登録ドメインとは、一般に言うと、あなたがドメイン名レジストラから購入したドメインの一部のことです。たとえば、www.example.com の場合、登録ドメインは example.com です。new.blog.example.co.uk の場合、登録ドメインは example.co.uk になります。Let’s Encrypt では、登録ドメインの計算にPublic Suffix List (公開サフィックスリスト) を使用しています。
サブドメインを多数持っている場合は、最大で証明書ごとに 100 ドメイン名まで1つの証明書に統合できます。上記の制限と合わせると、毎週 5,000 個までのユニークなサブドメイン名を含む証明書を発行できることになります。複数のドメイン名を含む証明書は、SAN 証明書と呼ばれることが多く、UCC 証明書と呼ばれることもあります。パフォーマンスと信頼性の理由から、証明書ごとのドメイン名はできるだけ少ない方がよいです。
証明書の更新は特別扱いされ、登録ドメインごとの証明書数の制限にカウントされませんが、1週間に 5 つまでの証明書の発行の複製の制限の対象とはなります。注意: 証明書の更新が登録ドメインごとの証明書数の制限の対象となるのは、2019年3月までです。しかし、2019年3月以降は制限の対象ではなくなります。
発行済の証明書が更新 (または複製) の対象とみなされるのは、全く同じホスト名の集合が指定されているときです (大文字・小文字、順序は区別しない)。たとえば、[www.example.com, example.com] というドメイン名に対する証明書をリクエストした場合、同じ週に [www.example.com, example.com] に対する証明書を重複して発行できるのは、追加で 4 つまでです。しかし、[blog.example.com] というドメインを追加してホスト名の集合が変化したときには、追加でリクエストを発行できます。
更新の処理では、公開鍵とリクエストの拡張は無視されます。新しい鍵を使用していたとしても、証明書の発行は更新とみなされます。
証明書の無効化を行ったとしても、レート制限はリセットされません。その証明書を発行するためのリソースはすでに消費されてしまっているからです。
検証の失敗は、1アカウントごと、1ホスト名ごと、1時間毎に、5回までに制限されています。この制限はステージング環境では緩和されているため、接続の問題をデバッグする場合には、こちらを使ってください。
“new-reg”、“new-authz”、“new-cert” のエンドポイントには、リクエスト全体に対する毎秒 20 回の制限があります。"/directory" と “/acme” ディレクトリおよびサブディレクトリのエンドポイントには、リクエスト全体に毎秒 40 回の制限があります。
その他に、通常はほとんど引っかからない制限が2つあります。
IP アドレスごとのアカウント数の最大は、3時間毎に 10 個までです。また、IPv6 /48 の範囲に含まれる IP レンジごとのアカウント数の最大は、3時間毎に最大 500 個までです。この2つのアカウントに関するレート制限の上限を超えることは極めて稀です。大規模なインテグレータには、多数の顧客を扱うために1つのアカウントを使う設計を採用することをおすすめします。
認証の待機は、アカウントごとに最大で 300 まで可能です。この制限にかかることは稀ですが、ACME クライアントの開発時には頻繁に発生します。というのも、通常クライアントの開発では、認証を作成しても実際に証明書を発行しないからです。そのため、ACME クライアントの開発時には、ステージング環境を使用してください。
ACME v2 API のユーザーは、1アカウントで3時間ごとに新しい命令を最大 300 個まで作成できます。
オーバーライド
レート制限に引っかかった場合、制限を一時的にリセットする方法はありません。レート制限が解消されるまで1週間後まで待つ必要があります。Let’s Encrypt ではスライディング・ウィンドウを使用しているため、たとえば月曜日に 25 個の証明書を発行し、金曜日に 25 個の証明書を発行した場合、次にもう一度証明書を発行できるのは月曜日以降です。登録ドメインに対する発行証明書のリストを取得するには、crt.sh で検索します。ここでは、パブリックな証明書の透明性 (Certificate Transparency; CT) ログを利用しています。
大規模なホスティングプロバイダや Let’s Encrypt のインテグレーションを行っている組織のために、レート制限フォームが用意されており、レート制限の上限を上げるリクエストができます。リクエストの処理には数週間かかるため、単に通常より早くレート制限を解除してほしいというリクエストには利用できません。
ただし、ほとんどのホスティングプロバイダでは、レート制限を上げる必要はありません。発行した独立した登録ドメインの数に制限はないからです。あなたの顧客が登録ドメインに 2,000 個以上のサブドメインを持っていない限り、制限を上げるリクエストは必要ありません。インテグレーションガイドには、さらに詳しいアドバイスがあります。
認証の待機を解消する
もし待機中の認証オブジェクトがたくさんあり、レート制限のエラーが発生するようになってしまった場合、これらの認証オブジェクトに対して検証を行うことができます。そのためには、ACME の仕様に記述されたチャレンジの1つに対して、JWS で署名された POST リクエストを送信します。待機中の認証オブジェクトは、https://acme-v02.api.letsencrypt.org/acme/authz/XYZ の形式の URL で送信され、クライアントのログに記録されているはずです。検証を行うと、成功・失敗に関わらず、認証が「待機」状態から抜けられます。もし関連する認証の URL を含むログが見つからない場合は、レート制限が解消するまで待つ以外に方法はありません。Let’s Encrypt では、スライディング・ウィンドウが使用されているため、発行のパターンによっては 1週間より短い時間で待機状態が解消される可能性があります。
一般に、大量の認証の待機が生じるのは、バグの多いクライアントが原因です。このレート制限が頻繁に起こる場合は、クライアントのコードをダブルチェックした方がいいでしょう。