CDN:HTTPS トラブルシューティングガイド

CDN コンソールでカスタム SSL 証明書をアップロードする際に、複数のエラーが発生する可能性があります。一般的なエラーの種類と解決策は次のとおりです。

• 無効な証明書形式：CDN は PEM 形式の証明書のみをサポートしています。証明書の内容が -----BEGIN CERTIFICATE----- で始まり、-----END CERTIFICATE----- で終わることを確認してください。各行は通常 64 文字です。証明書が DER、P7B、または PFX 形式の場合は、まず PEM 形式に変換してください。

• 無効な秘密鍵形式：秘密鍵ファイルのヘッダーは鍵アルゴリズムと一致する必要があります。RSA 鍵の場合は -----BEGIN RSA PRIVATE KEY----- (PKCS#1 形式)、ECC/SM2 鍵の場合は -----BEGIN EC PRIVATE KEY----- です。秘密鍵が -----BEGIN PRIVATE KEY----- (PKCS#8 形式) で始まる場合は、アップロード前に変換してください。RSA 鍵の場合は openssl rsa -in old_server_key.pem -out new_server_key.pem を実行し、ECC/SM2 鍵の場合は openssl ec -in old_server_key.pem -out new_server_key.pem を実行します。また、秘密鍵はパスワードで保護されていてはいけません。パスワード保護を削除する方法については、「秘密鍵ファイルからパスワード保護を削除する」をご参照ください。

  説明

  SM2 (中国国家暗号) 鍵に対して前述の openssl ec コマンドを実行するには、SM2 アルゴリズムサポートでコンパイルされた OpenSSL 1.1.1 以降 (SM2 は 1.1.1 で導入されました) を使用する必要があります。それ以外の場合、コマンドは直接エラーを報告し、秘密鍵ファイル自体が原因であると誤解される可能性があります。

  お使いの OpenSSL が SM2 をサポートしていない場合は、Alibaba Cloud Certificate Management Service が提供する SM2 証明書ツールを使用するか、証明書をコンソールで直接ホストすることを推奨します。

• 証明書と秘密鍵の不一致：アップロードされた証明書と秘密鍵はペアである必要があります。RSA 鍵の場合、次のコマンドを実行してモジュラス値が同一かどうかを比較します。

  openssl x509 -noout -modulus -in your_cert.pem | openssl md5
  openssl rsa -noout -modulus -in your_key.pem | openssl md5

  ECC/SM2 鍵にはモジュラスがありません。代わりに公開鍵を比較します。次のコマンドをそれぞれ実行します。出力が同一であれば、証明書と秘密鍵は一致しています。

  openssl x509 -pubkey -noout -in your_cert.pem
  openssl ec -pubout -in your_key.pem

  鍵の種類が不明な場合は、RSA と ECC の両方に適用される次の一般的な方法を使用します。2 つの出力行の MD5 値が同一であれば、証明書と秘密鍵は一致しています。

  openssl x509 -pubkey -noout -in your_cert.pem | openssl md5
  openssl pkey -pubout -in your_key.pem | openssl md5

• 証明書ドメイン名の不一致：証明書の CN または SAN には高速化ドメイン名が含まれている必要があります。確認コマンド： openssl x509 -in cert.pem -noout -text | grep -E -A1 "Subject:|Subject Alternative Name"

• 証明書または秘密鍵が長すぎる：コンソールはアップロードされるコンテンツの長さに制限を課しています。次の点を確認してください。証明書チェーンに余分な空白行、不可視文字、または BOM ヘッダーが含まれていないか (テキストエディタで不可視文字を表示して削除してください)、ルート CA 証明書が誤って証明書チェーンに貼り付けられていないか (サーバー証明書と中間証明書のみをアップロードしてください)、秘密鍵が証明書フィールドに貼り付けられていないか (またはその逆)。

• 証明書の有効期限切れ：openssl x509 -in your_cert.pem -noout -dates を実行して、証明書の有効期間を確認します。

具体的な形式要件と変換方法については、「証明書形式」をご参照ください。

秘密鍵がパスワードで保護されている場合、アップロード時に無効な秘密鍵形式エラーが報告されます。まずパスワード保護を削除する必要があります。

1. 秘密鍵がパスワードで保護されているかどうかの確認

   RSA で暗号化された秘密鍵の場合、OpenSSL を使用して次のコマンドを実行します。Enter pass phrase for <encrypted private key file>: というプロンプトが表示された場合、鍵は暗号化されています。秘密鍵情報が直接表示される場合、鍵は暗号化されていません。エラーが報告される場合、秘密鍵は RSA で暗号化されたファイルではありません。

   openssl rsa -in <encrypted private key file> -text -noout

   ECC/SM2 で暗号化された秘密鍵の場合、次のコマンドを実行して確認します。

   openssl ec -in <encrypted private key file> -text -noout

2. 秘密鍵の復号化

   証明書の暗号化アルゴリズムが RSA の場合、次のコマンドを実行して秘密鍵を復号化します。

   openssl rsa -in <encrypted private key file> -passin pass:<private key password> -out <decrypted private key file>

   証明書の暗号化アルゴリズムが ECC または SM2 の場合、次のコマンドを実行して秘密鍵を復号化します。

   openssl ec -in <encrypted private key file> -passin pass:<private key password> -out <decrypted private key file>

考えられる原因と解決策は次のとおりです。

1. ワイルドカード証明書が他の CDN ドメイン名にデプロイされている：ワイルドカード証明書が他の CDN ドメイン名にデプロイされた後、新しいドメイン名が同じ証明書を再利用する必要がある場合、デフォルトの証明書リストから証明書を直接選択することはできません。CDN コンソールのカスタムアップロード方法を使用してデプロイする必要があります。その後、Certificate Management Service コンソールの証明書デプロイ機能を使用できます。

2. 証明書にバインドされているドメイン名が高速化ドメイン名と異なる：証明書にバインドされているドメイン名が現在の CDN 高速化ドメイン名と一致しているかどうかを確認してください。2つのケースの違いに注意してください。単一ドメイン証明書 (example.com のみにバインドされているものなど) は、サブドメイン image.example.com には使用できません。そのサブドメインの証明書を別途申請する必要があります。一方、ワイルドカード証明書 (*.example.com など) は、同じレベルのすべてのサブドメイン (image.example.com や api.example.com など) と一致します。

3. アカウントの不一致：証明書と CDN ドメイン名が同じ Alibaba Cloud アカウントに属していることを確認してください。

4. 無料証明書に www プレフィックスが含まれていない：無料 SSL 証明書を申請する際、www プレフィックスは自動的に追加されません。完全なドメイン名を手動で入力して申請する必要があります。

5. ドメイン名形式により自動マッチングができない：ドメイン名形式 (ルートドメインとサブドメインなど) により自動マッチングが失敗する場合は、Certificate Management Service コンソールでデプロイタスクを作成して証明書を CDN にデプロイするか、証明書ファイルをダウンロードしてカスタムアップロード方法を使用して設定することを推奨します。

証明書がリソースリストに表示されない場合は、次の順序でトラブルシューティングを行ってください。

1. ドメイン名が CDN に追加されていることを確認してください。CDN コンソールにログオンし、[ドメイン名] ページに移動して、対象のドメイン名がリストにあるかどうかを確認します。証明書サービスの関連ドメイン名リストには、CDN に追加されたドメイン名のみが表示されます。新しいドメイン名が追加されていない場合、リストは空です。

2. 証明書にバインドされているドメイン名が高速化ドメイン名をカバーしていることを確認してください。ワイルドカード証明書 (*.example.com など) は同じレベルのすべてのサブドメインをカバーしますが、より深いレベルのサブドメイン (a.b.example.com など) や親ドメイン名自体 (example.com など) はカバーしません。証明書にバインドされているドメイン名が高速化ドメイン名と一致しない場合、証明書は選択可能なリストに表示されません。

3. 順序どおりに操作を実行してください。まず CDN コンソールでドメイン名の HTTPS 証明書を設定します (既存の証明書を選択するか、カスタム証明書をアップロードします)。これが完了した後、証明書コンソールのクラウド製品デプロイ機能を使用して後続の管理を実行してください。証明書コンソールのクラウド製品デプロイ機能は CDN コンソール側の設定に依存するため、まず CDN コンソールでの証明書設定を完了する必要があります。

HTTPS 証明書を設定する具体的な操作については、「HTTPS証明書の設定」をご参照ください。

[カスタム証明書 (証明書 + プライベートキー)] タイプの証明書をアップロードする際に、システムが証明書が重複していると報告する場合、同じ証明書コンテンツがシステムに既に存在しています。たとえば、以前に別のドメイン名に対して同じ証明書がアップロードされている可能性があります。解決策は次のとおりです。

• 既存の証明書を再利用する (推奨)：再度アップロードする必要はありません。CDN コンソールの HTTPS 設定ページで、証明書ソースを 既存の証明書 に切り替え、リストで証明書を検索して選択し、直接デプロイします。

• 再アップロードが本当に必要な場合：証明書名を変更して、再度アップロードしてください。

現象：高速化ドメイン名にワイルドカード証明書をアップロードした後、第 3 レベル以上のドメイン名にアクセスする際にブラウザが証明書エラーを報告します。

考えられる原因：HTTPS 証明書ドメイン名マッチング仕様 (RFC 6125) によると、ワイルドカード証明書は、ワイルドカードが存在するレベルの次のレベルのドメイン名のみと一致します。たとえば、*.abc.com 証明書は a.abc.com および b.abc.com と一致しますが、親ドメイン名 abc.com や第 3 レベルのドメイン名 x.a.abc.com とは一致しません。

解決策：

• より深いレベルのドメイン名については、対応するレベルのワイルドカード証明書を申請してください。たとえば、1.cdn.abc.com や 2.cdn.abc.com などの第 3 レベルのドメイン名を高速化する必要がある場合は、*.cdn.abc.com ワイルドカード証明書を使用します。

• 親ドメイン名 abc.com もカバーする必要がある場合は、親ドメイン名の証明書を別途申請するか、abc.com と *.abc.com の両方を含む SAN (Subject Alternative Name) 証明書を使用してください。

現象：CDN コンソールでドメイン名の無料証明書を設定する際に、システムが「ドメイン名が Alibaba Cloud CDN にあるかどうかを確認してください」というメッセージを表示し、設定を続行できません。

原因：無料証明書を設定するには、CDN 高速化ドメイン名が CNAME 値に正しく解決されている必要があります。ドメイン名が CDN によって割り当てられた CNAME に正しく解決されていない場合、システムはドメイン名が Alibaba Cloud CDN にあることを検出できず、このエラーを報告します。

1. DNS サービスプロバイダーのコンソールにログオンし、高速化ドメイン名の DNS レコードを確認し、CDN によって割り当てられた CNAME 値に正しく解決されていることを確認します。

2. DNS 解決が有効になるまでには時間がかかります。解決が正しいことを確認した後、CDN コンソールで無料証明書の設定を再度試してください。

3. ドメイン名が正しく解決されているにもかかわらずエラーが続く場合は、dig や nslookup などのツールを使用して解決が有効になったことを確認し、ブラウザキャッシュをクリアして再度試してください。

DCDN (Dynamic Route for CDN) ドメイン名の無料証明書を設定する際に同じメッセージが表示される場合、解決策は同じです。

ERR_SSL_PROTOCOL_ERROR は通常、CDN ノードで SSL 証明書が正しく設定されていない、または証明書が無効であることを示しています。次の手順でトラブルシューティングを実行してください。

1. CDN コンソールで HTTPS 設定を確認します。証明書がアップロードされ、有効化されていること、および証明書が正常な状態 (期限切れではない) であることを確認してください。

2. カスタム証明書を使用する場合は、証明書形式が正しい (PEM 形式) こと、および秘密鍵がパスワードで保護されていないことを確認してください。

3. 証明書が秘密鍵と一致し、証明書にバインドされているドメイン名が高速化ドメイン名と一致していることを確認してください。

4. 次のコマンドを実行して、CDN ノードによって実際に返される証明書が正しいかどうかを確認してください。

   openssl s_client -connect <accelerated domain name>:443 -servername <accelerated domain name> < /dev/null 2>/dev/null | openssl x509 -noout -subject -dates

5. 以前に HTTPS 証明書を設定していない場合は、まず CDN コンソールで設定してください。設定が完了するまでは、HTTP 経由でドメイン名に一時的にアクセスできます (URL から「s」を削除します)。

現象：ブラウザが ERR_SSL_VERSION_OR_CIPHER_MISMATCH (Chrome) または SSL_ERROR_NO_CIPHER_OVERLAP (Firefox) を報告し、接続が直接ブロックされます。これらは、同じ種類のネゴシエーション失敗に対し、2つのブラウザがそれぞれ異なるエラーメッセージを報告するものです。

考えられる原因：クライアントと CDN ノードが相互にサポートされる TLS プロトコルバージョンまたは暗号スイートをネゴシエートできない場合、ブラウザは接続を直接ブロックします。この種のエラーは TLS プロトコルレイヤーの問題であり、証明書リスク警告として表示されません。証明書信頼チェーンの問題としてトラブルシューティングしないでください。証明書が正しく設定されていることを前提として、このエラーは証明書の有効性とは無関係です (証明書が完全に正しい場合でも発生する可能性があります)。ただし、CDN 側で証明書がまったく設定されていない場合、証明書に依存するすべての暗号スイートも使用できなくなり、同じエラーが発生します。したがって、まず証明書が設定されていることを確認してください。

トラブルシューティング手順：

1. 証明書が設定されていることを確認する：CDN コンソールで HTTPS 証明書のステータスを確認し、証明書が設定されていない可能性がないか確認します。

2. クライアントがサポートする TLS プロトコルバージョンおよび暗号スイートを確認する：古いクライアントは、TLSv1.0 などの初期のプロトコルバージョンまたはレガシー暗号スイートのみをサポートしている可能性があります。

3. CDN 側で有効化されている TLS バージョンおよび暗号スイートを確認する：クライアント機能と重複していることを確認してください。Alibaba Cloud CDN コンソールは、TLSv1.0、TLSv1.1、TLSv1.2、および TLSv1.3 の設定をサポートしています。TLSv1.2 および TLSv1.3 を有効化することを推奨します。暗号スイートについては、AES-128-GCM や AES-256-GCM などの AEAD 暗号化アルゴリズムを使用するスイートを推奨します。鍵交換メカニズムとして ECDHE_RSA または ECDHE_ECDSA (ECC 証明書とペアリング) を使用してください。暗号化強度の低いレガシー暗号スイートは避けてください。設定方法については、「TLSバージョンおよび暗号スイートの設定」をご参照ください。

4. レガシークライアントとの互換性を維持する：ビジネスで初期のプロトコルバージョンのみをサポートするレガシークライアントをサポートする必要がある場合は、CDN 側で対応する初期のプロトコルバージョンを一時的に有効化できます。初期のプロトコルバージョンはセキュリティリスクをもたらすため、移行ソリューションとしてのみ推奨されます。できるだけ早くクライアントをアップグレードしてください。

1. 証明書が正しくデプロイされていることを確認する：CDN コンソールにログオンし、HTTPS 設定で新しい証明書が選択されている、または新しい証明書コンテンツがアップロードされていることを確認します。

2. ドメイン名の一致を確認する：証明書にバインドされているドメイン名が CDN 高速化ドメイン名と正確に一致していることを確認してください (www プレフィックスを含む)。

3. 変更が有効になるのを待ち、ローカルキャッシュをクリアする：新しい証明書をすべての CDN ノードにデプロイするには時間がかかります (通常 1〜10 分)。待ってから再度テストしてください。証明書の配信は CDN リソースのキャッシングとは無関係です。ブラウザキャッシュをクリアするか、シークレットブラウザウィンドウを使用して確認してください。

4. コマンドラインを使用してノード上の証明書を確認する：ブラウザキャッシュによる影響を避け、CDN ノードに現在デプロイされている証明書を直接表示します。

   curl -vI https://<accelerated domain name> 2>&1 | grep -E "subject:|expire date:|issuer:"

5. オリジンサーバー上の証明書の更新は自動的に同期されない：オリジンサーバー上の証明書が更新された場合、CDN 側は自動的に同期されません。CDN コンソールで証明書を手動で更新する必要があります。

CDN コンソールでドメイン名の HTTPS 証明書が設定されているが、ブラウザを使用してウェブサイトにアクセスする際に証明書リスク警告が表示される場合の考えられる原因と解決策は次のとおりです。

• 原因1：証明書チェーンが不完全

  証明書がアップロードされた際に、完全な中間証明書チェーンが含まれていませんでした。一部のデバイス (特に iOS デバイスおよび一部の Android デバイス) は証明書チェーンの完全性に対する要件が厳しく、リスク警告を直接表示します。オンラインツール (myssl.com など) を使用して証明書チェーンの完全性を確認し、中間証明書を補完して、証明書を再度アップロードすることを推奨します。コマンドラインを使用して確認することもできます。

  openssl s_client -connect <accelerated domain name>:443 -servername <accelerated domain name> < /dev/null 2>&1 | grep -i "verify"

  出力に verify error または unable to get local issuer certificate が含まれている場合、証明書チェーンは不完全です。

• 原因2：証明書の有効期限が切れている

  証明書を更新する必要があります。更新が成功したら、CDN コンソールで証明書を速やかに更新してください。証明書を更新する方法については、「HTTPS証明書の設定」をご参照ください。

• 原因3：自己署名 HTTPS 証明書が使用されている

  CA によって発行されたものではなく、自分で生成した証明書は自己署名証明書と呼ばれます。自己署名証明書はブラウザの信頼されたルート証明書リストにはなく、偽造や中間者攻撃に対して脆弱であるため、リスク警告が表示されます。この問題は証明書チェーンを補完しても解決しません。信頼された CA によって発行された HTTPS 証明書に置き換えることを推奨します。

• 原因4：ウェブページに HTTP リソースが含まれている (混合コンテンツ)

  ウェブページが HTTP 経由でリソース (画像、JS、CSS ファイルなど) を読み込む場合、ブラウザは混合コンテンツ警告を表示します。最新のブラウザは、スクリプトや iframe などの HTTP 経由で読み込まれるアクティブな混合コンテンツをデフォルトでブロックし、画像などのパッシブコンテンツに対してのみ警告を表示します。解決策：ページ上の HTTP リソースリンクを HTTPS に変更するか、プロトコル相対 URL (//domain/path) を使用してください。

• 原因5：システム時刻が正しくない

  コンピュータのシステム時刻が正しいかどうかを確認してください。システム時刻が正しくないと、ブラウザは証明書が期限切れまたはまだ有効でないと判断し、証明書リスク警告が表示されます。システム時刻を修正して、ウェブサイトを再度閲覧してください。

• 原因6：HSTS キャッシュにより HTTP へのフォールバックが防止される

  ウェブサイトが以前に HSTS (HTTP Strict Transport Security) レスポンスヘッダーを設定していた場合、ブラウザは指定された期間内に HTTPS アクセスを強制します。この時点で証明書の有効期限が切れる、または削除されると、ブラウザは「とにかく続行する」オプションを提供せずに、アクセスを直接ブロックします。解決策：できるだけ早く証明書の問題を修正してください。ローカル HSTS キャッシュを一時的にクリアする必要がある場合、Chrome では chrome://net-internals/#hsts にアクセスして、対応するドメイン名の HSTS レコードを削除できます。HSTS を設定する方法については、「HSTSの設定」をご参照ください。

現象：高速化ドメイン名に HTTPS 証明書が設定され、直接の HTTPS アクセスは正常です。ただし、HTTP アクセスは HTTPS にリダイレクトされず、コンテンツは HTTP 経由で返されます。

原因：HTTPS 証明書を設定すると、CDN ノードが HTTPS リクエストを処理できるようになるだけです。HTTP リクエストの処理方法は変更されません。HTTP から HTTPS へのリダイレクトは、プロトコルリダイレクトを使用して個別に設定する必要があります。

解決策：

1. CDN コンソールで高速化ドメイン名のプロトコルリダイレクトを有効化し、HTTP から HTTPS への強制リダイレクトモードを選択します。設定方法については、「HTTP/Sリダイレクトの設定」をご参照ください。

2. 設定が有効になった後、ブラウザキャッシュをクリアして再度テストしてください。次のコマンドを実行します。通常、301 または 302 ステータスコードが返され、Location レスポンスヘッダーは https で始まるアドレスになります。

   curl -I http://<accelerated domain name>

現象：ほとんどのデバイスは HTTPS 経由で高速化されたドメイン名に問題なくアクセスできますが、一部の古いクライアントまたは特定の設定のクライアントはアクセスできない、または証明書の検証が失敗します。

原因：CDN は HTTPS リクエストを処理する際に Server Name Indication (SNI) に依存しています。SNI は TLS プロトコルの拡張機能であり、クライアントが HTTPS 接続リクエストを開始する際にアクセスしたいホスト名を指定できるようにします。一部の古いクライアントまたは特定の設定のクライアント (メンテナンスが終了したレガシーオペレーティングシステムや年数が経過したクライアント TLS ライブラリ、および一部の IoT デバイスなど) は SNI をサポートしていない、または HTTPS リクエストを開始する際に SNI 情報を送信しない可能性があります。この場合、CDN ノードはクライアントがアクセスしたい正確なサイトを判断できず、したがって正しい SSL/TLS 証明書を提供できないため、HTTPS 接続が失敗します。

まず問題の種類を特定する：すべてのデバイスおよびすべてのブラウザで HTTPS アクセスまたは証明書の検証が失敗する場合、問題は通常証明書チェーンの問題です。以下の「証明書チェーンのトラブルシューティング」に従ってください。特定のレガシーデバイスまたは特定のクライアント (Android の WeChat ミニプログラムなど) でのみ失敗し、他のブラウザからのアクセスは正常な場合、問題は通常 SNI 互換性の問題です。以下の「SNI のトラブルシューティング」に従ってください。

SNI のトラブルシューティング：

1. 失敗範囲を確認する：特定のクライアント (Android の WeChat ミニプログラムなど) でのみ証明書の検証が失敗し、他のブラウザでのテストは正常かどうか。そうであれば、証明書チェーンの問題は基本的に除外できます。引き続き SNI を調査してください。

2. クライアントの TLS ハンドシェイクパケットをキャプチャし、クライアントがリクエストを開始する際に SNI 情報を含んでいるかどうかを分析します。SNI が含まれていない場合、CDN ノードはドメイン名の証明書を返すことができません。

3. クライアントとサーバーが証明書を交換する際に、Certificate Unknown エラーに続いてリセットが報告されるかどうかを分析します。これが発生し、リクエストに SNI が含まれていない場合、SNI の互換性の問題であると判断できます。

4. サーバーによって返される証明書がドメイン名の証明書であることを確認し、証明書設定のエラーでないことを確認します。

証明書チェーンのトラブルシューティング (すべてのデバイスが失敗する場合に適用)：

1. 証明書チェーンが完全かどうかを確認してください。証明書をアップロードする際は、サーバー証明書と完全な中間証明書チェーンを含めてください。

2. 中間証明書が正しいかどうかを確認してください。中間証明書が正しくないと、証明書の検証が失敗します。ブラウザの証明書エクスポート機能を使用して中間証明書をエクスポートして比較するか、オンラインツール (myssl.com など) を使用して確認し、チェーンを完成させて再度アップロードしてください。

改善策：

• クライアントシステムをアップグレードする：使用中のオペレーティングシステムとソフトウェアを最新バージョンにアップグレードすることで、SNI のサポートが得られます。

• IoT デバイスのファームウェアを更新する：IoT デバイスの場合、ベンダーが提供する最新のファームウェアアップデートを定期的に確認してインストールしてください。

• 証明書チェーンが完全であることを確認する：証明書をアップロードする際は、完全な中間証明書チェーンが含まれていることを確認し、証明書チェーンが不完全なことによって一部のデバイスで証明書の検証が失敗するのを防いでください。

現象：ローカルネットワーク速度は正常ですが、HTTPS 経由で CDN 高速化ドメイン名にアクセスする際にウェブページの読み込みが遅く (たとえば、プライバシーモードのブラウザでもアクセスが遅い)、アクセス速度が期待よりも大幅に低下しています。

考えられる原因：HTTPS アクセスが遅いのは、通常、TLS プロトコルバージョンのネゴシエーションが原因ではありません (ネゴシエーションの失敗により、接続は直接失敗し、遅くなることはありません)。一般的な原因は次のとおりです。

• OCSP クエリのタイムアウト：クライアントが証明書の失効ステータスを検証する際、CA の OCSP サーバーにリアルタイムでクエリを実行する必要があります。クエリがタイムアウトすると、ページの読み込みが数秒間停止する可能性があります。Alibaba Cloud CDN は OCSP ステープリングをサポートしています。CDN ノードがクライアントに代わって CA から証明書ステータスをクエリしてキャッシュし、TLS ハンドシェイク中に証明書と一緒に配信することで、クライアントからのリアルタイムクエリを回避します。ただし、最初のリクエスト時または OCSP キャッシュの有効期限が切れた後、CDN ノードは CA に再度クエリを実行する必要があり、その間に短い遅延が存在する可能性があります。設定方法については、「OCSPステープリングの設定」をご参照ください。

• 証明書チェーンのサイズが大きい：アップロードされた証明書チェーンに不要なルート証明書が含まれている場合、TLS ハンドシェイクのデータ量が増加します。サーバー証明書と中間証明書のみをアップロードしてください。ルート証明書はクライアントシステムに組み込まれており、含める必要はありません。

• DNS スケジューリングの問題：ドメイン名がクライアントから遠い CDN ノードに解決され、ネットワークレイテンシ自体が高くなっています。これは DNS スケジューリングの問題であり、TLS の問題ではありません。

• 初期の TLS プロトコルバージョン：TLSv1.3 ハンドシェイク (1-RTT) は TLSv1.2 (2-RTT) よりもラウンドトリップが少なくなります。後のプロトコルバージョンを有効化すると、ハンドシェイク時間を短縮できます。

トラブルシューティング手順：

1. 時間のかかるフェーズを特定する：ブラウザ開発者ツールの [ネットワーク] パネルを使用して、HTTPS リクエストの時間分布を確認します。時間が SSL/TLS ハンドシェイクフェーズに集中している場合は、以下の手順を続行してください。ハンドシェイクが速いがコンテンツのダウンロードが遅い場合、問題は TLS の問題ではありません。オリジンフェッチまたはネットワークリンクの観点からトラブルシューティングしてください。

2. OCSP ステープリングを確認する：CDN 側で OCSP ステープリングが有効化されているかどうかを確認してください。有効化されていない場合は、パケットキャプチャと組み合わせて、クライアントがハンドシェイク後に OCSP クエリで待機しているかどうかを確認できます。有効化されると、CDN ノードはハンドシェイク中に証明書ステータスを配信するため、この待機時間がなくなります。

3. 証明書チェーンのサイズを確認する：アップロードされた証明書チェーンにサーバー証明書と中間証明書のみが含まれ、ルート証明書が含まれていないことを確認し、ハンドシェイクデータ量の過剰を回避してください。

4. スケジューリングの問題を除外する：dig または nslookup を使用して、高速化ドメイン名の CNAME 解決結果を確認します。クライアントが遠い CDN ノードにスケジュールされている場合は、ローカル DNS 解決設定を確認するか、Alibaba Cloud に連絡してスケジューリングポリシーを調査してください。

5. プロトコルバージョンを確認する：CDN 側で TLSv1.2 または TLSv1.3 が有効化されていることを確認します。TLSv1.3 ハンドシェイクはラウンドトリップが少なく、通常の状況では無効化することは推奨されません。設定方法については、「TLSバージョンおよび暗号スイートの設定」をご参照ください。

6. 再テストする：調整後、ドメイン名に再度アクセスし、アクセス速度が正常に戻ったことを確認してください。

DCDN (Dynamic Route for CDN) ドメイン名で同じ HTTPS アクセスが遅い問題が発生した場合、トラブルシューティングと解決策は同じです。