Media CDN has first-class support for serving TLS-encrypted (HTTPS) traffic from your own domain name, as well as support for signed requests. Media CDN is served from your own domain (Bring-Your-Own or BYO domain), and does not need to be served from a Google-hosted domain.
- There are no additional charges associated with serving SSL (TLS) traffic or obtaining Google-managed certificates: protecting end-user traffic should not be at a premium.
- Media CDN supports both Google-managed certificates, allowing Google to manage rotation, keys and secure distribution to thousands of edge nodes, as well as self-managed (uploaded) certificates.
- Each Service can support up to 5 SSL certificates.
- Each managed certificate can have up to 100 names (Subject Alternative Names).
We recommend serving your Edge Cache service from dedicated hostnames (subdomains) and using separate managed certificates for your media domains as a good security practice.
Create and issue certificates
To validate, issue, and attach a managed SSL (TLS) certificate to a Media CDN service, see configuring SSL certificates.
Media CDN supports two types of certificates:
- Managed certificates, which Google can provision on your behalf for domain names you own. You do not need secure keys, and certificates are automatically renewed.
- Self-managed certificates, which you upload to Certificate Manager directly. You are responsible for uploading a valid, publicly trusted certificate, as well as replacing the certificate prior to expiry.
Because managed certificates can be authorized and issued prior to directing traffic at Media CDN, you can provision certificates before cutting over your production traffic and avoid downtime.
In some cases, such as where you require key-pinning in mobile applications, or support for legacy devices with outdated trust stores, you might need to use self-managed certificates. You can also use both managed and self-managed certificates on the same service if you have specific domain names (hosts) that require self-managed certificates.
Authorizing certificate issuance
If you want your Google-managed certificates to be ready for use before your
production environment is fully set up, such as before starting a migration from
another vendor to Google Cloud, you can provision them with DNS
authorizations. In this scenario, Certificate Manager uses
DNS-based validation. Each DNS authorization stores information about the DNS
record that you need to set up and covers a single domain plus its wildcard—for
When creating a Google-managed certificate, you can specify one or more DNS authorizations to use for provisioning and renewal of that certificate. You can specify the same DNS authorization in multiple certificates. The DNS authorizations must cover all domains specified in the certificate; otherwise, certificate creation and renewals fail.
Setting up a DNS authorization requires you to add a CNAME record for a validation subdomain nested under your target domain to your DNS configuration. This CNAME record points to a special Google Cloud domain that Certificate Manager uses to verify domain ownership.
At this domain, Certificate Manager exposes a TXT record generated from the one-time challenge received from the CA. The CA must be able to access this TXT record to complete domain ownership verification. When you create the DNS authorization for the target domain, Certificate Manager returns the corresponding CNAME record.
The CNAME record also grants Certificate Manager permissions for provisioning and renewal of certificates for that domain within the target Google Cloud project. To revoke these permissions, remove the CNAME record from your DNS configuration.
Multiple domains per certificate
Certificates issued by Certificate Manager allow you to specify multiple domain names (hostnames) on the same certificate as Subject Alternative Names.
You can add multiple domains to a certificate by specifying a list of domains when creating a certificate, as well as any matching authorizations required.
Each authorization only covers the exact domain (for example,
video.example.com) and the wildcard (
*.example.com). It does not cover any
explicit subdomains. If you want a certificate for
example, you must set up another DNS authorization for the
The following examples show how to attach an authorization for
gcloud certificate-manager certificates command:
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
This creates a certificate with the DNS authorization in the
state and the certificate in the
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
Domains can't share a DNS authorization. You must specify multiple domains and authorizations. Certificate Manager determines which domains require which authorizations.
To learn how certificates are issued and activated, see Configure SSL (TLS) certificates.
Managed certificates are automatically renewed by Certificate Manager. Renewed certificates are automatically pushed to Google's global edge for each active service you have configured.
EDGE_CACHEcertificates have a short validity period (30 days) to improve security and compliance, compared to the current industry standard of 90 days (with a 60-day renewal interval).
- Certificate renewal is typically initiated when the certificate is 10 days from expiring.
- You do not need to take action when a certificate is renewed; the new certificate automatically replaces the existing certificate before the expiration date, with zero impact to your live traffic.
Because the issuance pipeline revalidates domain control before renewal, ensure that you do not delete the DNS records configured for DNS authorization. Deleting the record used to demonstrate DCV (Domain Control Validation) results in the inability to renew your certificates and prevents clients from connecting over HTTPS (TLS) when the certificate expires.
CAA records and roots
To check compatibility with client devices, including older smart TVs, smartphones and streaming boxes, you can find the full set of root CAs that Google uses at pki.goog.
To allow Certificate Manager and Media CDN to
issue certificates for a domain with existing CAA records, add the
DOMAIN_NAME. CAA 0 issue "pki.goog"
Domains that do not have existing CAA records do not need to add this record, but we recommend it as a best practice.
Read more about CAA records.
You can issue up to 1,000 managed certificates and 1,000 DNS authorizations per project. For other related limits and quotas, see the Quotas and limits documentation .
Supported TLS versions
Media CDN supports the following TLS versions, matching the
COMPATIBLE SSL policy configuration.
|TLS Version||Supported||Included Ciphers|
|SSL 3.0||No||N/A (not supported)|
|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|
- Devices that don't support modern versions of TLS (such as TLS 1.3) automatically negotiate a supported TLS version (provided there is not a minimum version set).
- TLS 1.0 and TLS 1.1 are enabled by default to enable the widest device compatibility.
- Media CDN does not support attaching SSL policies to a service.
Troubleshoot certificate issuance
If you face any errors with certificate issuance, see how to troubleshoot certificate issuance issues.
- Read Configure SSL certificates.
- Understand client connectivity and protocol support.
- Review how SSL (TLS) connections are made to your origins.