2020年9月3日（木曜）に、Let's Encrypt は6つの新しい証明書を発行しました。1つのルート証明書、4つの中間証明書、および1つのクロス署名証明書です。これらの新しい証明書は、ECDSAエンドエンティティ証明書を広く利用可能にし、証明書を小さくすることで、Web上のプライバシーを向上させるという私たちのより大きな計画の一部です。

毎日150万枚の証明書を発行していることを考えると、これらの証明書が特別な理由は何でしょうか？なぜこれらを発行したのでしょうか？どのように発行したのでしょうか？これらの疑問に答え、その過程で認証局の考え方と働き方を見ていきましょう。

背景

公開的に信頼されているすべての認証局（Let's Encrypt など）には、さまざまなブラウザやOSベンダー（Mozilla、Googleなど）の信頼されたルートストアに組み込まれている少なくとも1つのルート証明書があります。これにより、ウェブサイトから証明書を受け取ったユーザーは、その証明書がブラウザが信頼する組織によって発行されたことを確認できます。しかし、ルート証明書は、その広範な信頼性と長い有効期間により、対応する秘密鍵を慎重に保護してオフラインで保管する必要があり、そのため常に署名に使用することはできません。そのため、すべての認証局（CA）には、追加の証明書を発行できるがルートではない「中間証明書」がいくつかあり、これらを日常的な発行に使用しています。

過去5年間、Let's Encrypt は1つのルート、つまりISRG Root X1を持っていました。これは4096ビットRSAキーを持ち、2035年まで有効です。

その間、4つの中間証明書がありました。Let's Encrypt Authorities X1、X2、X3、およびX4です。最初の2つは、Let's Encrypt が2015年に運用を開始したときに発行され、5年間有効でした。後者の2つは、約1年後である2016年に発行され、これも5年間有効で、来年頃期限切れになります。これらの中間証明書はすべて2048ビットRSAキーを使用しています。さらに、これらの中間証明書はすべて、別の認証局が管理する別のルート証明書であるIdenTrustのDST Root CA X3によってクロス署名されています。これは、ほとんどのルートストアで信頼されています。

最後に、ISRG Root OCSP X1証明書もあります。これは少し異なります。これは証明書を発行しません。代わりに、中間証明書が失効されていないことを示すオンライン証明書ステータスプロトコル（OCSP）レスポンスに署名します。これは重要です。このようなステートメントに署名できる唯一のものはルート自体であり、前述のように、ルートはオフラインで安全に保護しておく必要があるためです。

Let’s Encrypt’s hierarchy as of August 2020

新しい証明書

まず、R3とR4という2つの新しい2048ビットRSA中間証明書を発行しました。これらはどちらもISRG Root X1によって発行され、5年間の有効期間があります。これらはIdenTrustによってもクロス署名されます。これらは基本的に、1年後に期限切れになる現在のX3およびX4の直接的な代替品です。今年後半に主要な発行パイプラインをR3を使用するように切り替える予定です。これにより、発行や更新に実際の影響はありません。

他の新しい証明書はさらに興味深いです。まず、RSAではなくECDSA P-384キーを持ち、2040年まで有効な新しいISRG Root X2があります。そこから、E1とE2という2つの新しい中間証明書が発行されました。これらもどちらもECDSAであり、5年間有効です。

注目すべきは、これらのECDSA中間証明書はIdenTrustのDST Root CA X3によってクロス署名されていないことです。代わりに、ISRG Root X2自体は既存のISRG Root X1によってクロス署名されています。鋭い観察者であれば、ISRG Root X2からOCSP署名証明書を発行していないことにも気付くでしょう。

Let’s Encrypt’s hierarchy as of September 2020

これで技術的な詳細はさておき、新しい階層がそのように見える理由を詳しく見ていきましょう。

ECDSAルートと中間証明書を発行した理由

ECDSAの利点（同じレベルのセキュリティでキーサイズが小さくなること、それに対応する暗号化、復号化、署名、検証操作の高速化、その他）については、他にも多くの記事があります。しかし、私たちにとって大きな利点は、証明書のサイズが小さくなることです。

https://経由でのリモートドメインへのすべての接続には、TLSハンドシェイクが必要です。すべてのTLSハンドシェイクでは、サーバーがその証明書を提供する必要があります。その証明書の検証には、証明書チェーン（信頼されたルートを除くすべての中間証明書のリスト）も必要であり、通常はサーバーによって提供されます。つまり、すべての接続（広告やトラッキングピクセルが掲載されているページには数十または数百ある可能性があります）で大量の証明書データが転送されます。そして、すべての証明書には、独自の公開キーと発行者によって提供された署名が含まれています。

2048ビットRSA公開キーの長さは約256バイトですが、ECDSA P-384公開キーは約48バイトです。同様に、RSA署名はさらに256バイトになりますが、ECDSA署名はわずか96バイトです。追加のオーバーヘッドを考慮すると、証明書あたり約400バイトの節約になります。チェーン内の証明書の数の何倍にもなり、1日に受信する接続数によって、帯域幅の節約は急速に増加します。

これらの節約は、帯域幅が毎月重要なコストとなる可能性のあるサイトである購読者と、接続が制限されているか、または課金されているエンドユーザーの両方にとって、公共の利益となります。Web全体にプライバシーをもたらすことは、証明書を利用可能にするだけでなく、効率的にすることも意味します。

余談ですが、証明書のサイズを懸念しているため、新しい証明書でバイト数を節約するために、いくつかの対策も講じています。主題の共通名「Let's Encrypt Authority X3」を「R3」に短縮し、以前に冗長だった組織名フィールドを使用して「Let's Encrypt」という単語を供給しています。権限情報アクセス発行者とCRL配布ポイントのURLを短縮し、CPSとOCSPのURLは完全に削除しました。これらすべてを合わせると、証明書内の有用な情報を本質的に変更することなく、さらに約120バイトの節約になります。

ECDSAルートをクロス署名した理由

クロス署名は重要なステップであり、新しいルート証明書が発行されてから、そのルートがさまざまな信頼ストアに組み込まれるまでのギャップを埋めます。新しいISRG Root X2が広く信頼されるまでには約5年かかるとわかっているので、E1中間証明書によって発行された証明書を信頼するには、チェーンのどこかにクロス署名が必要です。

基本的には2つの選択肢がありました。既存のISRG Root X1から新しいISRG Root X2にクロス署名するか、ISRG Root X1から新しいE1とE2の中間証明書にクロス署名するかです。それぞれの長所と短所を調べてみましょう。

新しいISRG Root X2証明書にクロス署名するということは、ユーザーの信頼ストアにISRG Root X2が含まれている場合、完全な証明書チェーンは100％ECDSAになり、上記のように検証が高速化されることを意味します。そして、今後数年間でISRG Root X2がますます多くの信頼ストアに組み込まれるにつれて、ユーザーやウェブサイトが何も変更しなくても、ECDSAエンドエンティティ証明書の検証が高速化されます。ただし、トレードオフは、X2が信頼ストアに含まれていない限り、ユーザーエージェントは2つの中間証明書（X1ルートにチェーンされるE1とX2の両方）を検証する必要があることです。これにより、証明書の検証時間が長くなります。

中間証明書に直接クロス署名する場合、トレードオフは逆になります。一方では、すべてのチェーンの長さが同じになり、購読者証明書と広く信頼されているISRG Root X1の間に中間証明書が1つだけになります。しかし、もう一方では、ISRG Root X2が広く信頼されるようになった場合、別のチェーンの切り替えを行う必要があり、誰でも全ECDSAチェーンの利点を獲得できます。

最終的に、全ECDSAチェーンのオプションを提供することがより重要であると判断し、最初のオプションを選択して、ISRG Root X2自体にクロス署名することにしました。

OCSPレスポンダを発行しなかった理由

オンライン証明書ステータスプロトコルは、ユーザーエージェントがリアルタイムで、検証している証明書が失効されているかどうかを検出する方法です。ブラウザが証明書の有効性を確認したいときは、証明書自体に含まれているURLにアクセスして、はいまたはいいえの応答を取得するだけで済みます。これは、別の証明書によって署名され、同様に検証できます。これはエンドエンティティ証明書にとって非常に優れており、応答は小さく高速であり、特定のユーザーは、訪問するサイトに応じて、非常に異なる証明書の有効性について気にし（したがってフェッチする必要がある）可能性があるためです。

しかし、中間証明書は野生のすべての証明書のごく一部であり、一般的によく知られており、めったに失効されません。このため、すべてのよく知られた中間証明書の有効性情報を含む証明書失効リスト（CRL）を単に維持する方がはるかに効率的です。すべての中間証明書には、ブラウザがCRLを取得できるURLが含まれており、実際、一部のブラウザはこれらを独自のCRLに集約し、各アップデートで配布しています。つまり、中間証明書の失効状況をチェックするために、サイトをロードする前に追加のネットワークラウンドトリップを行う必要がなくなり、すべての人にとってより良いエクスペリエンスになります。

実際、CAを管理する基本要件への最近の変更（投票SC31）により、中間証明書にOCSP URLを含める必要がなくなりました。CRLによってのみ失効状態を処理できるようになりました。上記のように、新しい中間証明書からOCSP URLを削除しました。その結果、ISRG Root X2によって署名されたOCSPレスポンダを発行する必要がなくなりました。

全てをまとめる

新しい証明書がどのように見えるようになったかを共有したので、最後に一つだけ言及したいことがあります。それは、私たちが実際にそれらを発行する際にどのように行ったかです。

新しいルート証明書と中間証明書の作成は、その内容は厳しく規制されており、秘密鍵を非常に慎重に保護する必要があるため、非常に重要です。そのため、新しい証明書を発行する行為は「セレモニー」と呼ばれています。Let's Encryptは自動化を強く信じていますので、セレモニーでは可能な限り人間の関与を少なくしたいと考えていました。

ここ数ヶ月で、適切な設定があれば、必要なすべてのキー、証明書、および相互署名のリクエストを生成できるセレモニーツールを構築しました。また、設定ファイルの内容を示し、誰でも自分で実行して結果の出力を調べることができる、セレモニーのデモも構築しました。当社のSREは、ハードウェアセキュリティモジュールを備えたレプリカネットワークを構築し、セレモニーを複数回練習して、問題なく動作することを確認しました。このデモを技術諮問委員会、コミュニティ、およびさまざまなメーリングリストと共有し、その過程で貴重なフィードバックを受け、実際には上記のいくつかの決定に影響を与えました！最後に、9月3日、当社のエグゼクティブディレクターは安全なデータセンターでSREと会い、セレモニー全体を実行し、将来の監査のために記録しました。

そして今、セレモニーは完了しました。私たちは証明書ページを更新して、新しい証明書に関する詳細を含め、新しいルートをさまざまな信頼ストアに組み込むよう要求するプロセスを開始しています。今後数週間で新しい中間証明書を使用して発行を開始する予定であり、そうした場合はコミュニティフォーラムでさらに発表します。

これが階層に関する興味深く有益なツアーになっていることを願っており、一度に一つの証明書でインターネットを改善し続けることを楽しみにしています。ウェブのセキュリティをより良く変えるという私たちのビジョンに対する、IdenTrustの早期からの継続的なサポートに感謝します。

サービスを提供するために、ユーザーとサポーターのコミュニティからの貢献に依存しています。貴社の組織がLet's Encryptをスポンサーしたい場合は、sponsor@letsencrypt.orgまでメールでお問い合わせください。可能であれば個人からの寄付をお願いします。