Media CDN は、独自のドメイン名から TLS で暗号化された（HTTPS）トラフィックを処理する最高レベルのサポートに加え、署名付きリクエストもサポートしています。Media CDN は独自のドメイン（お客様所有ドメインまたは BYO ドメイン）から提供され、Google がホストするドメインから提供する必要はありません。
- SSL（TLS）トラフィックの配信や Google マネージド証明書の取得に関連して追加料金がかかることはありません。エンドユーザーのトラフィックの保護は高価ではありません。
- Media CDN は Google マネージド証明書の両方をサポートしているため、Google はセルフマネージド証明書（アップロード済み）だけでなく、ローテーション、鍵、数千のエッジノードへの安全な配信を管理できます。
- 各サービスは、最大 5 つの SSL 証明書をサポートできます。
- 各マネージド証明書には、最大 100 個の名前（サブジェクト代替名）を設定できます。
セキュリティ対策として、専用ホスト名（サブドメイン）から Edge Cache Service を提供し、メディア ドメインには個別のマネージド証明書を使用することをおすすめします。
証明書を作成して発行する
マネージド SSL（TLS）証明書を検証して発行し、Media CDN サービスに添付するには、SSL 証明書の構成をご覧ください。
証明書のタイプ
Media CDN では、次の 2 種類の証明書がサポートされています。
- マネージド証明書。Google が、所有しているドメイン名に対してユーザーに代わってプロビジョニングできます。安全な鍵は不要であり、証明書は自動的に更新されます。
- セルフマネージド証明書,、Certificate Manager に直接アップロードします。ユーザーは、公的に信頼できる有効な証明書をアップロードすることと、有効期限が切れる前に証明書を置き換える責任があります。
マネージド証明書は Media CDN にトラフィックを転送する前に承認および発行できるため、本番環境のトラフィックをカットする前に証明書をプロビジョニングして、ダウンタイムを回避できます。
場合によっては、モバイル アプリケーションで鍵を固定する場合や、古いトラストストアを持つレガシー デバイスのサポートが必要な場合など、セルフマネージド証明書を使用する必要があります。セルフマネージド証明書を必要とする特定のドメイン名（ホスト）がある場合は、同じサービスでマネージド証明書とセルフマネージド証明書の両方を使用することもできます。
証明書の発行を承認する
別のベンダーから Google Cloud への移行を開始する前になど、本番環境を完全に設定する前に Google マネージド証明書を使用できるようにするには、DNS 承認をプロビジョニングします。このシナリオでは、Certificate Manager は DNS ベースの検証を使用します。各 DNS 承認には、設定する必要がある DNS レコードに関する情報が保存され、単一のドメインとそのワイルドカード（myorg.example.com や *.myorg.example.com など）に対応しています。
Google マネージド証明書を作成するときに、その証明書のプロビジョニングと更新に使用する DNS 認証を 1 つ以上指定できます。1 つのドメインに複数の証明書を使用している場合は、それぞれの証明書に同じ DNS 認証を指定できます。DNS 認証は、証明書に指定されているすべてのドメインを対象にする必要があります。そうしないと、証明書の作成と更新が失敗します。
プロジェクトごとの DNS 認証を使用すると、プロジェクトごとに証明書を個別に管理できます。つまり、Certificate Manager は、Google Cloud 内でプロジェクトごとに個別に証明書を発行および管理できます。プロジェクト内で使用する DNS 認証と証明書は自己完結型であり、他のプロジェクトのものとはやり取りしません。
DNS 認証を設定するには、ターゲット ドメインの下にネストされている検証サブドメインの CNAME レコードを DNS 構成に追加する必要があります。この CNAME レコードは、Certificate Manager がドメインの所有権の確認に使用する特別な Google Cloud ドメインを指します。Certificate Manager は、ターゲット ドメインの DNS 認証を作成するときに、CNAME レコードを返します。
また CNAME レコードは、ターゲットの Google Cloud プロジェクト内でそのドメインの証明書のプロビジョニングと更新を行う権限を Certificate Manager に付与します。これらの権限を取り消すには、DNS 構成から CNAME レコードを削除します。
プロジェクトごとの DNS 認証を有効にするには、DNS 認証の作成プロセスで PER_PROJECT_RECORD を選択します。選択すると、サブドメインとターゲットの両方を含み、特定のプロジェクトに合わせた一意の CNAME レコードを受け取ります。
関連するドメインの DNS ゾーンに CNAME レコードを追加します。
証明書ごとの複数のドメイン
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
これにより、AUTHORIZING 状態の DNS 認証と 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（Domain Control Validation）の証明に使用するレコードを削除すると、証明書を更新できなくなります。また、証明書の有効期限が切れたときにクライアントが HTTPS（TLS）で接続できなくなります。
CAA レコードとルート
古いスマートテレビ、スマートフォン、ストリーミング ボックスなどのクライアント デバイスとの互換性を確認するには、Google が使用するルート CA の完全なセットを pki.goog で確認できます。
Certificate Manager と Media CDN が、既存の CAA レコードを持つドメインの証明書を発行できるようにするには、pki.goog CAA レコードを追加します。
DOMAIN_NAME. CAA 0 issue "pki.goog"
既存の CAA レコードがないドメインでは、このレコードを追加する必要はありませんが、追加することをおすすめします。
CAA レコードの詳細を確認する。
証明書の上限
プロジェクトごとに最大 1,000 個のマネージド証明書と 1,000 個の DNS 認証を発行できます。その他の関連する上限と割り当てについては、割り当てと上限のドキュメントをご覧ください。
サポートされている TLS バージョン
Media CDN は、次の TLS バージョンをサポートしています。
| TLS Version | サポート対象 | 含まれる暗号 |
|---|---|---|
| SSL 3.0 | いいえ | なし - サポート対象外 |
| TLS 1.0 | いいえ | なし - サポート対象外 |
| TLS 1.1 | いいえ | なし - サポート対象外 |
| TLS 1.2 | ✔ | 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 ポリシーの適用をサポートしていません。
証明書の発行のトラブルシューティング
証明書の発行でエラーが発生した場合は、証明書の発行に関する問題のトラブルシューティングをご覧ください。
次のステップ
- SSL 証明書の構成を読む。
- クライアント接続とプロトコルのサポートを理解する。
- 送信元との SSL（TLS）接続の方法を確認する。