Subscribe to receive notifications of new posts:

Cloudflareのお客様がLet's Encryptの証明書チェーンの変更の影響を受けないようにする方法

04/12/2024

10 min read
How we ensure Cloudflare customers aren't affected by Let's Encrypt's certificate chain change

Let's Encryptは、CloudflareがTLS証明書の発行に使用する公的に信頼される認証局CAで、2つの異なる証明書チェーンに依存しています。1つは2000年から存在する世界的に信頼されたCAであるIdenTrustとのクロス署名で、もう1つはLet's EncryptのルートCAであるISRG Root X1です。Let's Encryptの開始以来、ISRG Root X1は着実に独自のデバイス互換性を確保してきました。

2024年9月30日、IdenTrustによってクロス署名されたLet's Encryptの証明書チェーンの有効期限が切れます。クロス署名の有効期限が切れると、それ以降はサーバーはクロス署名チェーンによって署名された証明書を提供できなくなります。その代わり、すべてのLet's Encryptの証明書はISRG Root X1 CAを使用します。

2016年以降にリリースされたほとんどのデバイスとブラウザのトラストストアにはISRG Root X1がインストールされているため、この変更によって問題が発生することはありません。これは、これらの最新のブラウザとオペレーティングシステムが俊敏性と柔軟性を備えているように構築されており、新しい認証局を含めて更新可能なアップグレード可能なトラストストアを備えているためです。

この証明書チェーンの変更による影響は、Androidバージョン7.1.1を実行するデバイスなど、レガシーデバイスやシステムで発生します。これは、2016年リリース以前のバージョンはクロス署名チェーンのみに依存し、トラストストアにISRG X1 rootが存在しないためです。これらのクライアントでLet's Encrypt証明書で保護されたドメインにアクセスすると、TLSエラーや警告が表示されるようになります。当社のAndroidのリクエストを調査したところ、そのうち2.96%が、この変更の影響を受けるデバイスからのものであることがわかりました。これは、相当数のクライアントがインターネットにアクセスできなくなることを示します。当社では、これらのユーザーをオンライン状態に維持することに努め、お客様による手動での変更を必要とせず、古いデバイスのユーザーに引き続きサービスを提供でき方法で証明書パイプラインを変更できるよう検討を進めてまいります。

すべての人により良いインターネット

過去に私たちは、SHA-1ベースのアルゴリズムが廃止されつつある中、クライアントのサポートを継続できるようにするため、「No Browsers left Behind(すべてのブラウザを取り残さない)」のような取り組みに投資してきました。私たちは今後予定されているLet's Encryptの変更についても同じアプローチを適用しています。

CloudflareがCAを指示するすべてのフローから認証局としてのLet's Encryptを削除することを決定しました。これは、Universal SSLのお客様と「デフォルトのCA」の選択でSSL for SaaSを使用するお客様に影響します。

クロス署名チェーンの有効期限が切れる前の証明書ライフサイクル(90日)である2024年6月以降、更新を控えたLet's Encryptの証明書が別のCAを使用するように移行を開始し、変更の影響を受ける古いデバイスとの互換性を確保します。つまり今後は、お客様がLet's EncryptをCAとして明示的にリクエストした場合にのみ、Let's Encryptの証明書を受け取ることになります。

Let's Encryptが行おうとしている変更は必要なものです。新しい標準やプロトコルのサポートを前進するためには、公開鍵基板(PKI)のエコシステムをより俊敏にする必要があります。Let's Encryptはクロス署名チェーンを廃止することで、デバイス、ブラウザー、クライアントが適応性のあるトラストストアをサポートすることを推進しています。

しかし、当社では過去にもこのような変化を観察してきましたが、新しい標準の採用を推し進める一方で、経済的な理由から新技術に手を出すことが困難な地域のユーザーには不公平な影響を与える場合があります。

当社の使命は、より良いインターネットの構築を支援することであり、それは世界中のユーザーをサポートすることを意味します。以前、Let's Encryptの変更に関するブログ記事を掲載し、影響が予想されるお客様については認証局を切り替えるよう推進しました。しかし、この変更による影響の判断は困難です。トラストストアの非互換性によるエラー率は主にクライアント側に記録されるため、ドメイン所有者側で判断することは困難です。さらに、現在は互換性のないデバイスから受信するリクエストがないかもしれませんが、将来的にユーザーが中断なくアクセスできる保証はありません。

Cloudflareの証明書パイプラインは耐障害性と柔軟性を備えて長年にわたって進化してきたため、お客様に負の影響を与えることなく、このような変化にもシームレスに適応することができます。

Cloudflareが堅牢なTLS証明書パイプラインを構築した方法

現在、Cloudflareはお客様に代わって数千万もの証明書を管理しています。当社にとって、成功したパイプラインの基準は以下のとおりです:

  1. お客様がいつでもドメインのTLS証明書を取得できる
  2. CA関連に問題があっても、お客様の証明書取得に影響しない
  3. セキュリティのベストプラクティスと最新の標準が使用されている
  4. 将来の拡張に向けて最適化されている
  5. 幅広いクライアントとデバイスに対応している

毎年、私たちは最高レベルのサービスを維持するために、証明書パイプラインに新しい最適化を導入しています。その方法をご紹介します...

お客様がいつでもドメインのTLS証明書を取得できるようにする

2014年にUniversal SSLが公開されて以来、Cloudflareは当社のネットワークで保護されているすべてのドメインのTLS証明書の発行と提供を担当してきました。簡単に思えるかもしれませんが、ドメインが証明書を受け取るためには、次のような手順を正しく実行しなければなりません:

  1. ドメイン所有者がドメイン制御検証(DCV)を完了する(これは証明書の発行と更新の都度行う必要があります)。
  2. 認証局が証明書を発行するためにドメイン制御検証トークンを検証する。
  3. ドメインに使用できるCAを指定するCAAレコードを確認し、許可された者のみが証明書を発行できるようにする。
  4. 認証局が証明書を発行できる状態にする。

これらの各手順では、ドメイン所有者、CDN、認証局など、複数の関係者間の調整が必要です。Cloudflareはプラットフォームの成功の基準として、制御機能を掌握したいと考えています。そのため、これらの各手順を確実に完了することが私たちの仕事になっています。

私たちはすべての証明書の発行と更新において、お客様の労力が最小限に抑えられるようにしています。証明書を取得するには、ドメイン所有者はドメイン制御検証(DCV)を完了して、自身がドメインの所有者であることを証明する必要があります。証明書の要求を開始すると、CAからDCVが返されます。ドメイン所有者はこれをDNSレコードまたはHTTPトークンに配置する必要があります。DNSプロバイダーとしてCloudflareを使用している場合、Cloudflareがお客様に代わって、CAから返されたTXTトークンをDNSレコードに自動的に配置することでDCVを完了します。または外部のプロバイダーをご利用の場合は、お客様の介入なしに自動更新ができるようCloudflareにDCVの作業を委任するオプションも用意しています。

DCVトークンが発行されると、認証局(CA)によってそれが検証されます。CAは、スプーフィングの試みを防止するために、複数の観点からこの検証を行います。しかし、これらのチェックは複数の国とASN(自律システム)から行われるため、 Cloudflare WAFルールがトリガーされてDCVの審査がブロックされる可能性があります。そのため、私たちはこれらのリクエストがブロックされないよう、CAからのものであることを認識し、DCVが正常に完了するよう、WAFとセキュリティエンジンを更新しました。

一部のお客様は、内部要件やコンプライアンス規制により、特定の認証局(CA)を好む場合があります。ドメイン所有者はDNSに認証局許可(CAA)レコードを作成することでそのドメインに対して証明書発行できるCAを指定し、承認されていないCAがドメインの証明書を発行するのを防止することができます。お客様がいつでも証明書を取得できるようにするため、証明書リクエスト前のCAAレコードの審査を行い、どのCAを使用すべきかを確認します。Cloudflareのパイプラインで利用可能なすべてのCAがCAAレコードでブロックされ、お客様が選択したCAから証明書をアップロードしていない場合、当社はお客様に代わってCAAレコードを追加し、証明書を取得できるようにします。私たちの仕事は、できる限りお客様の希望を優先しますが、それができない場合、障害を防ぐために優先CAからのものでなくても、ドメインに対して利用可能なTLS証明書が常にあるようにすることです。

現在、Cloudflareは公的に信頼される認証局ではないため、高可用性を実現するために、私たちが使用するCAに依存しています。しかし、100%の稼働率は期待値として非現実的です。代わりに、CAが利用できなくなった場合に備えて、パイプラインを準備しておく必要があります。

CA関連に問題があっても、お客様の証明書取得に影響しないようにする

Cloudflareでは、インシデントが発生する前に予防するという意味で、先を見越して考えています。CAが利用できなくなることは珍しくありません。障害のために起こることもありますが、一般的にはCAには保守期間が設けられており、一定期間利用できなくなることが頻繁にあります。

CAの冗長性を確保するのは私たちの仕事です。そのため、私たちは常に複数のCAで証明書を発行できるようにし、常に高い可用性を確保しています。お客様が異なるCAからUniversal SSL証明書を発行していることに気付いた場合、それは私たちが意図的に行っているものです。負荷をCA全体に均等に分散することで単一障害点を回避しています。さらに、遅延とエラー率も監視することで問題を検出した場合には利用可能で高性能な別のCAに自動的に切り替えます。あまり知られていないかもしれませんが、当社のCAの1つは、毎月約4回の定期的な保守期間を定めています。この期間中も当社の自動システムがシームレスに起動し、すべてがスムーズに稼働します。これが非常にうまく機能し、全体が問題なく稼働するため、社内チームに対する問い合わせはありません。

セキュリティのベストプラクティスと最新の標準を使用する  

Cloudflareにとってセキュリティはこれまでも、そして今後も最優先事項であり、お客様のデータと秘密鍵を保護するために最高のセキュリティ基準を維持することが極めて重要です。

過去10年間、CA/ブラウザフォーラムは業界標準として証明書有効期間を5年から90日に短縮することを提唱してきました。この変更により、鍵の安全性が損なわれるリスクを最小限に抑えることができます。証明書を90日ごとに更新することで、秘密鍵はその期間だけ有効となり、悪意のある攻撃者が侵害された情報を利用できる時間が短縮されます。

Cloudflareはこの変更を積極的に推進しており、証明書のデフォルトの有効期間を90日間に設定しています。これにより、一定期間内に確実に鍵のローテーションが行われるようになり、セキュリティ体制が強化されます。また、頻繁に発生する証明書の更新を手間なく実行できるよう、自動化を促進するDCV委任などのツールを開発することになりました。このツールを使用することで、証明書の更新エラーの心配なく、秘密鍵を高頻度でローテーションしたいとお考えのお客様にも、2週間という短い有効期間の証明書を提供できるようになりました。

Cloudflareは常に新しいプロトコルと標準の最前線にいます。新しいプロセスのサポートを開始すると、その採用は急速に拡大することはよく知られています。今月、当社はGoogle Trustサービスから発行された証明書のECDSAのサポートを追加する予定です。ECDSAを使用した場合、より小さな鍵でRSAと同等レベルのセキュリティを得ることができます。鍵サイズが小さいほど、証明書のサイズも小さくなり、TLS接続を確立するために渡されるデータも少なくなり、接続が高速になり、読み込み時間も短縮されます。

将来の拡張に向けて最適化されている

現在、Cloudflareは1日に約100万枚の証明書を発行しています。最近の証明書の有効期間の短縮化に伴い、当社ではパイプラインをより堅牢なものにするための改善を続けています。しかし、たとえ当社のパイプラインが重大な負荷に対処できたとしても、依然として当社と共に拡張できるようにCAに依存する必要があります。当社が新たにCAと統合すると、それらのCAはすべて、瞬時にその最大の消費者の1人になります。CloudflareではCAに高い基準を課し、拡張するためのインフラストラクチャの改善を促しています。これはCloudflareのお客様に対する利益だけでなく、発行量の増加に対応する必要があるCAにとっても利益となり、インターネット全体の利益となります。

そして今回、Let's Encryptのトラストチェーンの短縮により、当社のパイプラインにさらなる改善が加えられることになります。これにより、すべてのデバイスで最適な互換性が確保されます。

旧型·最新を問わず、すべてのクライアントをサポート

今後のLet's Encryptの変更により、レガシーデバイスはLet's Encrypt証明書によって保護されているドメインやアプリケーションにリクエストを行うことができなくなります。当社では、世界のどの地域においても、インターネットアクセスを遮断したくないと考えています。つまり、この変更後も、Cloudflareはお客様に最高のデバイス互換性を提供し続けます。

最近の機能強化により、証明書パイプラインの信頼性やサービス品質に影響を与えることなく、Let's Encryptへの依存度を減らすことができます。私たちは変更の直前の証明書ライフサイクル(90日前)に、影響を受けるデバイスと互換性のある、別のCAを使用するように証明書の移行を開始します。これにより、お客様に何もしていただくことなく、影響を軽減することができます。CAにLet's Encryptを選択したお客様のみが、引き続きLet's Encryptを使用こととなります。

Let's Encryptの今後の変更について

Let's Encryptのクロス署名チェーンは、2024年9月30日に有効期限が切れます。Let's Encryptは2024年6月6日にこのチェーンからの証明書発行を停止する予定ですが、Cloudflareは2024年9月9日まですべてのLet's Encrypt証明書にクロス署名チェーンを提供し続けます。

変更の90日前または証明書のライフサイクルの前までに、Let's Encrypt証明書から別の認証局を利用するように移行を開始します。この変更は、CloudflareがCAの選択を担当するすべての製品に対して行います。つまり、これは、「デフォルトのCA」の選択で「Universal SSL」と「SSL for SaaS」をご利用のお客様に対して自動的に行われます。

CAにLet's Encryptを指定されているお客様には、Let's Encrypt証明書の一覧と、レガシーデバイスからのホスト名に対するリクエストがあるかどうかに関する情報が記載されたメール通知をお届けします。

2024年9月9日以降、CloudflareはISRG Root X1チェーンを使用して、すべてのLet's Encryptの証明書を提供します。使用している証明書製品に基づいて予想されることは次の通りです:

Universal SSL

Universal SSLの場合、Cloudflareがドメインの証明書に使用されるCAを選択します。これにより、お客様に最適な証明書を選択することができます。Universal SSLを使用している場合、この変更に備えるために必要な変更はありません。Cloudflareは今後、より互換性のあるCAを使用するように証明書を自動的に移行します。

Advanced Certificate

Advanced Certificate Managerから使用するCAの指定が可能です。ここでLet's Encryptを選択された場合、お客様が内部要件によりこのCAを指定した可能性や、証明書のピン留めを実装している可能性があるため、当社ではその選択を尊重します。

Let's Encryptから発行されたAdvanced Certificateを使用するドメインがこの変更の影響を受けることが確認された場合、どの証明書がLet's EncryptをCAとして使用しているのか、およびこれらのドメインがリクエストを受信しているかどうかを知らせるメール通知がお客様に届きます。他のプロバイダーを選択した場合は、お客様の責任でCAを別のプロバイダーに変更することになります。

SSL for SaaS

SSL for SaaSでは、お客様には、デフォルトのCAを使用する(Cloudflareが発行機関を選択する)か、使用するCAを指定するか、といった2つの選択肢があります。

CAの選択をCloudflareに委任される場合、デバイス互換性の高いCAが自動的に使用されます。

カスタムホスト名に特定のCAを指定している場合、その選択が尊重されます。SaaSプロバイダーとプラットフォーム宛に、どのカスタムホスト名がレガシーデバイスからリクエストを受けているかをお知らせするメールを送信します。他のプロバイダーを選択した場合は、お客様の責任でCAを別のプロバイダーに変更することになります。

カスタム証明書

Let's Encryptと直接統合し、カスタム証明書を使用してLet's Encrypt証明書をCloudflareにアップロードする場合、バンドル方法として「互換」または「最新」を選択し、2024年9月9日より前に証明書をアップロードすれば、証明書はクロス署名チェーンでバンドルされます。9月9日以降、すべてのLet's Encryptの証明書はISRG Root X1チェーンとバンドルされます。「ユーザー定義」のバンドル方式を使用する場合、常にCloudflareにアップロードされたチェーンが提供されます。この方法でLet's Encryptの証明書をアップロードする場合、CAの有効期限である2024年9月30日以降にアップロードされた証明書に正しい証明書チェーンが含まれていることを確認する必要があります。

また、アプリケーションに接続できるクライアントを制御している場合は、ISRG Root X1を含めるようにトラストストアを更新することをお勧めします。証明書のピン留めを使用している場合は、PINを削除または更新します。通常、証明書の更新またはCAの変更時に問題が発生するため、すべてのお客様に証明書をピン留めすることはお勧めしません。

まとめ

インターネットの標準は継続的に進化と改善が行われます。こうした変化を支え、受け入れると同時に、ユーザーのオンライン状態を維持し、新しいテクノロジーを容易に利用できない地域のインターネットアクセスを維持することも私たちの責任であると痛感しております。Cloudflareを利用することで、常にアプリケーションに最適な設定を選択することができます。

変更に関する詳細については、開発者向けドキュメントを参照してください。

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
Security (JP)Application Services (JP)TLS (JP)SSL (JP)Certificate Authority (JP)Deep Dive (JP)日本語

Follow on X

Dina Kozlov|@dinasaur_404
Cloudflare|@cloudflare

Related posts

May 30, 2024 12:12 PM

CloudflareがBastionZeroの買収によりゼロトラストアクセスをITインフラへ拡張

Zero TrustインフラアクセスプラットフォームのBastionZeroがCloudflareに加わったことを発表でき、嬉しく思います。この買収により、サーバー、Kubernetesクラスタ、データベースなどのインフラへのネイティブアクセス管理機能が備わり、当社のZero Trustネットワークアクセス(ZTNA)のフローが拡張されます...

March 08, 2024 2:05 PM

Log Explorer:サードパーティのストレージを使用せずにセキュリティイベントを監視します

Security AnalyticsとLog Explorerを組み合わせることで、セキュリティチームはCloudflare内でネイティブにセキュリティ攻撃を分析、調査、監視でき、サードパーティのSIEMにログを転送する必要がなくなるため、解決までの時間を短縮し、お客様の総所有コストを削減できます...

March 05, 2024 2:02 PM

セキュリティセンター内の保護されていないアセットを保護:最高情報セキュリティ責任者(CISO)のためのクイックビュー

本日、共通の課題であるインフラストラクチャ全体への包括的な展開を確実に行うために、セキュリティーセンター内に新しい機能セットを導入することを嬉しく思います。セキュリティ体勢を最適化する場所と方法を正確に把握することができます...