Understand the HTTPS connections

With an HTTPS request, there are two connections to consider. First, the connection from an end user to the Akamai Edge server; and second, the connection from an Edge server to your origin server, where the requested content is hosted. You need to consider both connections to properly incorporate HTTPS.



The entities in a request

There are multiple entities involved in the connections in an HTTPS request.

Entity Description How does it apply?
End user This is the entity requesting your website or app. The end user serves as "the client" in the first connection. (Specifically, the browser application in use acts as the client.)
Edge server This is a system within the Akamai content delivery network (CDN) that serves as a "go-between" for an end user requesting your site or app, and the origin that houses that site or app. Our CDN is comprised of thousands of Edge servers, and content from your origin is replicated to them. A request from an end user is directed to an Edge server that is geographically closest to it, to process the request and deliver your website or app as quickly as possible.
  • The Edge server serves as "the server" in the first connection.
  • The Edge server serves as "the client" in the second connection.
Origin This is where your actual website or application lives. This can be a unique origin server that you maintain for your own content, Akamai's NetStorage product or a third-party storage service. The origin serves as "the server" in the second connection.
Cert This is the certificate that is sent from the server to the requesting client. It is used to generated the public and private key pair, and is signed by a Certificate Authority. You need a separate cert for each connection in an HTTPS request.
Keys This represents the private and public key pair that is used to resolve a connection. A separate private and public key pair is required for each connection in an HTTPS request.

You need two certificates

Since there are two connections, we require two certificates for validation. Each connection uses a separate certificate, in order to incorporate a different public/private key pair.

  • The "Edge Certificate": This is the label we give to the certificate used for the first connection between the end user and the Edge server.
  • The "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. We avoid this problem by requiring separate private keys that are generated on the system where they're used, so they never need to be transmitted.