crt.sh レート制限 — 実際にわかっていること
crt.sh は公開のレート制限を持ちませんが、スクリプトで叩いたことがある人は必ず当たります。長年のコミュニティ検証で得たコンセンサスと、recon パイプラインを動かし続ける方法を紹介。
わかる範囲の数字
- 1 分間に約 5 リクエスト（送信元 IP あたり、JSON エンドポイント）、長年コミュニティ報告でこの値で一定。
- 429 は返らない。代わりに 502 Bad Gateway、空配列、または長時間ハングするクエリが返る。
- Retry-After なし。バックオフは自前。コミュニティ経験則は 12-15 秒のリクエスト間隔。
- ワイルドカードは重く扱われる。ワイルドカードクエリ（%.example.com）はクエリ予算を多く消費し、制限に早く達する。
- 非対称：HTML インターフェースは応答するが JSON エンドポイントは拒否することがあり、別経路で処理されている。
なぜ制限があるのか
crt.sh は数十億行を単一の PostgreSQL インスタンスでクエリしています。1 クライアントの並行する重いクエリが全体の可用性を壊しかねません。Sectigo は crt.sh を無料公共財として提供しており、レート制限は収益化ではなく可用性維持のためです。
パイプラインを動かし続ける方法
1. 積極的にキャッシュ
CT データは増える一方です。あるドメインの証明書履歴を持っていれば、新規エントリだけが重要。ETag/条件付きリクエストは自分のキャッシュに対して行い、crt.sh には行わない。
2. サブドメインごとのループより、ワイルドカードクエリを優先
%.example.com の 1 回のクエリは個別サブドメイン 200 回より安価です（ワイルドカードの単価は高くても）。
3. 公開クォータがあるサービスを使う
CT Radar は無料枠 1 日 100 検索で、超過時に明示的な 429 + Retry-After ヘッダを返します。Pro 枠は 1 日 10K まで。Censys、Cert Spotter なども公開クォータあり。
4. CT ミラーをセルフホスト
ボリュームが正当化するなら、certspotter（OSS）で CT ログを直接消費し自前で索引化。crt.sh、Censys、CT Radar はすべて内部でこれを行っています — ショートカットはありません。