概要: 過去1年間、Let's Encryptの証明書発行は非常に高速で、通常はリクエストから発行までわずか数秒（つまり、数千分の1時間）しかかかりません。**本番環境（production）**では、ドメイン検証が完了するとほぼ即座に証明書が発行されます（Let's encrypt cert takes long time to issue - Help - Let's Encrypt Community Support）。ステージング環境も同様の速度で動作しますが、非同期処理（証明書の準備が整うまで約1秒間「処理中」ステータスを返す）が使用されることがあります（The problem of getting a certificate from staging mode - Help - Let's Encrypt Community Support）。重要なのは、**チャレンジタイプ（DNS-01対HTTP-01）**の選択は発行時間に大きな影響を与えないということです。クライアントが事前にチャレンジレスポンスを準備している限り、どちらの検証方法も数秒で処理されます。以下に平均発行時間と比較を詳しく説明します：

本番環境（デフォルトCAサーバー）

平均発行時間： 本番環境では、証明書は通常わずか数秒—およそ0.001～0.003時間—で発行されます。実際には、Let's Encryptの証明書は「検証後ほぼ瞬時に発行される」とされています（Let's encrypt cert takes long time to issue - Help - Let's Encrypt Community Support）。つまり、ACMEチャレンジによってドメイン制御を証明すると、CAはほぼすぐに証明書に署名して提供します。
パフォーマンスデータ： Boulder（Let's EncryptのCAソフトウェア）の内部ベンチマークによると、負荷がかかっている状態でも、CSR提出から証明書受領までのエンドツーエンドプロセスは約4秒（約0.0011時間）の範囲内です（Boulder-SA is overwhelmed by 20 certs/sec. Is this normal? - Help - Let's Encrypt Community Support）。この時間の約半分は、必須の証明書透明性（CT）ログ送信（CAが証明書を最終化する前に待機する必要がある）によるものです（Boulder-SA is overwhelmed by 20 certs/sec. Is this normal? - Help - Let's Encrypt Community Support）。しかし、通常の運用では、最適化と並列処理のおかげで、レイテンシーはさらに低く—多くの場合、発行にはわずか1～2秒しかかかりません。
高負荷シナリオ： 非常に高いボリュームでも、本番システムは迅速な発行を維持します。2025年初頭の時点で、Let's Encryptは「高需要下でも応答性を維持」しながら、1時間あたり34万以上の証明書（≈1秒あたり94証明書）を発行しています（Scaling Our Rate Limits to Prepare for a Billion Active Certificates - Let's Encrypt）。つまり、インフラストラクチャーは、毎時何十万もの証明書が発行されていても、各個別リクエストが数秒で処理されるように拡張されています。（以前のデータベース依存のレート制限ではピーク時に若干の遅延が発生していましたが、2024年に導入された新しいレート制限システムにより、発行時間は一貫して低く保たれています（Scaling Our Rate Limits to Prepare for a Billion Active Certificates - Let's Encrypt）。）

ステージング環境

平均発行時間： （テスト用の偽のルート証明書を使用する）ステージング環境は、通常、本番環境と同じくらい速く証明書を発行します—平均で数秒（およそ0.001～0.003時間）の範囲です。通常の状況では、ステージングを使用しても顕著な遅延は感じられないはずです。同じコアBoulder CAソフトウェアを使用するため、処理速度は同等です。
ステージングでの非同期処理： 過去1年間で観察された違いの一つは、Let's Encryptが（テスト手段として）ステージングで非同期注文処理を有効にした一方、本番環境は同期のままだったということです。これにより、ステージングではチャレンジを完了して処理リクエストを送信した後、ACMEサーバーが"status": "processing"と応答し、すぐに証明書を提供しないことがあり、クライアントは短い遅延（多くの場合1秒）後に証明書が発行されるまでポーリングする必要がありました（The problem of getting a certificate from staging mode - Help - Let's Encrypt Community Support）。例えば、2023年7月にユーザーがステージングでは「処理中」ステータス（certificate URLなし）が返されたのに対し、本番環境では証明書URLとともに「有効」が即座に返されるのを目撃しました（The problem of getting a certificate from staging mode - Help - Let's Encrypt Community Support）。クライアントは短い待機後に再試行するだけで、証明書が利用可能になりました。これは、ステージングが非同期処理のトグルにより、平均して約1秒の追加遅延を導入することがあることを示しています。それでも、ステージングでの全体的な発行時間は非常に短く、そのようなケースでも本番環境よりもせいぜい1～2秒長いだけでした。（特筆すべきは、dehydratedやいくつかのクライアントは当初、本番環境が非同期処理を使用していなかったためこれを予期していませんでしたが、遅延はそれでも数秒の範囲であり、ポーリングに関するACMEの仕様に準拠していました（The problem of getting a certificate from staging mode - Help - Let's Encrypt Community Support）（The problem of getting a certificate from staging mode - Help - Let's Encrypt Community Support）。）
全体として： 上記のニュアンスを除けば、ステージングのパフォーマンスは本番環境とほぼ同じです。非同期処理がトリガーされない場合、ステージング証明書は本番環境と同じように瞬時に発行されます。ステージングでの平均発行時間は、典型的なケースでもまだわずか数秒（1分を大幅に下回る）です。

DNS-01対HTTP-01チャレンジ（検証方法）

検証ステップの速度： DNS-01チャレンジとHTTP-01チャレンジのどちらを使用するかの選択は、発行時間にほとんど影響しません。ドメイン検証プロセス自体は両方の方法で非常に迅速—通常、チャレンジレスポンスが準備されていれば、わずか数分の1秒しかかかりません。Let's Encrypt自身の検証レイテンシーに関するデータによると、DNS-01チャレンジのためのDNSルックアップやHTTP-01チャレンジのためのHTTP GETの実行は、通常、数百ミリ秒のレイテンシーしか追加しません（）。実際、複数視点検証システムでは、合計検証時間は「通常プライマリVAによって決定される」（つまり単一の検証リクエストに相当）であり、並行して複数の視点からチェックを行うオーバーヘッドはほぼ無視できる程度です（）。これは、DNS TXTレコードを確認する場合でもHTTPリソースを確認する場合でも、CAは通常同じ短い時間枠内で迅速に制御を検証できることを意味します。
発行時間の比較： 発行のボトルネックはチャレンジの種類ではなく、証明書の署名とCTログ記録（どちらのチャレンジタイプでも同じ）であるため、DNS-01とHTTP-01の全体的な発行速度は実質的に同じです。チャレンジに成功して応答すると、残りのステップ（注文完了と証明書生成）にかかる時間は同じです。例えば、証明書の発行に合計約4秒かかる場合、それは検証にDNS-01を使用しても、HTTP-01を使用しても同じです—その差はせいぜい数十分の1秒程度です。実際には、変動は通常、外部要因（例えば、誰かが手動でDNSを更新する場合のDNS伝播遅延や、Webサーバーへのネットワークレイテンシー）によるもので、CAの処理によるものではありません。理想的な、自動化された条件下では、HTTP-01とDNS-01の両方の検証がほぼ瞬時に完了し、どちらの方法でも数秒以内に証明書が発行されます（Let's encrypt cert takes long time to issue - Help - Let's Encrypt Community Support）（）。

結論

要約すると、Let's Encryptの発行プロセスは非常に高速で、通常は証明書あたりわずか数秒（10^-3時間のオーダー）です。公式コミュニケーションでは、ACMEチャレンジが満たされれば証明書は「ほぼ瞬時に」発行されることが強調されています（Let's encrypt cert takes long time to issue - Help - Let's Encrypt Community Support）。過去1年間、デフォルトの本番環境での平均発行時間は、このわずか数秒の範囲内にとどまっています。ステージング環境もこのパフォーマンスに近く、一部のケースではテスト関連の遅延（約1秒）がわずかに発生するだけです（The problem of getting a certificate from staging mode - Help - Let's Encrypt Community Support）。また、発行速度に関してはDNS-01とHTTP-01チャレンジ方法の間に意味のある違いはありません。どちらの方法でも、CAは本質的に同じ短い時間枠内で検証し、証明書を発行できます。全体として、本番環境を使用してもステージング環境を使用しても、DNS検証を選択してもHTTP検証を選択しても、通常の条件下では証明書発行が平均して0.01時間未満（数秒以内）で完了することを期待できます（Let's encrypt cert takes long time to issue - Help - Let's Encrypt Community Support）（Boulder-SA is overwhelmed by 20 certs/sec. Is this normal? - Help - Let's Encrypt Community Support）。

ソース：

Let's Encryptコミュニティフォーラム – 「Let's Encrypt証明書の発行に時間がかかる」（証明書が通常数秒以内に発行されることの確認）（Let's encrypt cert takes long time to issue - Help - Let's Encrypt Community Support）
Let's Encryptコミュニティフォーラム – Boulderパフォーマンスディスカッション（CSRから証明書発行までが約4秒、そのうち半分がCTログ処理であることを示すベンチマーク）（Boulder-SA is overwhelmed by 20 certs/sec. Is this normal? - Help - Let's Encrypt Community Support）
Let's Encryptブログ – 「レート制限のスケーリング...」（応答性を維持しながら1時間あたり34万の証明書発行を示す）（Scaling Our Rate Limits to Prepare for a Billion Active Certificates - Let's Encrypt）
Let's Encryptコミュニティフォーラム – ステージング対本番環境の処理応答（ステージングが約1秒の「処理中」遅延を引き起こす非同期発行を使用）（The problem of getting a certificate from staging mode - Help - Let's Encrypt Community Support）
USENIX Security '21 Let's Encrypt複数視点検証に関する論文（検証レイテンシーは低く、複数の視点を使用することによる影響は大きくない）（）