SSL（TLS）証明書

Media CDN は、独自のドメイン名からの TLS 暗号化（HTTPS）トラフィックの配信をファーストクラスでサポートしています。また、署名付きリクエストもサポートしています。Media CDN は独自のドメイン（お客様所有ドメインまたは BYO ドメイン）から提供され、Google がホストするドメインから提供する必要はありません。

  • SSL（TLS）トラフィックの処理や Google 管理の証明書の取得に追加料金はかかりません。エンドユーザー トラフィックの保護に追加料金はかかりません。
  • Media CDN は、Google マネージド証明書とセルフマネージド（アップロードされた）証明書の両方をサポートしています。これにより、Google はローテーション、鍵、数千のエッジノードへの安全な配信を管理できます。
  • 各 Service は最大 5 つの SSL 証明書をサポートできます。
  • 各マネージド証明書には、最大 100 個の名前（サブジェクトの代替名）を含めることができます。

セキュリティ上のベスト プラクティスとして、専用のホスト名（サブドメイン）から Edge Cache サービスを提供することをおすすめします。また、メディア ドメインには別個のマネージド証明書を使用することをおすすめします。

証明書を作成して発行する

マネージド SSL（TLS）証明書を検証、発行、Media CDN サービスに接続する方法については、SSL 証明書の構成をご覧ください。

証明書のタイプ

Media CDN は、次の 2 種類の証明書をサポートしています。

  • マネージド証明書: お客様が所有するドメイン名に対して Google がプロビジョニングできます。安全な鍵は不要で、証明書は自動的に更新されます。
  • セルフマネージド証明書,、Certificate Manager に直接アップロードします。有効で公的に信頼されている証明書をアップロードし、有効期限が切れる前に証明書を交換する責任はお客様にあります。

マネージド証明書は、Media CDN でトラフィックを転送する前に承認と発行ができるため、本番環境トラフィックのカットオーバー前に証明書をプロビジョニングして、ダウンタイムを回避できます。

モバイル アプリケーションでキー ピンニングが必要な場合や、古いトラストストアを持つ従来のデバイスをサポートする必要がある場合など、自己管理証明書を使用する必要がある場合があります。セルフマネージド証明書が必要な特定のドメイン名（ホスト）がある場合は、同じサービスでマネージド証明書とセルフマネージド証明書の両方を使用することもできます。

証明書発行の承認

DNS 認証を使用すると、本番環境を完全に設定する前に、ドメインの所有権を確認して Google マネージド証明書をプロビジョニングできます。これは、証明書を Google Cloud に移行する場合に特に便利です。

Certificate Manager は DNS レコードを使用してドメインの所有権を確認します。各 DNS 承認には、DNS レコードに関する情報が保存され、単一のドメインとそのワイルドカード（myorg.example.com と *.myorg.example.com の両方など）に対応しています。

Google マネージド証明書を作成するときに、証明書のプロビジョニングと更新に 1 つ以上の DNS 認証を使用できます。1 つのドメインに複数の証明書がある場合は、それらすべてに同じ DNS 認証を使用できます。ただし、DNS 認証は証明書にリストされているすべてのドメインを対象とする必要があります。対象としていない場合、証明書の作成と更新は失敗します。

DNS 認証を設定するには、DNS 構成に CNAME レコードを追加する必要があります。このレコードは、移行先ドメインのサブドメインの検証に使用されます。CNAME レコードは、Certificate Manager がドメインの所有権の確認に使用する特別な Google Cloud ドメインを参照します。DNS 認証を作成すると、Certificate Manager はこの CNAME レコードを返して所有権を確認します。

CNAME レコードは、Google Cloud プロジェクト内の移行先ドメインの証明書のプロビジョニングと更新を行うための Certificate Manager の権限も付与します。これらの権限を取り消すには、DNS 構成から CNAME レコードを削除します。

プロジェクトごとの DNS 認証

プロジェクトごとの DNS 認証を使用すると、各 Google Cloud プロジェクト内で証明書を個別に管理できます。プロジェクトごとの DNS 認証を使用すると、Certificate Manager はプロジェクトごとに証明書を発行して処理できます。プロジェクト内で使用される DNS 認証と証明書は自己完結型であり、他のプロジェクトのアーティファクトとはやり取りしません。

プロジェクトごとの DNS 認証を有効にするには、DNS 認証を作成するときに PER_PROJECT_RECORD オプションを選択します。その後、サブドメインとそのプロジェクト固有のターゲットの両方を含む一意の CNAME レコードが生成されます。この CNAME レコードは、関連するドメインの DNS ゾーンに追加する必要があります。

証明書あたりの複数ドメイン

Certificate Manager によって発行された証明書では、同じ証明書に複数のドメイン名（ホスト名）をサブジェクト代替名として指定できます。

証明書の作成時にドメインのリストと、必要な一致する承認を指定して、証明書に複数のドメインを追加できます。

各承認は、正確なドメイン（video.example.com など）とワイルドカード（*.example.com）のみを対象とします。明示的なサブドメインは対象外です。たとえば、eu.video.example.com の証明書が必要な場合は、eu.video.example.com ドメインに別の DNS 認証を設定する必要があります。

次の例は、video.example.com と eu.video.example.com の承認を適用する方法を示しています。

gcloud

gcloud certificate-manager certificates コマンドを使用します。

gcloud certificate-manager certificates create video-example-com \
    --domains="video.example.com,eu.video.example.com" \
    --dns-authorizations="video-example-com-auth,eu-video-example-com-auth" \
    --scope=EDGE_CACHE

これにより、DNS 認証が AUTHORIZING 状態の証明書と、PROVISIONING 状態の証明書が作成されます。

managed:
authorizationAttemptInfo:
- domain: video.example.com
  state: AUTHORIZED
dnsAuthorizations:
- projects/123456/locations/global/dnsAuthorizations/video-example-com-auth
- projects/123456/locations/global/dnsAuthorizations/eu-video-example-com-auth
domains:
- video.example.com
state: PROVISIONING
scope: EDGE_CACHE
subjectAlternativeNames:
- video.example.com

ドメインは DNS 認証情報を共有できません。複数のドメインと承認を指定する必要があります。Certificate Manager は、どのドメインにどの承認が必要かを判断します。

証明書の発行と有効化の方法については、SSL（TLS）証明書を構成するをご覧ください。

証明書の更新

マネージド証明書は Certificate Manager によって自動的に更新されます。更新された証明書は、構成したアクティブなサービスごとに Google のグローバル エッジに自動的に push されます。

  • 現在の業界標準の 90 日間（更新間隔 60 日）と比べて、EDGE_CACHE 証明書の有効期間はセキュリティとコンプライアンスを向上するために、短く（30 日間）なっています。
  • 通常、証明書の更新は、証明書の有効期限が切れる 10 日前に開始されます。
  • 証明書の更新時に操作する必要はありません。新しい証明書は有効期限の前に自動的に既存の証明書に置き換えられ、運用中のトラフィックに影響を与えません。

発行パイプラインは更新前にドメイン管理を再検証するため、DNS 認可用に構成された DNS レコードを削除しないようにしてください。DCV（ドメイン管理検証）の検証に使用したレコードを削除すると、証明書を更新できなくなり、証明書の有効期限が切れたときにクライアントが HTTPS（TLS）経由で接続できなくなります。

CAA レコードとルート

古いスマートテレビ、スマートフォン、ストリーミング ボックスなどのクライアント デバイスとの互換性を確認するには、Google が使用するルート CA の完全なセットを pki.goog で確認してください。

Certificate Manager と Media CDN が既存の CAA レコードを持つドメインの証明書を発行できるようにするには、pki.goog CAA レコードを追加します。

DOMAIN_NAME. CAA 0 issue "pki.goog"

既存の CAA レコードがないドメインには、このレコードを追加する必要はありませんが、ベスト プラクティスとして追加することをおすすめします。

詳しくは、CAA レコードをご覧ください。

証明書の上限

プロジェクトごとに発行できるマネージド証明書と DNS 認証は最大 1,000 個です。その他の関連する上限と割り当てについては、割り当てと上限のドキュメントをご覧ください。

サポートされている TLS バージョン

Media CDN は、次の TLS バージョンをサポートしています。

TLS Version サポート対象 含まれる暗号
SSL 3.0 いいえ なし - サポート対象外
TLS 1.0 いいえ なし - サポート対象外
TLS 1.1 いいえ なし - サポート対象外
TLS 1.2 ✔ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384
TLS 1.3 ✔ TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256

また、次の点も注意してください。

  • 最新バージョンの TLS（TLS 1.3 など）をサポートしていないデバイスは、サポートされている TLS バージョンを自動的にネゴシエートします。
  • Media CDN でサポートされる最小 TLS バージョンは TLS 1.2 です。
  • Media CDN では、サービスへの SSL ポリシーの適用はサポートされていません。

証明書発行のトラブルシューティング

証明書の発行でエラーが発生した場合は、証明書の発行に関する問題のトラブルシューティングをご覧ください。

次のステップ