SSL (TLS) Certificates

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).

Note: Certificates can be issued or uploaded with Certificate Manager. Only certificates with a scope of EDGE_CACHE can be associated with an EdgeCacheService.

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.

Certificate types

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.

Note: We strongly recommend using managed certificates, which avoid the risk of a certificate accidentally expiring and causing your user-facing requests to fail.

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 example, myorg.example.com and *.myorg.example.com.

When creating a Google-managed certificate, you can specify one or more DNS authorizations to use for provisioning and renewal of that certificate. If you are using multiple certificates for a single domain, you can specify the same DNS authorization in each of those certificates. Your DNS authorizations must cover all domains specified in the certificate; otherwise, certificate creation and renewals fail.

You can manage certificates for each project separately by using per-project DNS authorization. This means that Certificate Manager can issue and manage certificates for each project independently within Google Cloud. DNS authorizations and certificates that you use within a project are self-contained and don't interact with those in other projects.

Note: Due to ongoing IETF standardization efforts for account-based DNS authorization, Google uses a custom implementation of account-based DNS authorization for per-project DNS authorizations.

Setting up a DNS authorization requires you to add a CNAME record for a validation sub-domain 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. Certificate Manager returns the CNAME record when you create a DNS authorization for the target domain.

The CNAME record also grants to Certificate Manager the 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.

Note: The validation sub-domain must be openly resolvable from the internet. Split-horizon or DNS firewall environments can interfere with certificate provisioning.

To enable per-project DNS authorization, select the PER_PROJECT_RECORD during the DNS authorization creation process. Upon selection, you receive a unique CNAME record that includes both subdomain and target and that is tailored to the specific project.

Add the CNAME record to the DNS zone of the relevant domain.

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.

Key Point: You must attach authorizations that cover all of the domains listed on the certificate. A certificate with unauthorized names cannot be issued.

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 eu.video.example.com, for example, you must set up another DNS authorization for the eu.video.example.com domain.

The following examples show how to attach an authorization for video.example.com and eu.video.example.com:

gcloud

Use the 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 theAUTHORIZING state and the certificate in the PROVISIONING state:

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.

Certificate renewal

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_CACHE certificates 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 pki.goog CAA record:

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.

Certificate limits

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:

TLS Version	Supported	Included Ciphers
SSL 3.0	No	N/A (not supported)
TLS 1.0	No	N/A (not supported)
TLS 1.1	No	N/A (not supported)
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

Additionally:

• Devices that don't support modern versions of TLS (such as TLS 1.3) automatically negotiate a supported TLS version.
• TLS 1.2 is the minimum supported TLS version for Media CDN.
• 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.

What's next

• Read Configure SSL certificates.
• Understand client connectivity and protocol support.
• Review how SSL (TLS) connections are made to your origins.