Inspecting TLS Web Traffic – Part 3

by Jim Black on December 23, 2019

In the second part of this blog, I covered how HTTPS web content inspection is provided in Akamai’s Enterprise Threat Protector (ETP) service using ETP proxy. In this final blog post I want to provide information about how Akamai generates, distributes and controls access to private keys including TLS certificates.

Akamai KMI Introduction

The Key Management Infrastructure (KMI) is Akamai’s distributed system for generation, escrow, distribution, and access control for private keys and other private pieces of information used on our Secure Content Delivery Network (the Secure CDN), our Enhanced TLS service, and ETP Proxy services. KMI allows Akamai to not only securely provision our customers’ certificates, which are presented to end users on behalf of our customers, but also securely distribute them to hundreds of ETP proxy servers around the globe.

A key security benefit of ETP is that the certificates which Akamai presents to end users from our proxy servers are based on public and private keys generated by KMI. This is to ensure that only Akamai is responsible for the security of its certificates and keys, while helping to prevent “man-in-the-middle” attacks. Akamai does not support the use of private keys generated by customers outside of Akamai’s KMI.

KMI helps ensure the safety of this critical customer data by allowing us to control our secrets in an automated way, resulting in improved security and low operational overhead on our networks. When necessary, both Akamai and customers can rotate secrets quickly, automatically, and regularly. Secrets generated by KMI are trusted and reliable without any human ever being exposed to these secrets.

KMI System Components

KMI consists of a series of servers deployed in some of Akamai’s most secure colocation data Centers. There are three core components in the KMI system, which provide the necessary infrastructure for secret management:

Sponsorships Available

The Key Distribution Center (KDC) is the central brain of KMI and is responsible for managing secrets (generation, provisioning, and access).
Auditserver authenticates the ETP Proxy servers on our network, confirms that they are properly configured to deliver traffic, and verifies that they have not been compromised.
Key Agent (sometimes spelled “keyagent”) runs on all servers (and other machines that receive secrets from KMI) and acts as a proxy to provide a secure, isolated component for managing secrets locally on ETP proxy servers.

When combined, these systems provide a highly secure means of generating CSRs, storing related certificates and private keys, and distributing these to the ETP proxy servers for use in the service.

Managing CSRs and Certificates for ETP via KMI

Customers indirectly leverage KMI via the Certificate menu in the portal for ETP. Some of these actions were previously described in this document. In summary, from the Certificate menu customers can:

Download an Akamai-Signed certificate to distribute on your users’ systems
Generate a CSR for an intermediate root that you sign with a private CA (non-Akamai certificate)
Upload and distribute the intermediate root cert signed by your private CA (non-Akamai certificate)
Rotate certificates at any time (along with the private key).
Distribute the certificates to the Proxy for use in the service

The images below shows how an admin starts the process of selecting the certificate type for the service. They also show how an existing certificate deployed to the platform can be rotated, with a corresponding change in private key issued by CSI.

Readers who seek more information on Akamai’s Key Management Infrastructure beyond what is included in this blog should request from their account team the document Akamai’s Key Management Infrastructure: An Overview published April 2019, which is available under NDA.