Trust Chain Manager is a self-service application that supports the creation, management, and deployment of trusted certificates issued by a certificate authority (CA) for use with client to ​Akamai​ edge mutual authentication.

How Trust Chain Manager works

Trust Chain Manager lets you create, manage, and deploy CA certificate sets which enables ​Akamai​ to authenticate client certificates from a user's browsers.

You may create multiple CA sets, providing a unique name/label for each. Each CA set contains one or more trusted CA certificates that are used to validate the client certificates presented by a user during the TLS handshake at the Edge.

You can think of a CA set as a virtual certificate trust store that can be associated with one or more of your Edge certificates to facilitate TLS mutual authentication (mTLS). You can create one or more CA sets. Each CA set may contain diverse groupings of trusted intermediate and root certificates that are intended to meet various mTLS requirements that can be applied to your Edge certificates. All CA certificates included in a CA set, intermediate or root, are considered mTLS trust anchors at the Edge.

Once a new CA set is created and deployed to Staging and Production, you may use CPS to apply that set to one or more Edge certificates on a contract, thereby enabling mTLS on those certificates.

Uploading certificates

When creating a new CA set or managing an existing CA set, you can use Trust Chain Manager to upload trusted CA certificates that will be used to authenticate client certificates. Once uploaded, Trust Chain Manager checks that your uploaded CA certificates are valid for Trust Chain Manager and then deploys your uploaded CA certificates as a named CA set to the ​Akamai​ edge. When deployed, you can associate your Edge Certificate with that named CA set - thereby enabling mTLS on that Edge Certificate.

Validating uploaded CA certificates

When Trust Chain Manager validates your uploaded CA certificates, it checks each certificate to ensure it is:

• Properly formed X509 certificate (PEM encoded)

• Has valid x509 CA flags set

• Currently within the validity period

• Using the SHA-1 signature hash algorithm or better. Certificates that use MD2, MD4, or MD5 signatures are not allowed

• Has a valid PKI chain to a self-signed root certificate using additional certificates within the same CA set, or is itself a self-signed root certificate (you can opt-out of this check by disabling Require Root Certificate).

Certificate set structure

As you create certificate sets, they appear in alphabetical order under Certificate sets. The number of versions associated with a set appears in parentheses. Certificate sets may contain multiple trust chains, which appear in the navigation tree. Your CA certificates appear under the set's deployment state in hierarchical order. The root CA is listed first in the chain, followed by intermediate certificates signed by that root, then any additional intermediates signed by the preceding intermediates and so on as shown in this trust chain example.

📘

Certificate number limit

Trust chains are limited to five certificates. If you exceed this limit, the chain fails validation. Upload only root and intermediate certificates. Trust Chain Manager does not accept end-entity (leaf) certificates and returns a validation error if one is uploaded.

When a set or certificate is selected, information such as deployment status and change details about that item appears on the right. A set’s version details includes the number of certificates uploaded.

Anytime you make a change to a deployed certificate set such as adding or removing a certificate, you need to re-deploy the set to either staging, production, or both. You cannot modify a certificate set while the set is being deployed (in flight). A new version of the certificate set is archived and appears above the version you modified.