新規投稿のお知らせを受信されたい方は、サブスクリプションをご登録ください:

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

2024-04-12

10分で読了
この投稿はEnglish繁體中文FrançaisDeutsch한국어Español简体中文でも表示されます。

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は着実に独自のデバイス互換性を確保してきました。

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

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を利用することで、常にアプリケーションに最適な設定を選択することができます。

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

Cloudflareは企業ネットワーク全体を保護し、お客様がインターネット規模のアプリケーションを効率的に構築し、あらゆるWebサイトやインターネットアプリケーションを高速化し、DDoS攻撃を退けハッカーの侵入を防ぎゼロトラスト導入を推進できるようお手伝いしています。

ご使用のデバイスから1.1.1.1 にアクセスし、インターネットを高速化し安全性を高めるCloudflareの無料アプリをご利用ください。

より良いインターネットの構築支援という当社の使命について、詳しくはこちらをご覧ください。新たなキャリアの方向性を模索中の方は、当社の求人情報をご覧ください。
セキュリティApplication ServicesTLSSSLCertificate AuthorityDeep Dive

Xでフォロー

Dina Kozlov|@dinasaur_404
Cloudflare|@cloudflare

関連ブログ投稿

2024年10月08日 13:00

Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One

The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. ...

2024年10月06日 23:00

Enhance your website's security with Cloudflare’s free security.txt generator

Introducing Cloudflare’s free security.txt generator, empowering all users to easily create and manage their security.txt files. This feature enhances vulnerability disclosure processes, aligns with industry standards, and is integrated into the dashboard for seamless access. Strengthen your website's security today!...

2024年10月02日 13:00

How Cloudflare auto-mitigated world record 3.8 Tbps DDoS attack

Over the past couple of weeks, Cloudflare's DDoS protection systems have automatically and successfully mitigated multiple hyper-volumetric L3/4 DDoS attacks exceeding 3 billion packets per second (Bpps). Our systems also automatically mitigated multiple attacks exceeding 3 terabits per second (Tbps), with the largest ones exceeding 3.65 Tbps. The scale of these attacks is unprecedented....