Media CDN は、TLS で暗号化された（HTTPS）トラフィックを独自のドメイン名から配信するための優れたサポートと、署名付きリクエストのサポートを提供します。メディア CDN は独自のドメイン（Bring-Your-Own または BYO）から提供されます。Google がホストするドメインから提供する必要はありません。
- SSL（TLS）トラフィックの処理や Google マネージド証明書の取得に関連する追加料金は発生しません。エンドユーザーのトラフィックの保護をプレミアムにしないでください。
- Media CDN は Google マネージド証明書をサポートします。これにより、Google が数千のエッジノードへのローテーション、鍵、安全な配信と、セルフマネージド（アップロード）証明書を管理できます。
- 各 Service は最大 5 つの SSL 証明書をサポートします。
- 各マネージド証明書には最大 100 個の名前（サブジェクト代替名）を設定できます。
Edge Cache サービスは、専用のホスト名（サブドメイン）から提供し、メディア ドメインごとに個別のマネージド証明書を使用することをおすすめします。
証明書を作成して発行する
マネージド SSL（TLS）証明書を検証、発行、メディア CDN サービスに添付するには、SSL 証明書の構成をご覧ください。
Certificate types
Media CDN は次の 2 種類の証明書をサポートしています。
- マネージド証明書。お客様所有のドメイン名の代わりに Google がプロビジョニングできます。セキュアな鍵は必要なく、証明書は自動的に更新されます。
- セルフマネージド証明書: Certificate Manager に直接アップロードします。お客様には、有効で一般公開された有効な証明書をアップロードし、有効期限が切れる前に証明書を置き換える必要があります。
マネージド証明書は、Media CDN でトラフィックを転送する前に承認および発行できるため、本番環境のトラフィックをカットする前に証明書をプロビジョニングして、ダウンタイムを回避できます。
モバイル アプリケーションでのキー固定の必要や、古いトラストストアを持つレガシー デバイスのサポートが必要な場合などでは、セルフマネージド証明書が必要になることがあります。セルフマネージド証明書を必要とする特定のドメイン名（ホスト）がある場合は、同じサービスでマネージド証明書とセルフマネージド証明書の両方を使用することもできます。
証明書の発行を承認する
別のベンダーから Google Cloud への移行を開始する前になど、本番環境を完全に設定する前に Google マネージド証明書を使用できるようにするには、DNS 承認をプロビジョニングします。このシナリオでは、Certificate Manager は DNS ベースの検証を使用します。各 DNS 認可には、セットアップする必要がある DNS レコードに関する情報と、単一のドメインとそのワイルドカード（example.com や *.example.com など）が格納されています。
Google マネージド証明書を作成するときに、その証明書のプロビジョニングと更新に使用する 1 つ以上の DNS 承認を指定できます。複数の証明書で同じ DNS 承認を指定できます。DNS 承認は、証明書で指定されたすべてのドメインをカバーする必要があります。そうしなければ、証明書の作成と更新に失敗します。
DNS 認証を設定するには、ターゲット ドメインの下にネストされている検証サブドメインの CNAME レコードを DNS 構成に追加する必要があります。この CNAME レコードは、証明書マネージャーがドメインの所有権を確認するために使用する特別な Google Cloud ドメインを指します。
このドメインで、Certificate Manager は、CA から受け取った 1 回限りのチャレンジから生成された TXT レコードを公開します。ドメインの所有権の確認を完了するには、CA がこの TXT レコードにアクセスできる必要があります。ターゲット ドメインの DNS 承認を作成すると、証明書マネージャーは対応する CNAME レコードを返します。
CNAME レコードは、ターゲットの Google Cloud プロジェクト内のそのドメインの証明書のプロビジョニングと更新の権限も Certificate Manager に付与します。これらの権限を取り消すには、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
これにより、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）証明書の構成をご覧ください。
証明書の更新
マネージド証明書は、証明書マネージャーによって自動的に更新されます。更新された証明書は、構成したアクティブなサービスごとに Google のグローバル エッジに自動的に push されます。
- 現在の業界標準である 90 日（60 日の更新間隔）と比べて、
EDGE_CACHE証明書の有効期間は短く（30 日）、セキュリティとコンプライアンスが向上しています。 - 証明書の更新は通常、証明書が期限切れしてから 10 日後に開始します。
- 証明書が更新された場合は、何もする必要はありません。新しい証明書は、有効期限が切れる前に既存の証明書を自動的に置き換えます。ライブ トラフィックには影響しません。
発行パイプラインは更新前にドメイン制御を再検証するため、DNS 承認用に構成された DNS レコードを削除しないでください。DCV（ドメイン管理の検証）を示すレコードを削除すると、証明書の更新ができなくなり、証明書が期限切れになったときにクライアントが HTTPS（TLS）経由で接続できなくなります。
CAA レコードとルート
古いスマートテレビ、スマートフォン、ストリーミング ボックスなど、クライアント デバイスとの互換性を確認するには、Google が使用しているルート CA の完全なセットを pki.goog で確認できます。
既存の CAA レコードを持つドメインの証明書を Certificate Manager と Media CDN が発行できるようにするには、pki.goog CAA レコードを追加します。
DOMAIN_NAME. CAA 0 issue "pki.goog"
既存の CAA レコードがないドメインでは、このレコードを追加する必要はありませんが、ベスト プラクティスとしてレコードを追加することをおすすめします。
CAA レコードの詳細をご覧ください。
証明書の発行のトラブルシューティング
発行（または更新）の失敗の最も一般的な原因は、DNS レコードが無効か、欠落しているために、Certificate Manager でドメインの所有権を確認できないことです。
- パブリック DNS 経由で DNS レコードにアクセスできることを確認します。ドメインの
_acme-challengeCNAME レコードの値（アンダースコアが必要）は、承認の作成時にdnsResourceRecord.dataで指定された値を返します。Google Public DNS を使用して、レコードが解決可能で有効であることをすばやく確認できます。 - 証明書をリクエストしているドメインが、証明書リクエストに関連付けられている承認と一致するか、そのサブドメインであることを確認します。たとえば、
media.example.comを承認することにより、media.example.com、uk.media.example.comおよびstaging.media.example.comには証明書を発行できますが、www.example.comには発行できません。 - ドメインに既存の CAA レコードがある場合、Certificate Manager でドメインの証明書を発行できない場合があります。Google が承認済みドメインの証明書を発行できるように、
pki.googの CAA レコードがあることを確認してください。問題が CAA レコードの制限によるものである場合、API レスポンスのfailure_reasonフィールドにCAAの値が含まれます。 - スコープ
EDGE_CACHEを持つ証明書を Edge キャッシュ サービスにのみ接続できます。証明書の作成時にEDGE_CACHEのスコープを明示的に指定しなかった場合は、既存の DNS 承認を使用して証明書を再発行する必要があります。
複数のドメイン名を持つ証明書を作成する場合、無効なドメイン承認は、証明書の発行または更新を行えません。これにより、リクエストしたすべてのドメインが、発行される証明書に含まれるようになります。証明書に関連付けられた各ドメインで、DNS レコード、ドメイン名、CAA レコードの構成が有効であることを確認します。
失敗の理由
次の表は、証明書を発行しようとしたときに返される可能性のある失敗の理由、原因、推奨される修正を示しています。
| Type | エラー | トラブルシューティング手順 |
|---|---|---|
| DNS 認証 | CONFIG | DNS を介して証明書を検証できませんでした。多くの場合、これは DNS レコードが欠落しているか、無効である（誤ってコピーされた）か、承認済みドメインの子ではないサブドメインに対して証明書を発行しようとしていることを意味します。 |
| DNS 認証 | CAA | ドメインに関連付けられた現在の [CAA レコード](/media-cdn/docs/ssl-cerificates#caa-records-roots)のセットで証明書の発行が禁止されているか、CAA レコードが更新されました。 |
| DNS 認証 | RATE_LIMITED | （一般的でない）CA またはドメインで受け入れられる速度よりも速く証明書を発行している（1 分間に数十以上など）。 |
| 証明書 | AUTHORIZATION_ISSUE | 個別ドメインの承認に失敗しました。ドメインの managed.authorizationAttemptInfo.failureReason の値を確認して、承認が失敗した理由を理解します。 |
証明書の制限
プロジェクトごとに最大 1,000 個のマネージド証明書と 1,000 個の DNS 承認を発行できます。その他の関連する上限と割り当てについては、割り当てと上限のドキュメントをご覧ください。
サポートされている TLS バージョン
Media CDN は、COMPATIBLE SSL ポリシー構成と一致する次の TLS バージョンをサポートしています。
| TLS Version | サポート対象 | 含まれる暗号 |
|---|---|---|
| SSL 3.0 | なし | なし - サポート対象外 |
| TLS 1.0 | ✔ | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA |
| TLS 1.1 | ✔ | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA |
| 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 バージョンを自動的にネゴシエートします（最小バージョンが設定されていない場合）。
- デバイスの幅広い互換性を実現するため、TLS 1.0 と TLS 1.1 はデフォルトで有効になっています。
- Media CDN では、サービスに SSL ポリシーを追加できません。
次のステップ
- SSL 証明書を構成するをご覧ください。
- クライアント接続とプロトコルのサポートについて理解します。
- 送信元への SSL（TLS）接続方法を確認します。