Get familiar with Mutual TLS Edge Truststore terminology:

• Certificate (also: CA certificate). It's an electronic document that identifies a company (such as the name of the company and address), a public key, and the digital signature of a CA based on that certification authority's private key. In a public-key encryption system, you can widely distribute public keys, but only the owner knows the paired private keys. Any person can encrypt content using the public key of the receiver, but only the receiver’s private key can decrypt the content.

  • Root certificate. It's a primary, self-signed certificate that meets the X.509 standard. This certificate identifies the certificate authority (CA) that signs a client's certificate.
  • Intermediate certificate. It's a secondary certificate that meets the X.509 standard. This certificate serves as an extra level of security and a link of trust that provides the necessary chaining to the trusted root certificate in a secure socket layer connection.

• Certificate validation. When you create a certificate set along with its version, the API checks if the certificates are valid. After your CA set is activated, you can enable mutual authentication for the set in the Certificate Provisioning System. To learn more about certificate validation per the PA requirements, see Validating added certificates.

  📘

  Mutual TLS Edge Truststore does not accept end-entity (leaf) certificates and returns a validation error if one is uploaded.

• Certificate authority (CA). It’s a trusted entity that signs certificates and can vouch for the identity of a website. You can use Certificate Provisioning System to integrate and generate certificates using two CAs:

  • Let's Encrypt
  • Symantec (issued by DigiCert)
    If you want to use a different CA, you also need to use a third-party certificate.

• Certificate set (CA set). It's a set of CA certificates versioned to allow incrementally different sets. If you delete a CA set it becomes read-only, which means you can no longer perform any operations on it but you can access the history of its activities.

• CA set version. It's a revision of a given certificate set. When you create a CA set, it has no versions. You can activate the CA set on staging and production networks only after you create a version. Version numbers start at 1 and increment as you create new versions for a set. When you activate a certificate set on the production network, you activate a specific version of that set.

📘

Activating CA set versions on ​Akamai​ networks

Only one version of a CA set can be active on a network. The version on staging and production networks can be different.

• Activation. It specifies the network on which you want to activate your CA set. You can activate on the staging or production networks. Only one version can be active on either the staging or production network. When the activation process completes, the previously activated version becomes inactive. See Activate the CA set version on a network..

• Deactivation. Before you delete a CA set, you need to deactivate its active version. When you delete a CA set, it is permanently removed from both staging and production networks and marked as Deleted. The deleted CA set becomes read-only and you can no longer perform operations on it (such as create version, activate version, etc.).

• Edge certificate. It's a certificate managed by ​Akamai​ Certificate Provisioning System (CPS) that enables secure content delivery on ​Akamai​.

• Mutual authentication. TLS mutual authentication is a process where both the client and the server present certificate identities to one another, and each verify the authenticity of the other's claimed identity using locally configured trusted CA certificates. This is in contrast to common TLS server authentication on the Web, where only the server presents its certificate identity claim and the client verifies the authenticity of that claim using its local truststore.

• PEM (Privacy enhanced mail). It's a file format for storing and sending cryptographic keys, certificates, and other data, based on a set of 1993 Internet Engineering Task Force (IETF) standards.

• Truststore. It stores certificates from a Certificate Authority that verify that the client and all CAs are trustworthy in an SSL connection.
  Truststore is an integral component of the Public Key Infrastructure (PKI) framework. It acts as a centralized storage facility for digital certificates issued by trusted Certificate Authorities and their associated public keys, which ensures the authenticity and security of online communication.

Adding certificates

When you create a new CA set or manage an existing CA set, you can use Mutual TLS Edge Truststore to add trusted CA certificates that are used to authenticate client certificates. When you create a CA set, there are no versions associated with it, so you need to create a new one (starts at 1 and increases the number as you create new versions for a CA set). Then, you can add multiple CA certificates.

CA certificates are validated automatically. If the validation is successful, you can activate your CA set on the staging and production environments. After activation you can associate your edge certificate with this CA set to enable mTLS for the secure hostnames on this edge certificate.

See the Create a CA set workflow to learn how to create a CA set and enable mTLS.

Validating added CA certificates

When Mutual TLS Edge Truststore validates your added CA certificates, it checks each CA certificate to make sure:

• It's correctly formed x509 (PEM encoded) certificate
• It has valid x509 CA bits set
• It's within the validity period
• It's a self-signed root certificate or an intermediate certificate
• It uses the SHA-256 signature hash algorithm or better (unless the allowInsecureSha1 option is set)

🚧

Allow SHA-1 (insecure) setting

​Akamai​ recommends SHA-256 or higher algorithm for certificates. Allow SHA-1 option is disabled by default. If you want to use SHA-1 signed CA certificates for this version, enable this option.