To start, you should have a basic understanding of the flow of a request and how the ​Akamai​ content delivery network (CDN) fits in.

The stages of a request

There are two connections involved in a request using the ​​Akamai​ platform:

1. The client to the ​Akamai​ edge server. This is the initial connection between the end user's browser or application and an edge server in the ​Akamai​ network. When you set up a property, you assign an edge hostname to a property hostname, that is the domain that the end users request. Based on this correlation, the edge server maps and reads the property configuration to determine how to deliver your content to the end user. To secure the connection, you'll need to use an edge certificate that's verified between the client and the edge server.

2. The ​Akamai​ edge server to origin. This is the connection between the edge server and your designated origin, where the requested content is hosted. You'll use the obligatory Origin Server behavior and various other behaviors in your property to configure this connection. Depending on your selected origin type, you may need to create a separate secure certificate and apply it on your origin. See Prepare your origin server for all the details.

Understand secure connections and certificates

📘

Secure hypertext transfer protocol (HTTPS) has become the standard for access on the Internet. All processes covered here focus on the use of this security to deliver your content via the ​Akamai​ network. While non-secure HTTP is still supported, it's not recommended.

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 subject alternative name SAN list
• 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.