HTTPS 設定エラー - CDN - Alibaba Cloud ドキュメントセンター

HTTPS (Hypertext Transfer Protocol Secure) は、HTTP 上にセキュアなチャネルを作成し、Alibaba Cloud CDN 経由で送信されるコンテンツをより良く保護します。これにより、クライアントは高速化されたアクセスで、安全かつ効率的に Web サイトを閲覧できます。このトピックでは、HTTPS に関するよくある質問にお答えします。

HTTPS とは

HTTPS (Hypertext Transfer Protocol Secure) は、HTTP 上で送信されるデータを暗号化してセキュリティを確保するためのプロトコルです。HTTP プロトコルはコンテンツを平文で送信し、データ暗号化を提供しません。HTTPS は、Secure Sockets Layer (SSL) または Transport Layer Security (TLS) で HTTP をカプセル化することで、HTTP をセキュアにします。SSL/TLS は HTTPS のセキュリティ基盤を提供します。HTTPS は、ID 認証と暗号化通信を提供するため、決済取引などのセキュリティが重視される Web 通信に不可欠です。Alibaba Cloud CDN で HTTPS を設定する場合、ドメイン名の証明書を提供する必要があります。この証明書はすべての CDN エッジノードにデプロイされ、ネットワーク全体での暗号化データ伝送を可能にします。

一般的な HTTP 攻撃の種類

HTTPS は、包括的なセキュリティ戦略の一部にすぎません。完全なネットワークセキュリティを確保するには、WAF や DDoS 防御などの対策も実装する必要があります。以下は、一般的な HTTP 攻撃の種類です。

SQL インジェクション：攻撃者が、既存のアプリケーションを介してバックエンドのデータベースエンジンに悪意のある SQL コマンドを注入する攻撃です。Web フォームに悪意のある SQL ステートメントを入力することで、攻撃者は脆弱な Web サイトのデータベースを悪用し、意図しないコマンドを強制的に実行させることができます。
クロスサイトスクリプティング (XSS)： XSS は、Web アプリケーションを攻撃するための最も一般的で基本的な手法の 1 つです。攻撃者は、悪意のあるコードを含むデータを Web ページに投稿します。ユーザーがこのページを表示すると、スクリプトがユーザーの ID と権限で実行され、攻撃者はユーザーデータを変更したり、ユーザー情報を盗んだりすることができます。
クロスサイトリクエストフォージェリ (CSRF)： CSRF は、もう 1 つの一般的な攻撃です。攻撃者は、フォームの送信など、ユーザーの操作を模倣したリクエストを偽造して、ユーザーデータを変更したり、特定のタスクを実行したりします。ユーザーになりすますため、CSRF 攻撃は XSS 攻撃と組み合わせて行われることがよくありますが、攻撃を含むリンクをユーザーにクリックさせるなど、他の手段によっても実行される可能性があります。
HTTP ヘッダーインジェクション： HTTP レスポンスでは、2 つの CRLF (0x0D 0A) 文字ペアで構成される空行がヘッダーとコンテンツを区切ります。この空行はヘッダーの終わりとコンテンツの始まりを示します。攻撃者はこれを悪用して、ヘッダーに任意の文字を注入することができます。
リダイレクト攻撃：フィッシングは一般的な攻撃手法です。フィッシング攻撃者は通常、正規に見えるリンクを被害者に送信します。そのリンクにアクセスすると、個人情報をだまし取るために設計された悪意のある Web サイトにリダイレクトされます。これを防ぐには、すべてのリダイレクト操作を監査して、危険な場所へのリダイレクトを回避する必要があります。一般的な解決策は、正規のリダイレクト URL の許可リストを使用し、リストにないドメインへのリダイレクトを拒否することです。もう 1 つの解決策は、正規の URL にリダイレクトトークンを追加し、リダイレクト時にそれを検証することです。

HTTPS が必要なのは Web サイトのログイン時のみか

いいえ。サイト全体で HTTPS を使用する理由として、次の点が挙げられます。

セキュリティ：サイトに HTTP と HTTPS のページが混在している場合、JS や CSS ファイルなどのリソースを HTTP 経由で読み込むと、ユーザー情報が漏洩する可能性があります。サイト全体の HTTPS 化は、このリスクを防ぐ最も簡単な方法です。
パフォーマンス：Web サイトが HTTPS と HTTP の両方を使用している場合、両者を切り替えるには多数のサーバーリダイレクトが必要となり、ページの読み込み時間が遅くなる可能性があります。
互換性：ブラウザは HTTPS のサポートを強化しており、検索エンジンもランキングで HTTPS サイトを優遇します。

HTTPS の設定に必要な証明書

クライアントから CDN エッジノードへのリクエストのみを暗号化する必要がある場合は、CDN のみに SSL/TLS 証明書を設定します。

エンドツーエンドの HTTPS アクセスを設定する必要がある場合は、CDN とオリジンサーバーの両方に HTTPS 証明書を設定する必要があります。詳細については、「HTTPS 高速化とは」をご参照ください。

CDN で HTTPS 高速化を有効にすると追加料金は発生するか

はい。CDN で HTTPS 高速化を有効にすると、クライアントから CDN エッジノードへのリンクがセキュアになります。SSL ハンドシェイクとコンテンツの復号は計算処理を伴い、これにより CDN サーバーの CPU 消費量が増加します。ただし、CDN エッジノードからオリジンサーバーへのリンクは引き続き HTTP を使用するため、オリジンサーバーのリソース消費量は増加しません。

証明書の種類によって追加料金が発生します。Certificate Management Service コンソールにログインして、DV レベルの証明書であるテスト証明書 (無料版) を申請することもできます。高速化ドメイン名ごとに 1 つのテスト証明書を申請できます。この証明書の有効期間は 3 か月で、無料で自動更新できます。HTTPS 証明書を設定すると、CDN はそのドメイン名のすべての HTTPS リクエストに対して課金します。

IP ブラックリスト/ホワイトリストまたは User-Agent ブラックリストが 403/404 を返した場合、HTTPS リクエストは課金されるか

はい。ポリシールールに一致し、403 または 404 ステータスコードを返すリクエストは、正常に処理されたと見なされ、1 回の HTTPS リクエストとして課金されます。レスポンスにはリソースコンテンツが含まれないため、そのトラフィックと課金は最小限です。

オリジンサーバーが既に HTTPS を使用している場合でも、CDN で HTTPS を設定する必要はあるか

はい。HTTPS はクライアントとサーバー間の接続をセキュアにします。CDN を使用する前は、クライアントはオリジンサーバーに直接接続するため、オリジンサーバーで HTTPS が必要です。CDN を追加した後は、クライアントは CDN に接続します。したがって、クライアントと CDN 間の接続をセキュアにするには、CDN で HTTPS 証明書を設定する必要があります。手順については、「HTTPS 証明書の設定」をご参照ください。

HTTPS 高速化を有効にすると、リソース消費量が増加したり、アクセス速度が低下したりするか

オリジンサーバーで HTTPS を有効にすると、HTTP と比較して計算リソースの消費量が増加します。この増加は、主に HTTPS ハンドシェイク中の非対称暗号化と復号によるもので、特に高同時実行環境では顕著になります。対称暗号化と復号は、HTTP とほぼ同じリソースを消費します。したがって、セッション再利用率を高めることが重要です。ただし、HTTPS 経由でオリジンサーバーに直接アクセスすると、HTTP 経由でアクセスするよりも時間がかかります。

エンドツーエンドの HTTPS アクセスに動的アクセラレーションを使用すると、平均 SSL ハンドシェイク時間が短縮されます。高同時実行環境では、オリジンサーバーのセッション再利用率が大幅に向上し、リソース消費量が削減されます。

静的コンテンツの場合：エッジ配信によりハンドシェイク時間は多少増加しますが、伝送時間が短縮されるため、全体的なアクセス時間は短縮されます。静的リソースはオリジンフェッチを必要としないため、オリジンサーバーとのやり取りが減り、リソース消費量が削減されます。
動的コンテンツの場合：動的リクエストは、オリジンサーバーからコンテンツをフェッチする必要があります。動的アクセラレーションを使用すると、パブリックインターネットよりも制御可能で最適なパスが提供されます。これにより、セッション再利用率が向上し、全体的な伝送速度が改善されます。避けられない非対称暗号化によりオリジンサーバーのリソース消費量は増加しますが、動的アクセラレーションはエンドツーエンドの HTTPS アクセスのリソース消費量を最適化します。

HTTPS 証明書の設定方法

CDN コンソールで HTTPS 証明書を設定できます。詳細な手順については、「HTTPS 証明書の設定」をご参照ください。

新しい CDN ドメインに証明書をデプロイする際、リソースリストに既存の証明書が見つからないのはなぜか

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

次のトラブルシューティング手順に従ってください。

ドメイン名が CDN に追加されていることを確認してください。CDN コンソールにログインし、[ドメイン名] ページに移動して、対象のドメイン名がリストにあるかどうかを確認します。Certificate Management Service の関連ドメイン名リストには、CDN に追加されたドメイン名のみが表示されます。新しいドメイン名が追加されていない場合、リストは空になります。
証明書が高速化ドメイン名をカバーしていることを確認してください。ワイルドカード証明書 (例： *.example.com) は、同じレベルのすべてのサブドメインをカバーできます。証明書にバインドされているドメイン名が高速化ドメイン名と一致しない場合、証明書は利用可能なリストに表示されません。
次の順序で操作を実行してください。まず、既存の証明書を選択するか、カスタムアップロードを使用して、CDN コンソールでドメイン名の HTTPS 証明書を設定します。次に、Certificate Management Service コンソールのクラウド製品デプロイを通じて証明書を管理します。Certificate Management Service コンソールのクラウド製品デプロイ機能は、CDN 側の証明書設定に依存します。まず CDN コンソールで証明書の設定を完了する必要があります。
ワイルドカード証明書が他の CDN ドメイン名にデプロイされている場合は、カスタムアップロード方法を使用して新しいドメイン名に再利用できます。または、Certificate Management Service コンソールでデプロイタスクを作成して CDN にデプロイすることもできます。

HTTPS 証明書の設定方法については、「HTTPS 証明書の設定」をご参照ください。

HTTPS 証明書をアップロードする際に重複証明書エラーが表示された場合の対処法

カスタム証明書 (証明書 + プライベートキー) をアップロードする際に、重複証明書エラーが表示された場合は、証明書名を変更して再度アップロードしてください。

サードパーティ CA から複数の .crt ファイルがある場合の証明書のアップロード方法

中間認証局からの証明書ファイルには、複数の証明書が含まれている場合があります。アップロードする前に、サーバー証明書と中間証明書を 1 つのファイルに連結する必要があります。

.pem ファイルをテキストエディタで開き、サーバー証明書の直後に中間証明書の内容を貼り付けます。間に空行を入れないでください。通常、証明書認証局は手順を提供しているので、必ずそのガイドラインをお読みください。

連結された証明書は次のようになります。

HTTPS 証明書の設定時にエラーが発生した場合の対処法

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

証明書形式エラー: CDN は PEM 形式の証明書のみをサポートしています。証明書の内容が -----BEGIN CERTIFICATE----- で始まり、-----END CERTIFICATE----- で終わり、通常 1 行あたり 64 文字であることを確認してください。証明書が DER、P7B、または PFX 形式の場合は、最初に PEM 形式に変換する必要があります。
秘密鍵の形式エラー: 秘密鍵ファイルのヘッダーは -----BEGIN RSA PRIVATE KEY----- である必要があります。秘密鍵の形式エラーが表示された場合は、アップロードする前に変換する必要があります。また、秘密鍵はパスワードで保護できません。
証明書と秘密鍵の不一致: アップロードされた証明書と秘密鍵は、一致している必要があります。RSA 証明書を確認するには、openssl x509 -noout -modulus -in your_cert.pem | openssl md5 と openssl rsa -noout -modulus -in your_key.pem | openssl md5 を実行して、それらのモジュラス値を比較します。
証明書のドメインの不一致: 証明書のコモンネーム (CN) またはサブジェクトの別名 (SAN) には、アクセラレーション対象のドメイン名を含める必要があります。確認するには、次のコマンドを実行します: openssl x509 -in cert.pem -noout -text | grep -A1 "Subject:|Subject Alternative Name"
証明書/キーが長すぎる：証明書チェーンに余分な空行、不可視文字、バイトオーダーマーク (BOM) が含まれていないか、またはルート CA 証明書が誤って含まれていないかを確認してください。
証明書の有効期限切れ: openssl x509 -in your_cert.pem -noout -dates コマンドを使用して、証明書の有効期間を確認します。

特定のフォーマット要件と変換方法については、「証明書のフォーマットと変換」をご参照ください。

オリジンサーバーの証明書を更新した後、CDN の HTTPS 証明書も更新する必要はあるか

いいえ。オリジンサーバーの HTTPS 証明書を更新しても、CDN の HTTPS 証明書には影響しません。CDN の HTTPS 証明書は、有効期限が近づいているか、すでに期限切れの場合にのみ更新する必要があります。手順については、「HTTPS 証明書の設定」をご参照ください。

includeSubdomains オプションを有効にした後、サブドメインでも HSTS を有効にする必要はあるか

いいえ、サブドメインで HSTS を有効にする必要はありません。[Include Subdomains] オプションを有効にすると、HSTS ポリシーはすべてのサブドメインに適用されます。すべてのサブドメインが HTTPS アクセスをサポートしていることを確認してください。そうしないと、アクセスできなくなります。

HTTPS を設定した後もクライアントが HTTP を使用するのはなぜか

クライアントが HTTP と HTTPS のどちらを使用するかは、そのリクエストによって決まります。すべてのクライアントに HTTPS の使用を強制するには、CDN で強制リダイレクトを有効にしてください。手順については、「強制リダイレクトの設定」をご参照ください。

ほとんどのデバイスは HTTPS 高速化ドメインにアクセスできるのに、一部のデバイスがアクセスできないのはなぜか

この問題は通常、CDN が HTTPS リクエストを処理するために Server Name Indication (SNI) に依存しているために発生します。SNI は TLS の拡張機能であり、クライアントが HTTPS 接続を開始する際に接続したいホスト名を指定できるようにします。

ただし、古いバージョンの Android や iOS、Java 6 以前、一部の IoT デバイスなど、一部の古いまたは特別に設定されたクライアントは、SNI をサポートしていないか、HTTPS リクエストを行う際に SNI 情報を送信しない場合があります。このような場合、CDN エッジノードはクライアントがアクセスしたい正確なサイトを特定できず、したがって正しい SSL/TLS 証明書を提供できません。これにより、HTTPS 接続が失敗し、ユーザーは Web サイトのコンテンツにアクセスできなくなります。

この問題を解決するには、以下を推奨します。

クライアントシステムのアップグレード：オペレーティングシステムとソフトウェアが最新であることを確認し、SNI がサポートされるようにしてください。
IoT デバイスのファームウェアの更新： IoT デバイスについては、製造元から提供される最新のファームウェアアップデートを定期的に確認し、インストールしてください。

秘密鍵ファイルからパスワード保護を解除する方法

キーがパスワードで保護されているかどうかを確認する
秘密鍵がパスワードで保護されており、暗号化アルゴリズムがわかっている場合は、以下の「パスワード保護の解除」セクションに直接進んで復号してください。秘密鍵がパスワードで保護されているかどうかわからない場合、または暗号化アルゴリズムがわからない場合は、次の手順に従って確認してください。
1. RSA 暗号化された秘密鍵の場合
  OpenSSL を使用して、次のコマンドを実行します。秘密鍵が暗号化されている場合、OpenSSL はパスフレーズの入力を求めるプロンプトを表示します: Enter pass phrase for <encrypted private key file>:。秘密鍵が暗号化されていない場合、OpenSSL はパスフレーズを要求せず、秘密鍵情報を表示します。エラーメッセージが返された場合は、秘密鍵が RSA 暗号化ファイルではないことを示します。
```
openssl rsa -in <encrypted_private_key_file> -text -noout
```
2. ECC/SM2 暗号化された秘密鍵の場合
  OpenSSL を使用して、以下のコマンドを実行します。秘密鍵が暗号化されている場合、OpenSSL によってパスワードの入力が求められます: Enter pass phrase for <encrypted_private_key_file>:。秘密鍵が暗号化されていない場合、OpenSSL はパスワードを要求せず、秘密鍵の情報を直接表示します。エラーメッセージが表示された場合、その秘密鍵は ECC または SM2 で暗号化されたファイルではありません。
```
openssl ec -in <encrypted_private_key_file> -text -noout
```
パスワード保護の解除
- 証明書の暗号化アルゴリズムが RSA の場合は、OpenSSL または BabaSSL がインストールされているコンピューターで次のコマンドを実行して、秘密鍵を復号してください。
```
openssl rsa -in <encrypted_private_key_file> -passin pass:<private_key_password> -out <decrypted_private_key_file>
```
- 証明書の暗号化アルゴリズムが ECC または SM2 の場合は、OpenSSL または BabaSSL がインストールされているコンピューターで次のコマンドを実行して、秘密鍵を復号してください。
```
openssl ec -in <encrypted_private_key_file> -passin pass:<private_key_password> -out <decrypted_private_key_file>
```