Use case 4: HTTPS using a custom/vanity DNS name: shared cert

Here, we use a “vanity” hostname for HTTPS traffic, and the subcustomer owns the DNS names used to serve content to End-Clients.

Additionally, the subcustomer doesn't require a vanity TLS certificate. (Other subcustomer hostnames may exist in the list of supported Subject Alternative Name (SAN) entries in a single TLS certificate.)

Value Example
Partner Domain
secure.cloudplatform.net
End-Client-facing Domain CNAME
{sub-customer-vanity-domain}. {TTL} IN CNAME 
{cert-identifier}.secure.cloudplatform-net.edgekey.net
Example End-Client-facing Domains
secure.sub-customer.com
shop.other-sub-customer.com
api.another-customer.com
Complete End-Client CNAME Chain - Example 1: subcustomer hostname direct to Akamai
secure.sub-customer.com. {TTL} IN CNAME san8.secure.cloudplatform.net.edgekey.net.

san8.secure.cloudplatform.net.edgekey.net. 21600 IN CNAME e1235.dsce16.akamaiedge.net.

e1235.dsce16.akamaiedge.net. 20 IN A 184.24.170.18
Complete End-Client CNAME Chain — Example 2: subcustomer hostname direct to Cloud Partner
secure.sub-customer.com. {TTL-1} IN CNAME
secure.sub-customer.com.secure.cloudplatform.net.

secure.sub-customer.com.secure.cloudplatform.net. {TTL-2} IN CNAME
san8.secure.cloudplatform.net.edgekey.net.

san8.secure.cloudplatform.net.edgekey.net.21600 IN CNAME
e1235.dsce16.akamaiedge.net.

e1235.dsce16.akamaiedge.net. 20 IN A 184.24.170.18

With this example, you (as the Cloud Partner) can support hundreds, or even thousands of these vanity DNS hostnames using shared SAN certificates. Multiple certificates are required to support such large numbers of hostnames, because a single TLS certificate has an overall size limit. Each SAN has a hard limit of 100 alternative name entries, but we recommend that you keep the max closer to 40 entries for best performance.

The Time to Live (TTL) for the vanity hostname CNAME record is determined by each individual subcustomer. (This is the second example {TTL-1}, above.) Being the cloud partner, you determine {TTL-2}.

In this case, you can adopt a pattern to relate a collection of DNS names to a single TLS SAN certificate. For example:

san{n}.secure.cloudplatform.net
  • {n}: This could be a simple index/counter for each SAN certificate you're using. You can create and modify certificates (add or remove hostnames) via the CPS API, via the CPS UI in Control Center, or you can work with Akamai Professional Services (at a cost) to implement them for you.

For example, a value of san1.secure.cloudplatform.net might be used for the first SAN certificate. This value is used by the back-end provisioning systems to define the Secure Edge Hostname for all SAN entries in this certificate, and is suffixed with .edgekey.net. As an end result, you have san1.secure.cloudplatform.net.edgekey.net as the DNS name in this example. It refers to this SAN and would support HTTPS delivery for any of the Subject Alternative Names added to the certificate.

Next, we use the sample subcustomer domain examples from the table above:

  • secure.sub-customer.com
  • shop.other-sub-customer.com.

Each subcustomer must CNAME to either:

  • Your cloud partner-managed DNS name (that is in turn CNAMEd to the secure Edge Hostname)
  • Directly to the secure Edge Hostname

The former lets you maintain control of the delivery and the associated certificate, and we recommend this approach. This might look like the following pair of example CNAME chains to be created by the respective Sub-Customers and in turn by you as the cloud partner:

secure.sub-customer.com. {TTL-1} IN CNAME
secure.sub-customer.com.secure.cloudplatform.net.

secure.sub-customer.com.secure.cloudplatform.net. {TTL-2} IN CNAME
san8.secure.cloudplatform.net.edgekey.net.

san8.secure.cloudplatform.net.edgekey.net. 21600 IN CNAME
e1235.dsce16.akamaiedge.net.

e1235.dsce16.akamaiedge.net. 20 IN A 184.24.170.18
shop.other-sub-customer.com. {TTL-1} IN CNAME 
shop.other-sub-customer.com.secure.cloudplatform.net.

shop.other-sub-customer.com.secure.cloudplatform.net. {TTL-2} IN CNAME
san8.secure.cloudplatform.net.edgekey.net.

san8.secure.cloudplatform.net.edgekey.net. 21600 IN CNAME
e1235.dsce16.akamaiedge.net.

e1235.dsce16.akamaiedge.net. 20 IN A 184.24.170.18

The CPS tool in Control Center and the deployed TLS certificate itself, show the list of alternate names in a given certificate. However,as the Cloud Partner, it is your responsibility to maintain the relationship between each vanity subcustomer domain and the Akamai Secure Edge Hostname to which the domain has been associated. It is also your responsibility to ensure that no certificate is overloaded beyond the stated limits.

What about the origin server?

Similar to the other use cases, the Akamai server requires a separate DNS hostname to use as the origin. The origin- prefix method works, so does creating an origin behavior for each subcustomer (just like what we show in Use case 1: HTTP-only, using a partner-owned DNS name).

When the intermediate hostname is not the same, the cloud partner DNS hostname that refers to the subcustomer method you use to retrieve content can be configured as the origin domain.

If you have subcustomers who provision their own origin certificates you must use the Property Manager in Control Center (or the Property Manager API) to configure the origin certificate and trust chain details individually on behalf of the subcustomer. When setting up the certificate for this use case, use the Choose Your Own option and a Trust setting of Custom Certificate Authority Set. Once set, you can add new Certificate Authorities or Specific Certificates for self-signed certificates.