If you want to deliver your content securely there are a few preparatory actions related to certificates that you need to complete before you start editing your property. This will help you make sure the configuration runs smoothly.

Understand secure connections

Secure hypertext transfer protocol (HTTPS) embodies security on the web. When end users make an HTTPS request to your site or application, they expect that their request and the response are encrypted and trusted, end-to-end.

At its base, HTTPS (also known as Secure Sockets Layer, SSL or Transport Layer Security, TLS) compares a pair of encryption keys, one public and one private, to allow access. When an HTTPS connection is established, the server sends the requesting client a certificate with:

• the public key
• a list of sites on which the cert is valid, referred to as a SAN
• an expiration date for the cert
• a signature from a Certificate Authority that proves that the key is legitimate for a SAN listed in the cert

The client checks whether:

• the signature matches the cert.
• the cert came from a Certificate Authority it trusts.
• the cert is actually for the site it requested.
• the cert hasn't expired.

If those checks succeed, the client encrypts this information using the public key, and sends it to the server, establishing a shared key for the session. Only a server that holds the corresponding private key can decrypt the information, read the shared key, and ultimately prove its identity to the requesting client.

Stages of an HTTPS request

In HTTPS delivery, there are two connections involved in a request using the ​Akamai​ platform:

• Client to edge server. This is the initial connection between the end user's browser and the edge server. The property hostname to edge hostname association determines how to deliver the requested content based on the property configuration. To secure the connection, you must use the "edge certificate" that is verified between the client and the edge server.

  

• Edge server to origin. This is the connection between the edge server and your designated origin, where the requested content is hosted. To configure this connection, you set the Origin Server behavior in your property.

  

You need two certificates

Since there are two connections, two certificates are required for validation, unless you are using NetStorage as your origin server. Each connection uses a separate certificate in order to incorporate a different public/private key pair.

• Edge certificate. This is the certificate used for the first connection between the end user and the edge server.

• Origin certificate. This is the certificate used in the second connection, between the edge server and the origin server.

While you could use a single key pair for both connections, you'd need to send the private key between the origin and edge server over the public internet, and this defeats the purpose of HTTPS. If the private key was intercepted by an attacker, they could impersonate your site to any end user. ​Akamai​ avoids this problem by requiring separate private keys that are generated on the system where they're used, so they never need to be transmitted.

🚧

NetStorage origin

You don't need to create an origin certificate if you're using NetStorage as your origin.

Discontinued SHA ciphers

If you are using HTTPS delivery, note that various versions of Secure Hash Algorithm (SHA) cipher are no longer supported for use in certificates.

The discontinued ciphers include:

• DES-CBC-SHA

• RSA-IDEA-CBC-SHA

• EDH-RSA-DES-CBC-SHA

• EDH-RSA-DES-CBC3-SHA

These ciphers have been discontinued for both portions of the edge server to origin connection.

🚧

Update the ciphers

If your certificate uses any of these ciphers in an existing property configuration, talk to your account representative to have it updated.