Media CDN は、自ドメイン名からの TLS 暗号化（HTTPS）トラフィックの配信をファーストクラスでサポートしています。また、署名付きリクエストもサポートしています。Media CDN は独自のドメイン（お客様所有ドメインまたは BYO ドメイン）から提供され、Google がホストするドメインから提供する必要はありません。
- SSL（TLS）トラフィックの配信や Google 管理の証明書の取得に関連する追加料金はありません。エンドユーザーのトラフィックの保護にプレミアム料金はかかりません。
- Media CDN は、Google マネージド証明書とセルフマネージド（アップロードされた）証明書の両方をサポートしています。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 など）に対応しています。ワイルドカードは最初のサブドメイン レベルのみに対応し、より深いサブドメイン レベルには対応していません。たとえば、*.myorg.example.com は sub.subdomain.myorg.example.com をカバーしません。
Google マネージド証明書を作成するときに、1 つ以上の DNS 認証を使用して証明書をプロビジョニングして更新できます。1 つのドメインに複数の証明書がある場合は、すべての証明書に同じ DNS 認証を使用できます。ただし、DNS 認証は証明書にリストされているすべてのドメインを対象とする必要があります。対象としない場合、証明書の作成と更新は失敗します。
DNS 認証を設定するには、CNAME レコードを DNS 構成に追加する必要があります。このレコードを使用して、ターゲット ドメインのサブドメインを検証できます。CNAME レコードは、Certificate Manager がドメインの所有権の確認に使用する特別な Google Cloud ドメインを参照します。DNS 認証を作成すると、Certificate Manager はこの CNAME レコードを返し、所有権を確認します。
CNAME レコードは、Google Cloud プロジェクト内のターゲット ドメインの証明書のプロビジョニングと更新を行う権限も Certificate Manager に付与します。これらの権限を取り消すには、DNS 構成から CNAME レコードを削除します。
プロジェクトごとの DNS 認証
Google Cloud プロジェクトごとの DNS 認証を使用すると、各プロジェクト内で証明書を個別に管理できます。プロジェクトごとの 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 レコードをご覧ください。
証明書の上限
プロジェクトごとに最大 1,000 個のマネージド証明書と 1,000 個の DNS 認証を発行できます。関連するその他の上限と割り当てについては、割り当てと上限のドキュメントをご覧ください。
サポートされている TLS バージョン
メディア 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 バージョンを自動的にネゴシエートします。
- TLS 1.2 は、Media CDN でサポートされる最小の TLS バージョンです。
- Media CDN では、SSL ポリシーをサービスに適用することはできません。
証明書発行のトラブルシューティング
証明書の発行でエラーが発生した場合は、証明書の発行に関する問題のトラブルシューティングをご覧ください。
次のステップ
- SSL 証明書の構成を読む。
- クライアント接続とプロトコルのサポートを理解する。
- オリジンへの SSL（TLS）接続がどのように行われるかを確認します。