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 set (CA set). A container that holds different versions of CA certificates. Versions act like folders, where each one can store many certificates. 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.

• 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, 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.

• CA set version. A CA set acts like a container that can hold different collections of certificates. Each collection is called a version, allowing you to manage and deploy specific sets of certificates. 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 version. 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.

• Slot. Identifies where the certificate is either deployed or is already deployed.

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. Initially, a newly created CA set doesn't have any versions. To manage certificates, you need to create a new version within the CA set. Version numbering starts at 1 and increments sequentially as you create additional versions.Each version can then accommodate multiple CA certificates.

CA certificates are validated automatically. If the validation is successful, you can activate your CA set version 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 mTLS 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

For best results, use 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.

Additional considerations

• Certificates signed using any SHA hashing algorithm (SHA-256, SHA-384 etc.) will be accepted.
• Certificates signed using RSA, ECDSA, or any elliptic curve signature algorithm will be accepted.
• RSA certificates must have a key size of at least 2048 bits.
• ECDSA certificates require a minimum key size of 256 bits
• Certificates that are identical (same fingerprint) will still be accepted, but a warning will be displayed.
• Explicitly call out about leaf certificate.